Brian Dickson wrote: > Top-reply (since there are already a bunch of threaded replies that might > benefit from this): > Queries are small, and have room in the first packet for EDNS (and often the > resulting size will still be < 576). > Idea: > EDNS "signal" + bits -> tells server the client knows about the new meaning of > the 15 bits of QCOUNT, and is sending its client-side version of what those > bits are. > I.e. the bits are NOT changed from zero in the header in the query, only in > the > reply and only if the server understands this EDNS option. > IFF a server understands this EDNS parameter, it responds with the > corresponding EDNS parameter (possibly without bits, either same EDNS > parameter > or a sibling parameter), and sets the 15 bits per whatever the rules are. > Reason: > Putting bits in the header (when mutually understood and agreed upon) ensures > they are in the first portion of the response, even if the response gets > fragmented. E.g. for entropy, this is an important feature, to protect against > things like "fragmentation considered poisonous".
So, 15 bits of extra entropy is not that much for such a substantial engineering effort. If getting entropy into the first response fragment in order to protect against off-path spoofing vulnerabilites is the problem to be solved, *and* you're willing to update both the client and the server implementations, *and* you're willing to negotiate a new message format definition between updated clients and servers, then you should just go ahead and put a cryptographically secure amount of entropy directly into the header. Expand the DNS header to add space for 256 bits of cryptographically secure entropy right after the 12 octet STD 13 DNS header and don't bother with re-defining the QDCOUNT field. Otherwise you're still left to wonder if all the various small bits of repurposed entropy in a DNS transaction add up to something that's cryptographically secure. Also, if you're willing to discount EDNS COOKIE because it might not be carried in the first response fragment, it seems like the ~15 bits added by UDP source port randomization should also be discounted, since the UDP query might have passed through a de-randomizing NAT box. So, that gives you 16 bits DNS ID entropy, plus 15 bits of "QDCOUNT" entropy, plus whatever is added by 0x20 (since both client and server have been updated with new code, they can also be mandated to support 0x20), which gives you 31 up to perhaps 50 bits of entropy, which still can't be considered cryptographically secure. Or, if the above is too use case specific, but there is a class of problems that is worthwhile to solve that can only be solved by getting data into the first response fragment, then for the amount of engineering and operational effort required it sounds like an "EDNS version 1" project and one of the requirements should be that the "EDNS1" data be carried between the 12 octet STD 13 DNS header and the question section. Of course, there would probably have to be an array of really compelling use cases to make such a project worthwhile as well as an opportunity for complexity reduction in order to get folks interested in undertaking such a project. -- Robert Edmonds _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
