As we discussed in Montreal, the ESNI draft doesn't seem to interact well with origins which use multiple unrelated CDNs. While Section 7.2.2 says that the scope of key sharing is between all hosts which can respond to a single IP address, but the DNS lookup method described actually makes it apply to all hosts responding to any IP address to which the target hostname might resolve. The conflict between these two generates the issue.
It would appear that there are two deployment models which are possible with the current draft: Customers provide the ESNI keys to the CDN This implies that the client will publish the TXT records directly and use the same keys across all CDNs they use to serve traffic. This seems to be possible, since the ESNI extension carries the record_digest of the record; CDNs use the record_digest to look up the key which it should use to decrypt the extension. However, an attacker can guess-and-check by resolving a particular domain and checking whether the record_digest returned matches that seen on an inspected connection. If record_digests are unique per origin (or at least per customer's set of origins), ESNI protects relatively little. Therefore, I presume that the desire is for ESNI keys to be the same for all / large populations of a CDN's customers. CDN uses the same ESNI keys for all customers This implies the CDN will be the one generating keys and publishing the ESNI records; the client domain will use CNAMEs to point to the CDN's ESNI record. However, a common strategy for load sharing between CDNs is to provide different CNAME responses to the desired portion of traffic. If the CNAME returned during an A/AAAA query differs from the CNAME returned during a TXT query, the server receiving the traffic will be unable to decrypt the SNI. As far as I'm aware, DNS provides no mechanism to guarantee this selection will be atomic. (Incidentally, you say in 6.2 that this will probably result in an invalid identity which doesn't chain to a public trust root; it might very well be a trusted certificate, albeit for the wrong name.) Fundamentally, it seems like the choice of CDN and the choice of ESNI parameters have to be delivered to clients together and with comparable TTLs; the TXT record design makes it difficult to do that. Embedding the ESNI information in Alt-Svc would be an HTTP-specific solution, but might be an alternative we should consider. If there's a more general-purpose way of ensuring the information is delivered consistently without compromising privacy, I'm happy to see it solved in a non-HTTP manner instead / as well. One such option, which I think someone raised in Montreal, might be to bind the ESNI record to the in-addr.arpa/ip6.arpa name for the resolved IP address instead of to the hostname. This necessarily serializes the DNS queries, which is sub-optimal for performance. More fatally, server operators in general are less likely to control this namespace.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
