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?

  • 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. Oct 30, 2018 at 3: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, 2018 at 4:35

1 Answer 1


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 :(

  • 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, 2018 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. Oct 30, 2018 at 3: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 and call it TLS 2.0.
    – Cyker
    Oct 30, 2018 at 4: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. Oct 30, 2018 at 6: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. Oct 30, 2018 at 6:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.