I only just noticed this (don't know why). I don't know the status of discussion either, so apologies if this isn't appropriate. The draft is expired, but I felt motivated to comment since I seem to understand the problem a little bit.
TLS early data could be useful for DNS, even if it is less useful given that the cost of connection establishment is amortized quite well in most cases [1]. That assessment might differ depending on your views of the relative merits of endpoints doing their own recursion. 1. This draft could lean more heavily on RFC 8470 and 8446 for detail on TLS early data works and its effects. The bulk of the intro and even the main section are just reiterations of stuff from there. Not that that text is bad or wrong, just that it isn't really DNS-specific. For instance, the ALPN piece probably doesn't need to be repeated. 2. The draft needs to more clearly identify what might be safe to send. All the draft concretely does is forbid a few things. If this were just queries, with everything else not allowed unless stated, that might be enough. 3. How does this advice differ for recursive vs. authoritative? I think that the advice is probably going to be largely applicable to both, but the zone transfer thing seems to be one clear example of a difference worth highlighting. So you should say "everything except" or - by scoping - concentrate on a use case where there are no differences. And say that there are no differences. 4. The advice about stateful rotation in 4.1 needs to condition the recommendation on accepting early data. I'm sure that stateful rotation is fine absent a replay risk. 5. Along the lines of the design in 8470... Is there any signal that might be generated by a recursive resolver toward an authoritative if the recursive is forwarding a query that might have been replayed? Is there a need for a response indicating that the request should be tried again outside of early data? I can't see DNS servers holding queries until the handshake completes, so that's unlikely to be a solid recommendation. Of course, a recursive cannot ensure that the authoritative understands an optional signal in the same way we require reverse proxies to check with origin servers, and a non-optional signal is just going to fail the "can I deploy this" sniff test. All that to say just that I don't know what the answer is myself, but it sure would be nice if someone could tell me. Cheers, Martin [1] RFC 8310 recommends False Start, so maybe my understanding of this space needs enrichment. But that might be a symptom of a more general problem in that RFC: recommending False Start without qualification isn't a great idea as it exposes clients to downgrade attacks. It also mandates implementation (or use, I can't tell) of session tickets, which I think is a little off; a more useful mandate would be to insist on clients offering to accept tickets, and then recommend use only when adequate care is taken to avoid the worst of session linkability. Also (this list is getting long) the implication that "DNS servers on private networks" can't get certificates assumes that public names cannot be used, which is a very different assertion. But that is all part of maybe considering an update to that document. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
