Re: [DNSOP] what could we do with 15 unused bits of QDCOUNT?
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 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
Re: [DNSOP] what could we do with 15 unused bits of QDCOUNT?
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
Re: [DNSOP] what could we do with 15 unused bits of QDCOUNT?
Please no. If we really want to stop fragmentation attacks just use well known TSIG. This doesn’t require new code. It just requires configuration. > On 28 Jul 2023, at 02:50, 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". > > Brian > > > On Wed, Jul 26, 2023 at 4:12 PM George Michaelson wrote: > if QDCOUNT is defined as [0|1] then we have 15 new bits of freedom in > the header. > > What would be interesting uses of the flow-label? Oh wait.. that's > right, nobody really knows at scale how to use flow-label either. > > I tend to "use it for 15 bits of signalling" because there are a lot > of things I wish were signalled from client to server. > > "I am new code" > "I am at least not ancient code" > "I'm the same as that other guy you saw over " > "I like TCP and want to do a persisting session" > "tell me if you are doing a|b|c|d" > "I like chocolate and want a pony" > > maybe the truth is, we've got 15 bits of zero in the header forever, amen. > > (I deliberately didn't put this in the draft- post from Ray so as not > to pollute an objective discussion of what it is or is not the value > proposition) > > clue-stick hits welcome. Avoid the stomach. > > -G > > ___ > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] what could we do with 15 unused bits of QDCOUNT?
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". Brian On Wed, Jul 26, 2023 at 4:12 PM George Michaelson wrote: > if QDCOUNT is defined as [0|1] then we have 15 new bits of freedom in > the header. > > What would be interesting uses of the flow-label? Oh wait.. that's > right, nobody really knows at scale how to use flow-label either. > > I tend to "use it for 15 bits of signalling" because there are a lot > of things I wish were signalled from client to server. > > "I am new code" > "I am at least not ancient code" > "I'm the same as that other guy you saw over " > "I like TCP and want to do a persisting session" > "tell me if you are doing a|b|c|d" > "I like chocolate and want a pony" > > maybe the truth is, we've got 15 bits of zero in the header forever, amen. > > (I deliberately didn't put this in the draft- post from Ray so as not > to pollute an objective discussion of what it is or is not the value > proposition) > > clue-stick hits welcome. Avoid the stomach. > > -G > > ___ > 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
Re: [DNSOP] what could we do with 15 unused bits of QDCOUNT?
On Thu, Jul 27, 2023 at 09:11:33AM +1000, George Michaelson wrote: > if QDCOUNT is defined as [0|1] then we have 15 new bits of freedom in > the header. We don't actually have that freedom. There's no mechanism to make those bits mean something other than a larger (invalid QDCOUNT) for a normal query. > maybe the truth is, we've got 15 bits of zero in the header forever, amen. This. There's nothing we can do with the "extra bits" (and even if we could, that wouldn't better be done with a suitable EDNS(0) extension). The meaning of the message of course depends on the OPCODE. A new OPCODE can bring in new semantics for the rest of the packet. -- Viktor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] what could we do with 15 unused bits of QDCOUNT?
On Wed, Jul 26, 2023 at 5:09 PM Robert Edmonds wrote: > George Michaelson wrote: > > if QDCOUNT is defined as [0|1] then we have 15 new bits of freedom in > > the header. > > > > What would be interesting uses of the flow-label? Oh wait.. that's > > right, nobody really knows at scale how to use flow-label either. > > > > I tend to "use it for 15 bits of signalling" because there are a lot > > of things I wish were signalled from client to server. > > > > "I am new code" > > "I am at least not ancient code" > > "I'm the same as that other guy you saw over " > > "I like TCP and want to do a persisting session" > > "tell me if you are doing a|b|c|d" > > "I like chocolate and want a pony" > > > > maybe the truth is, we've got 15 bits of zero in the header forever, > amen. > > > > (I deliberately didn't put this in the draft- post from Ray so as not > > to pollute an objective discussion of what it is or is not the value > > proposition) > > > > clue-stick hits welcome. Avoid the stomach. > > > > -G > > With a maximum length QNAME inside a UDP query packet there are slightly > under a couple thousand bits available for EDNS. Those bits at the end > of the packet are easier to get to, ecosystem-wise, so if those use > cases are worthwhile they should probably be done with EDNS. > > It depends. E.g. one variable in the mix is UDP fragmentation, which can put the EDNS component outside the first fragment. Header bits are always in the first fragment, so depending on the specific attack scenario and deployment state of things (like avoid-fragmentation), entropy in the first packet is still valuable. Brian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] what could we do with 15 unused bits of QDCOUNT?
I don't agree. My reasoning is that signals in the first 576 bytes are more likely to pass through non-conforming systems based on length alone. There is also John Scudder's observations on fast-path and slow-path processing: if its inside the state you latch EARLY when you see the packet, its far more likely to avoid CPU stalls and get done in firmware or hardware. (probably not strictly applicable, but I go to "flag early, flag often") But, for other reasons raised by other people, I concur that these bits are excluded from use because we don't have time travel and middleboxes make false assumptions. -G On Thu, Jul 27, 2023 at 10:08 AM Robert Edmonds wrote: > > George Michaelson wrote: > > if QDCOUNT is defined as [0|1] then we have 15 new bits of freedom in > > the header. > > > > What would be interesting uses of the flow-label? Oh wait.. that's > > right, nobody really knows at scale how to use flow-label either. > > > > I tend to "use it for 15 bits of signalling" because there are a lot > > of things I wish were signalled from client to server. > > > > "I am new code" > > "I am at least not ancient code" > > "I'm the same as that other guy you saw over " > > "I like TCP and want to do a persisting session" > > "tell me if you are doing a|b|c|d" > > "I like chocolate and want a pony" > > > > maybe the truth is, we've got 15 bits of zero in the header forever, amen. > > > > (I deliberately didn't put this in the draft- post from Ray so as not > > to pollute an objective discussion of what it is or is not the value > > proposition) > > > > clue-stick hits welcome. Avoid the stomach. > > > > -G > > With a maximum length QNAME inside a UDP query packet there are slightly > under a couple thousand bits available for EDNS. Those bits at the end > of the packet are easier to get to, ecosystem-wise, so if those use > cases are worthwhile they should probably be done with EDNS. > > -- > Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] what could we do with 15 unused bits of QDCOUNT?
George Michaelson wrote: > if QDCOUNT is defined as [0|1] then we have 15 new bits of freedom in > the header. > > What would be interesting uses of the flow-label? Oh wait.. that's > right, nobody really knows at scale how to use flow-label either. > > I tend to "use it for 15 bits of signalling" because there are a lot > of things I wish were signalled from client to server. > > "I am new code" > "I am at least not ancient code" > "I'm the same as that other guy you saw over " > "I like TCP and want to do a persisting session" > "tell me if you are doing a|b|c|d" > "I like chocolate and want a pony" > > maybe the truth is, we've got 15 bits of zero in the header forever, amen. > > (I deliberately didn't put this in the draft- post from Ray so as not > to pollute an objective discussion of what it is or is not the value > proposition) > > clue-stick hits welcome. Avoid the stomach. > > -G With a maximum length QNAME inside a UDP query packet there are slightly under a couple thousand bits available for EDNS. Those bits at the end of the packet are easier to get to, ecosystem-wise, so if those use cases are worthwhile they should probably be done with EDNS. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] what could we do with 15 unused bits of QDCOUNT?
George Michaelson wrote on 2023-07-26 16:11: ... maybe the truth is, we've got 15 bits of zero in the header forever, amen. that's how i treated it when i crafted EDNS0. we'd have to negotiate any new use, and we've since learned that billions of middleboxes will treat that as a 16-bit field which must always be 0 or 1, no matter what the endpoints may have agreed to. clue-stick hits welcome. Avoid the stomach. i think that some 30 years before there was an RFC called "pervasive monitoring is an attack" there should have been an RFC called "middle boxes are an attack". forget about killing hitler's grandparents or whatever -- this is what a time machine is needed for. -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] what could we do with 15 unused bits of QDCOUNT?
In the general case, you can't do anything with those bits for the same practical reason why we can't decide to allow QDCOUNT > 1. Too many existing servers expect that those bits can never be validly non-zero and will have unpredictable behavior. It's already out-of-our-control ossified. If we could do something with those bits (but we unfortunately can't), my recommendation would be to use them to allow QDCOUNT > 1. :P On Wed, Jul 26, 2023 at 7:32 PM Mark Andrews wrote: > > > > On 27 Jul 2023, at 09:20, Brian Dickson > wrote: > > > > > > > > On Wed, Jul 26, 2023 at 4:12 PM George Michaelson > wrote: > > if QDCOUNT is defined as [0|1] then we have 15 new bits of freedom in > > the header. > > > > What would be interesting uses of the flow-label? Oh wait.. that's > > right, nobody really knows at scale how to use flow-label either. > > > > I tend to "use it for 15 bits of signalling" because there are a lot > > of things I wish were signalled from client to server. > > > > "I am new code" > > "I am at least not ancient code" > > "I'm the same as that other guy you saw over " > > "I like TCP and want to do a persisting session" > > "tell me if you are doing a|b|c|d" > > "I like chocolate and want a pony" > > > > maybe the truth is, we've got 15 bits of zero in the header forever, > amen. > > > > (I deliberately didn't put this in the draft- post from Ray so as not > > to pollute an objective discussion of what it is or is not the value > > proposition) > > > > clue-stick hits welcome. Avoid the stomach. > > > > 15 bits of entropy would maybe be a good use, particularly for short > QNAMEs (and with QNAME minimization, that definitely applies to root and > TLD queries). > > That would augment or compensate for fewer bits available for 0x20 > entropy. > > Or root and TLD servers could just deploy DNS COOKIE. There is no reason > for them not to deploy > DNS COOKIE today other than vendors not implementing it. Time for vendors > to pull their fingers > out. > > DNS COOKIE is standards track. It is a security fix. Deploy it. > > > > > Brian > > ___ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 <+61%202%209871%204742> INTERNET: > ma...@isc.org > > ___ > 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
Re: [DNSOP] what could we do with 15 unused bits of QDCOUNT?
> On 27 Jul 2023, at 09:20, Brian Dickson wrote: > > > > On Wed, Jul 26, 2023 at 4:12 PM George Michaelson wrote: > if QDCOUNT is defined as [0|1] then we have 15 new bits of freedom in > the header. > > What would be interesting uses of the flow-label? Oh wait.. that's > right, nobody really knows at scale how to use flow-label either. > > I tend to "use it for 15 bits of signalling" because there are a lot > of things I wish were signalled from client to server. > > "I am new code" > "I am at least not ancient code" > "I'm the same as that other guy you saw over " > "I like TCP and want to do a persisting session" > "tell me if you are doing a|b|c|d" > "I like chocolate and want a pony" > > maybe the truth is, we've got 15 bits of zero in the header forever, amen. > > (I deliberately didn't put this in the draft- post from Ray so as not > to pollute an objective discussion of what it is or is not the value > proposition) > > clue-stick hits welcome. Avoid the stomach. > > 15 bits of entropy would maybe be a good use, particularly for short QNAMEs > (and with QNAME minimization, that definitely applies to root and TLD > queries). > That would augment or compensate for fewer bits available for 0x20 entropy. Or root and TLD servers could just deploy DNS COOKIE. There is no reason for them not to deploy DNS COOKIE today other than vendors not implementing it. Time for vendors to pull their fingers out. DNS COOKIE is standards track. It is a security fix. Deploy it. > > Brian > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] what could we do with 15 unused bits of QDCOUNT?
I like your idea! Another one is to reserve n bits for the length of the resolver/forwarder chain to the answer. if you pass it on, increment the n bits. preserve it in the answer. would permit authorities, and clients to know how long the chain is behind the answers they see and questions made. I posit 3 bits would be plenty. -G ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] what could we do with 15 unused bits of QDCOUNT?
On Wed, Jul 26, 2023 at 4:12 PM George Michaelson wrote: > if QDCOUNT is defined as [0|1] then we have 15 new bits of freedom in > the header. > > What would be interesting uses of the flow-label? Oh wait.. that's > right, nobody really knows at scale how to use flow-label either. > > I tend to "use it for 15 bits of signalling" because there are a lot > of things I wish were signalled from client to server. > > "I am new code" > "I am at least not ancient code" > "I'm the same as that other guy you saw over " > "I like TCP and want to do a persisting session" > "tell me if you are doing a|b|c|d" > "I like chocolate and want a pony" > > maybe the truth is, we've got 15 bits of zero in the header forever, amen. > > (I deliberately didn't put this in the draft- post from Ray so as not > to pollute an objective discussion of what it is or is not the value > proposition) > > clue-stick hits welcome. Avoid the stomach. > 15 bits of entropy would maybe be a good use, particularly for short QNAMEs (and with QNAME minimization, that definitely applies to root and TLD queries). That would augment or compensate for fewer bits available for 0x20 entropy. Brian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] what could we do with 15 unused bits of QDCOUNT?
if QDCOUNT is defined as [0|1] then we have 15 new bits of freedom in the header. What would be interesting uses of the flow-label? Oh wait.. that's right, nobody really knows at scale how to use flow-label either. I tend to "use it for 15 bits of signalling" because there are a lot of things I wish were signalled from client to server. "I am new code" "I am at least not ancient code" "I'm the same as that other guy you saw over " "I like TCP and want to do a persisting session" "tell me if you are doing a|b|c|d" "I like chocolate and want a pony" maybe the truth is, we've got 15 bits of zero in the header forever, amen. (I deliberately didn't put this in the draft- post from Ray so as not to pollute an objective discussion of what it is or is not the value proposition) clue-stick hits welcome. Avoid the stomach. -G ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
