As a reminder, the (non-consensus) IETF definition of consensus is that there all remaining technical objections have been addressed, or a decision has been made not to address them. I think there are people reading this who think this bad idea has some chance of actually happening. I don't think that's the case, because the technical objections raised to it are compelling. I don't see how the DNSOP working group could ever get to consensus to implement this suggestion.
tl;dr, please don't worry. This will never make it into an RFC. It was a cute idea, but that's the best I can say about it. (Of course, I'm not the one who would call consensus on this, but the chairs are, and I think they are trustworthy). On Thu, Jul 27, 2023 at 1:38 PM Robert Edmonds <edmo...@mycre.ws> wrote: > 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 > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
