MSC1714: using the TLS private key to sign federation-signing keys #1714
Conversation
|
I know I've talked about DNSSEC in quite a few of the recent proposals, but I swear I'm trying not to be annoying :D If we had DNSSEC, we could put the signing key into a TXT record and be done with it. That would be so much simpler. All that is already available, nearly no code needed to be written, we'd just need to take it. That would of course not work with IP-as-server-name HSs, but this proposal won't either without a certificate for that IP, which is expensive. |
| verify that the events which claim to originate from Alice's server actually | ||
| did so. | ||
|
|
||
| A similar situation arises if Alice used a trust root which is a certificate |
There was a problem hiding this comment.
Do we also get this problem if the cert itself has expired or been revoked (as well as the CA itself), amd not knowing whether to trust the events which were signed whilst the cert claimed to be valid or not?
There was a problem hiding this comment.
wait. We don't get a problem if the cert has expired, because it should still be possible to get hold of the (expired) certificate - either from Alice herself, or from anyone else in the room. (The rule is: if you have a copy of an event, you have to have a copy of the cert chain that you used to validate it.)
However, there are certainly similar problems with revoked certs; but there are other problems with revoked certs, as per https://github.com/matrix-org/matrix-doc/pull/1714/files#r245164485.
|
fixes #1685 |
@jcgruenhage I like this for several reasons, but I'm not yet sure it solves the primary issue leading to this proposal. When the party to some federation key leaves the matrix system, it's probable that TXT record, if not the domain entirely, will disappear from DNS. All that we can rely on to still exist are the actively participating servers in that room. Those servers have to archive and provide something which proves the identity of the historical server, without being able to forge that identity themselves. The TLS certificate tying the domain to the federation key makes that possible. If DNSSEC can be leveraged in such a post-hoc manner, we can cache that record in |
|
|
||
| Where a server is asked for its own key, the relevant certificates will already | ||
| be present in the TLS connection (and it may be difficult for a homeserver to | ||
| obtain its own certificates), so it need not add them to the response. |
There was a problem hiding this comment.
doesn't it need them anyways to cross sign the keys? or am I misunderstanding how the cross signing works here?
There was a problem hiding this comment.
it needs the keys, but not necessarily the certs.
|
also there's no mention of backwards compatibility as far as I can tell. |
|
@jevolk We can definitely store the signed DNSSEC records, but that might mean that homeservers need to do the DNS resolving themselves, since resolvers just tell you "yes it is validated" and not the data you need to validate it yourself. Take this for example, the AD flag says "authenticated data", but we'd need to validate that ourselves for this to work properly. There is also the disadvantage that the DNS records will probably rotate a lot more often, meaning this potentially takes a lot more space than storing the certificates instead. |
|
Signing with the private key of a valid TLS cert sort of relies on what happens to #1708 too, since that is part of what is considered a valid TLS cert for that server, so we'd need the thing served in #1708 also signed.(EDIT: I just saw this was pointed out in #1711 too) Building such a chain of signatures, with a bunch of expiration dates, which, if used with LE for example, change every now and then seems like a very fragile system. What about instead identifying a server by it's signing key instead of it's domain? That would help with domain reuse too. |
| key, it can use the certificate chain to confirm that it belonged to server A. | ||
|
|
||
| Each server therefore maintains a list of the signing keys it has seen for each | ||
| remote server, and the time it believes they are valid for. (It must also |
There was a problem hiding this comment.
I think there are big problems around revocation with this proposal. CRLs are falling out of fashion in favour of OCSP (Let's Encrypt does not supply a CRL at all), and of course an old certificate will always return a negative OCSP result. (In any case, CRLs only list revoked certs until they would have expired anyway).
There is therefore no way for us to perform any sort of revocation check on the TLS keys and certs which this proposal relies on. This feels like a big red flag.
Of course, it is not easy to revoke a compromised signing key as things stand today, but I am very uncomfortable with doubling-down on that failure by adding a whole extra layer of keys which can't be revoked.
| root CA to a certificate for the relevant server name, using the correct RSA | ||
| key, and use the key to validate the signature on the response. Again, the | ||
| `valid_until_ts` should be clipped according to the timespans that the | ||
| certificate chains are valid for. |
There was a problem hiding this comment.
It isn't spelt out here, but the idea in my head was that the requesting server would require the origin_server_ts on an event to be within the validity periods of the certs used to validate the key used to sign that event.
However, we have no way of knowing that the origin_server_ts is correct. This presents a problem:
- Alice has a signing key Ksign, and cross-signs it with her TLS key Ktls, which is in turn authenticated via her TLS cert C.
- Alice uses Ksign to sign a bunch of events, which Bob and others can validate via the certificate chain from C.
- Time passes; C expires and is replaced by C'.
- Eve compromises Ktls!
- So Alice revokes her current certificate C'.
- Eve uses Ktls to cross-sign a signing key which she controls, and uses that signing key to sign events which purport to be from Alice, with timestamps within the validity period of C. Bob has no way of knowing that these events came from Eve rather than Alice.
We can mitigate this by ensuring that, whenever a certificate is revoked, any other certificates for the same key are also treated as being revoked. However, there are other problems here, as per https://github.com/matrix-org/matrix-doc/pull/1714/files#r245164485.
|
My feeling on all this is that it's not at all obvious that it can be made to work reliably or securely. Meanwhile it would be a significant investment to develop it, and ultimately I think better solutions are offered by ideas such as MSC1228. I've set out some reasons at https://github.com/matrix-org/matrix-doc/issues/1685#issuecomment-452086452 which record why, although the current situation is entirely unsatisfactory, it is not so bad that we should rush into this solution rather than invest our time in MSC1228. Accordingly, I'm abandoning this MSC. |
richvdh
added
abandoned
Rendered