Delegated Credentials in TLS

https://engineering.fb.com/security/delegated-credentials/

by sudoyear123 • 7 years ago

41 15 7 years ago

engineering.fb.com

est313• 7 years ago

While the proposal is nice, it's a bit sad that the RFC invents its own serialization scheme instead of just using ASN.1, like everything else that touches X.509:

The signature of the DelegatedCredential is computed over the concatenation of:
1. A string that consists of octet 32 (0x20) repeated 64 times.
2. The context string "TLS, server delegated credentials" for servers and "TLS, client delegated credentials" for clients.
3. A single 0 byte, which serves as the separator.
4. The DER-encoded X.509 end-entity certificate used to sign the DelegatedCredential.
5. DelegatedCredential.cred.

https://tools.ietf.org/html/draft-ietf-tls-subcerts-04#secti...

sudoyear1234• 7 years ago

DER encoded ASN.1 is used for the X.509 end-entity certificate, however generally this follows how CertificateVerify works in TLS 1.3 https://tools.ietf.org/html/rfc8446#section-4.4.3

est313• 7 years ago

Hmm fair enough. Case rested then.

baybal2• 7 years ago

Why would not they run their own CA for short term certs?

Few CDNs have this exact problem and they sign their short term certs with their master cert.

megous• 7 years ago

It's not feasible for everyone to become a public CA, and benefits of this solution will be available to anyone, I guess.

sudoyear1234• 7 years ago

As a CA you can issue certificates for other domains as well which might be undesirable. There are existing mechanisms such as Name constrained CAs and proxy certificates to reduce this scope. While they were originally considered there are issues with them. There is no widespread support for either and there is no way to know whether both sides support them. DCs allow for a extremely minimal subset of what you might need to issue credentials with your own lifetime and it only affects you. DCs are cryptographically bound to the leaf certificate as well. A bunch of this is documented in the draft.

vertex-four• 7 years ago

A system for creating delegated credentials from a leaf cert would not have to have the same checks and balances as a publicly trusted certificate authority, as any mess-up can only affect that single leaf cert.

chasil• 7 years ago

What is preventing this from turning into another "Turktrust fiasco?" Is the delegated signing privilege only valid for explicit DNS names?

https://nakedsecurity.sophos.com/2013/01/08/the-turktrust-ss...

breser• 7 years ago

All this is doing is allowing the server (or client since the protocol allows client certificates to do the same thing) to use a different key pair with a shorter validity period than the CA signed certificate.

The delegated credential is not another cerificate and doesn't have a DNS name in it at all. The original certificate who's private key was used to create the delegated credential still has that information and the client still gets that. The delegated credential only consists of four pieces of information: validity interval, public key, signature algorithm and signature. I.E. just enough information to provide the public key and verify it is signed by the CA signed certificate.

RFC is here if you want to read the details: https://tools.ietf.org/html/draft-ietf-tls-subcerts-04

saltcured• 7 years ago

The part I find a bit weak is the discussion of RFC3820 proxy certs, which I remember from the grid-computing days. They were originally designed in the different era of the late 1990s, but I would be interested to read a more in-depth comparison of the approaches.

Those proxy credentials were primarily for delegating "limited" client/user credentials, which in turn might be used as either the client or server role for subsequent TLS connections during the lifecycle of a distributed, scientific computing job. As I recall, the practical "limited" characteristic in the Globus GSI system was a single bit flag that was interpreted in the ecosystem to prevent recursive delegation, i.e. out of an abundance of caution about things like batch jobs turning into worms.

sudoyear1234• 7 years ago

This is a very good question. We actually did consider proxy certs and name constraints certs first and had a long discussion at the IETF about these different options. At the end the consensus was that it would be much better to have a very minimal structure which could only do 1 thing and nothing else. DCs also have the advantage that they are cryptographically bound to a particular End entity certificate vs a particular public key only, and hence can only be used with their properties, so it really is the minimal possible thing you need and nothing more.

tialaramex• 7 years ago

This is/ will be part of the dividend from TLS 1.3 encrypting more of the handshake.

Historically deploying a feature like delegated credentials was impractical because some large and unpredictable fraction of connections would go like this:

Popular Web Browser: "Hi, I want to talk TLS 1.2 to somesite.example, I know how to handle DelegatedCredentials if you've got any"

Some Site: "Hi, here's our delegated credentials for somesite.example and now let's..."

"Security" MITM Box: "Oh no you don't scumbag! I don't recognise that certificate - FIN. FIN. This connection is an attack!"

With TLS 1.3 that MITM box's operator has to make a decision up front, since it can't understand the part where the remote server actually identifies itself because that's now encrypted. It can either just give up and let the Popular Web Browser do TLS 1.3 unmolested and not break random features OR it can proxy everything and then since it doesn't claim to understand DelegatedCredentials the remote server won't bother trying to use them.

This way if you have middle boxes everything stays no worse than before, but if you don't you get the benefit of new features.

Unfortunately although TLS 1.3 makes it possible to begin deploying this, the end game which reaps the benefits seems a bit fraught. But hey, can't get there if you don't start.

Delegated Credentials in TLS

Related Stories