0

The security of a TLS connection relies on trusting the CA's certificate, which in turn, is usually actually a proof of DNS entry ownership. Even though the server operator may request a certificate on its behalf, when server operator and domain owner distrust each other, domain owner wins.

SSL and TLS are usually associated with the domain name, and the client doesn't care about server's real IP. However the client always asks the server for a certificate. This results in one more RTT, making HTTPS one time slower than HTTP, not taking into account the key exchange which add 1 to 2 RTTs. Keep-Alive header and TLS 1.3 makes the problem less of a headache, but the RTT at first handshake cannot be saved. Why not just let the DNS server return the server IP together with the certificate and key exchange information, saving one RTT?

The only advantage I see here is that multiple servers can use multiple certificates. This allows to revoke one of the certificates without affecting the others. However, if any of these servers is compromised, it doesn't make detecting compromise any easier. With any private key MITM attacks can already be quite transparent, and it's just as difficult to notice the attack.

  • 3
    The DNS Server's sole purpose is to turn domain names into IP addresses, and the one-time cost of that additional request to get the certificate is pretty low in the grand scheme of things. The cert would be the same size no matter where it came from. Your scenario wouldn't work at all if you only had an IP address to work with and not a domain name. – Robert Harvey Aug 12 '18 at 15:40
  • That would add significant load to DNS servers and make DNS responses more difficult to cache (simply because of the sheer size of certs + their trust chain). This would also require completely new DNS record types and new server deployment tooling to deploy your certs to DNS. That's not impossible but it's a lot of engineering effort that requires participation from many actors (e.g. your ISP's DNS server – remember that DNS is distributed, if we ignore authoritative servers). If you use a CDN then HTTPS termination will be close to the client anyway, with RTTs comparable to a DNS lookup. – amon Aug 12 '18 at 18:36
  • Changes to DNS records can take hours to propogate thru all the levels of servers that cache them. If a certificate is revoked , you want that to be visible as soon as possible. Allowing the DNS server to send the certificate would increase the chance that a client would use a stale certificate. – 1201ProgramAlarm Aug 12 '18 at 20:07
  • Why not just let the DNS server return the server IP together with the certificate and key exchange information The nameserver may not be under the same administrative or technical control than the webhost (different providers) so how could the DNS server authoritatively send that back? Except with DANE of course but there some humans put the certificate or some derivative of it in the DNS because it controls it, not because the nameserver fetched it somewhere somehow. – Patrick Mevzek Aug 13 '18 at 21:23
3

If you want perfect forward secrecy, you must negotiate a separate session key for each connection (or short-lived group of connections, depending on the implementation). It is not possible to negotiate an ephemeral session key with a "dumb" DNS nameserver (in fact, the DNS protocol doesn't even provide the necessary primitives for it without a lot of folding and mutilating). Furthermore, even if we assume the DNS nameserver is somehow negotiating a session key with the end user, that key still needs to be propagated to the actual content server in order to do TLS termination. Ephemeral keys are meant to be ephemeral; they should not be leaving RAM, let alone traversing the network in this fashion.

The keying round trips are unavoidable, unless you are willing to give up forward secrecy. Giving up forward secrecy is seriously undesirable given the Snowden revelations (which showed among other things that the NSA had an actual practice of storing encrypted communications in the hope of eventually decrypting them) and the likelihood of similar behavior by other adversaries.

That leaves us with just saving the certificate download. But the reality is that serving a certificate (or any large-enough file) over TCP (the transport layer used by HTTP(S)) is likely to be faster and more efficient than serving it over UDP (the transport used by DNS). UDP requires the application to manually re-send any lost chunks, and to manually fix up packet reordering or duplication. UDP also requires the application to manually break files up into packets (which may need to be extremely small depending on the network) and reassemble them. TCP does all these things automatically, and typical TCP implementations are heavily optimized for file transfer (e.g. TCP automatically resizes packets to best fit the congestion of the underlying network link). UDP still makes sense for best-effort transfers of very short messages such as DNS queries, but transferring an entire signed certificate would likely be slower over DNS than HTTP/HTTPS.

Of course, there is also the problem of caching and indirection. It is extremely common for users to communicate with non-authoritative DNS nameservers (for example, those provided by their ISP). In theory, these nameservers are supposed to return the same results as their authoritative counterparts, either by directly querying them (recursively if needs be) or by caching the results from previous queries up to a configurable time-to-live (TTL). In practice, they often deviate from the standard, for example in any or all of these ways:

  1. NXDOMAIN hijacking (returning a "fake" IP address instead of an error for nonexistent domain lookups, which usually results in the user seeing ads vaguely related to the domain name).
  2. Not respecting the TTL (caching for longer than they are supposed to).
  3. Ignoring, dropping, or serving errors for requests which are not commonly issued by regular web browsers (e.g. requests for TXT records).
  4. Support for and actual use of DNSSEC varies substantially by ISP and by region.

It is difficult to put into practice any "clever DNS hack" when half the standard is not correctly implemented by a substantial portion of your clients.

  • Thanks for the detailed answer. It is possible to drop forward secrecy for only the first request and use ephemeral keys for subsequent responses, though it is not desirable too. However I'd like to argue that while TLS certificates are big and difficult to transfer, the only important part of it, the public key, needs only 32 extra bytes (in compressed form). By adding 32 extra bytes on top of DNSSEC and falling back to the regular method in case the user fails to get an authenticated public key, I don't think it's UDP that's preventing such a scheme. – He WenYang Aug 13 '18 at 17:29
  • If you don't transmit a signature and instead rely on DNSSEC, then you are doing DANE, which has its own issues. – Kevin Aug 13 '18 at 17:43

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.