3

This article gives an implementation of encrypted SNI where a public key is retrieved from the DNS. It feels like cheating but imagine this: If the server publishes its certificate on its DNS record, shouldn't the client be able to send encrypted data (since it has fetched server protocol, public key, etc. from DNS record) in the very first packet, without TLS handshakes, and thus making HTTPS 0-RTT (instead of 1-RTT with TLS 1.3) even for new connections? In a word, the DNS now contain richer information than a plain domain name to ip address mapping, to help with TLS handshake.

Any security problems with this scenario?

Cyker
  • 1,613
  • 11
  • 17
  • Until DNSSEC actually works DNS can be tampered, but that's already true of IP. Also in practice DNS will often be cached for hours or days, meaning fixing any problem will be slowed quite a bit; in particular OCSP stapling probably can't work through DNS, so clients must either go back to basic OCSP or CRL, which were unreliable and slow, or to not checking revocation at all and allowing fraudulent or compromised sites to continue operating until the next browser or OS update. – dave_thompson_085 Oct 30 '18 at 03:54
  • @dave_thompson_085 If I understand it correctly OCSP stapling is the server attaching a cert validity information. It can post that to DNS record regularly as well, so I don't think this is a problem. With DNSSEC and DoT (already supported by some public DNS providers), DNS is encrypted and authenticated. The only problem might be caching. But I always see this as a source of problems. (Try google *why dns cache* and it shows *why clean/flush dns cache*.) I definitely think we need more promptly updated DNS especially when it becomes more than a domain name resolver (eg: a certificate agent). – Cyker Oct 30 '18 at 04:35

1 Answers1

4

In theory it would be possible to do a 0-RTT handshake if the certificate is known up-front (like via DNS) and RSA key exchange is done. In RSA key exchange the client creates the full premaster secret (from which encryption key etc are derived) and sends it encrypted with the servers public key (from the RSA certificate) to the server. If simplifying RSA Kx a bit to not include a server random into the computation (see comment from dave_thompson_085 below) the encryption key can be fully determined by the client it could immediately start sending encrypted data.

But, RSA key exchange is deprecated and is no longer available with TLS 1.3. The problem with RSA Kx is that an attacker could passively sniff all the traffic and if he gets later access to the certificates private key he could decrypt all the previously sniffed traffic. Diffie-Hellman key exchange instead provides forward secrecy, i.e. even if the private key of the servers certificate gets compromised the previously sniffed traffic can not be decrypted.

But, Diffie-Hellman Kx can not be done with 0-RTT since it needs the input from both client and server to compute the shared premaster secret :(

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • With DH Kx isn't server (Alice) still possible to publish its own non-secret value `A = g^a mod p` in its DNS record so that the client (Bob) can compute the secret `g^(ab) = A^b mod p` without any server response? Then the client can piggyback `B = g^b mod p` with the first data packet so that the server can calculate `g^(ab) = B^a mod p` as well. This still guarantees forward secrecy w.r.t server's private key. There's one more secret `a`, but `A` can be rotated on DNS regularly so still guarantees (weaker) forward secrecy: compromise of `a` only decrypts msgs within a limited time range. – Cyker Oct 29 '18 at 22:44
  • 1
    For plain-RSA in TLS<=1.2 client fully determines _premaster_, but master and workingkey derivations use nonces from both ClientHello and ServerHello. Although since you're breaking compatibility already you could change that also. – dave_thompson_085 Oct 30 '18 at 03:54
  • @dave_thompson_085 For the nonce part, let server post (and rotate) its nonce to DNS as well. As for break of compatibility, we can increase its [major version number](https://semver.org/) and call it TLS 2.0. – Cyker Oct 30 '18 at 04:48
  • @dave_thompson_085: It's always a pleasure to get feedback from you. I've adapted the answer to reflect what you said in the comment. – Steffen Ullrich Oct 30 '18 at 06:13
  • @Cyker: Your question only asked about publishing the certificate in the DNS and nothing else and I've answered this part. The idea to put even more and also short-lived information in the DNS at the cost of a less perfect forward-secrecy is interesting though. There will likely be some problems in implementing this since due to how DNS works (i.e. decentralized directory with caching in the nodes) there can be multiple valid `A` at one time. I recommend to ask this extended version of your idea in a separate question though to get better feedback. – Steffen Ullrich Oct 30 '18 at 06:26
  • @Cyker The point of ephemeral DH is that the private values are not stored for a long time. If the server puts some public values in the DNS, it has to store the corresponding private values until the public value gets used. That makes the session keys more at risk of being recovered and adds some complex management to track which private values are still potentially in use. You start to lose the security benefit of ephemeral session keys well before you can gain some performance. – Gilles 'SO- stop being evil' Oct 30 '18 at 12:12
  • @Gilles Yup it's *less* ephemeral and *more* dangerous but saves you one RTT. The danger is degraded forward secrecy (and possibly replays within the time range) not decryption of current session. The server can use a timeout to rotate its secret and determine if the secret sent by client is still in use. Even if it's no longer in use the server may just send a new secret (as fallback) so you still don't lose much. Plus, the timeout can be tuned depending on how much secrecy the server wants. – Cyker Oct 30 '18 at 12:18
  • @Gilles An extreme case I can think of is, the server updates its DNS record with all public info in real time. So the client gets everything it needs for TLS negotiation when it accesses DNS, before even initiating a connection to server. This is unlikely true due to DNS caching but might help understand the main point. – Cyker Oct 30 '18 at 12:32