0

My understanding of the TLS 1.3 protocol is that the client authenticates the server by checking the public key in the certificate sent by the server. Before a client connects, the operating system typically has to do a DNS lookup of the server’s domain to know what address the client should connect to.

If DNSSEC is known to be used by the operating system instead of plain DNS to look up the server’s domain, and if DNSSEC returns the server’s public key along with the server’s domain and address (or say the entire certificate) for caching by the operating system, then it would be unnecessary for the server to supply its certificate during the TLS handshake, since the client could supposedly fetch it from the DNS data cached by the operating system, correct?

Witness Protection ID 44583292
  • 1,072
  • 1
  • 8
  • 25
  • *if DNSSEC returns the server’s public key*: I'm not an expert on this, but I don't think it does. Am I wrong? – Nate Eldredge Aug 22 '20 at 23:17
  • If DNSSEC **does** return the key or certificate, the question stands of whether that would allow a TLS shortcut. If DNSSEC **doesn't** return the key or certificate, wouldn't it be useful if it did, since zillions of TLS handshakes would probably then be smaller and faster? – Witness Protection ID 44583292 Aug 23 '20 at 02:37
  • DNSSEC signs DNS records with a zone signing key that is completely unrelated to the server's TLS certificate. I suppose you could add the TLS certificate as a DNS record for the server, since DNS can hold arbitrary key-value pairs, but it wouldn't really save anything in the long run; you'd just have to get extra data from the DNS server instead of the host itself. – Nate Eldredge Aug 23 '20 at 02:42

0 Answers0