On Wed, Apr 24, 2024 at 2:28 PM David Schinazi <dschinazi.i...@gmail.com> wrote:
> If I understand your proposal correctly, this would require the receiver > to support this new EDNS option in order to properly remove values that the > sender thought were unused but that the receiver did not. Such a > requirement on receivers makes it impossible for the sender to know it can > safely GREASE, because the sender has no way of knowing that the receiver > supports this new EDNS option. In general, the idea behind GREASE is that > any sender can use it without requiring any changes on the receiver. > Not exactly, at least I don't think so. The presumption would be at some point in time, new code points are deployed. If the "grease" specific thing were well publicised, and new code points referenced it, it might be possible to infer that newer code points are deployed only if they are covered in grease. And conversely, code points prior to the EDNS grease thing would not be covered in grease. Thus, senders using grease would be able to know that either a code point was free to use for grease operations (because the receiver does not return the grease EDNS thing), or that the grease coverage facilitated flagging of code points subsequent to the EDNS grease thing. It's kind of like a flag day, but more of a soft opening, i.e. a dependency situation. Brian > > David > > On Wed, Apr 24, 2024 at 2:09 PM Brian Dickson < > brian.peter.dick...@gmail.com> wrote: > >> >> >> On Wed, Feb 28, 2024 at 7:11 AM Shumon Huque <shu...@gmail.com> wrote: >> >>> Thanks for your comments David. I hope it will progress too, and good to >>> hear that that grease worked well for TLS and QUIC. >>> >>> On random vs reserved values, we do intend to propose some reserved >>> ranges (there is a placeholder section in the draft for this already). And >>> then try to have a debate about the pros and cons (e.g. is reservation just >>> going to cause middleboxes to treat the greasing range specially, etc). For >>> the larger fields, yes, we could allocate larger reserved ranges and pick >>> randomly from those. For the smaller fields (that accommodate just a >>> discrete set of flags, rather than a number), we could reserve just a small >>> handful of flags. For any proposal that uses purely random unallocated code >>> points, I think we'd need software to have pre-configured (or configurable) >>> end-of-test dates as one way to avoid future interoperability issues. >>> >>> Even for the larger ranges though, there is a more granular >>> classification (such as data vs meta vs q-types in the RR-type space) where >>> more nuanced treatment is needed, such as defining multiple reserved ranges >>> and expecting distinct response behavior for each. >>> >> >> I have an idea, which may or may not be useful, for avoidance of testing >> random code points which are subsequently used, when the two endpoints have >> differing ideas of which code points are in use. >> >> (Philosophically, I prefer negotiated/signaled over unilateral/reserved >> things. Reserved ranges are the latter. The suggestion here is one >> potential method or approach for the former.) >> >> Would using an EDNS option to signal the set of values that the sender >> believes are "grease" (and are set in the outgoing packet) work? >> >> The recipient would flag the values that are "in use" from among the >> "grease" values, and the original sender would handle the non-grease >> response elements flagged by the recipient. >> >> This would also allow for one or more grease values to be probed >> simultaneously or individually, in order to assess/investigate sources of >> non-response. Including information from both ends via EDNS allows for >> correlation of those including both the path and the authoritative server >> EDNS information as data points. >> >> For example, if RRTYPE=FOO were a grease value sent by a resolver, it >> would have EDNS thing "grease-list:RRTYPE=FOO,..." (modulo bike shed color) >> added. The authoritative server would generate whatever response it had for >> RRTYPE=FOO, and add a corresponding EDNS thing "non-grease-list:RRTYPE=FOO". >> The resolver would be able to safely ignore anything/everything in the >> response, and optionally cache tuple of (authority-IP,code-point) so as to >> potentially avoid using it as grease, or to log something to the effect of >> "FOO is now in the wild, maybe you need to update this resolver's >> software?". >> >> This would allow for random grease rather than reserved grease, I think, >> and would be more appropriate for exercising the full range of code points. >> >> Brian >> >> >>> >>> Shumon. >>> >>> On Tue, Feb 27, 2024 at 5:59 PM David Schinazi <dschinazi.i...@gmail.com> >>> wrote: >>> >>>> I think this draft is a great idea and I'd love to see it progress. >>>> GREASE did well in TLS and worked wonders in QUIC - it helped us catch >>>> multiple real production issues early on. >>>> >>>> That said, I do worry about the idea of using random unallocated >>>> values. Not all software gets updated, and no software gets updated >>>> immediately worldwide, so this idea is bound to cause interoperability >>>> failures down the road. For the 16-bit values, definitely allocate a few >>>> hundred GREASE codepoints and then pick a random one from that allocated >>>> list. For the fields smaller than 8 bits, things are obviously more >>>> difficult but I think you'll be much better off reserving a much smaller >>>> number of codepoints and using those instead of using random ones. One >>>> instance of an non-updated implementation spraying what values it thinks >>>> are unallocated could be enough to prevent future extensibility. >>>> >>>> David >>>> >>>> On Mon, Feb 26, 2024 at 10:39 PM Mark Andrews <ma...@isc.org> wrote: >>>> >>>>> Yep, we are in a much better position than we were in 2019. Most >>>>> failures are >>>>> well < 1% when talking to authoritative servers. Broken firewall >>>>> defaults have >>>>> been fixed and mostly deployed. >>>>> >>>>> > On 27 Feb 2024, at 16:41, George Michaelson <g...@algebras.org> >>>>> wrote: >>>>> > >>>>> > so yet again, I voice things which show my ignorance, not yours. I >>>>> > thank you for the gentle clue-stick hit, it was educational. >>>>> > >>>>> > -G >>>>> > >>>>> > On Tue, Feb 27, 2024 at 12:24 PM Shumon Huque <shu...@gmail.com> >>>>> wrote: >>>>> >> >>>>> >> On Tue, Feb 27, 2024 at 12:01 AM Mark Andrews <ma...@isc.org> >>>>> wrote: >>>>> >>> >>>>> >>> >>>>> >>>> On 27 Feb 2024, at 15:53, George Michaelson <g...@algebras.org> >>>>> wrote: >>>>> >>>> >>>>> >>>> Not in any way to stop this specific draft, I wonder if this is a >>>>> more >>>>> >>>> general principle of exercising code points which are not marked >>>>> >>>> "never to be used" and should also be raised cross-area, or in >>>>> another >>>>> >>>> place? >>>>> >>>> >>>>> >>>> Maybe the best path is to get this proved here, and then >>>>> embrace-extend. >>>>> >>> >>>>> >>> Sure there are a lot of places where this should be done. This is >>>>> going >>>>> >>> to cover DNS. >>>>> >> >>>>> >> >>>>> >> Yup, and although Mark and I have been mulling this for DNS for a >>>>> number >>>>> >> of years now, the general principle has also been discussed >>>>> elsewhere (see >>>>> >> the references to greasing) and RFC 8701 describes greasing for TLS. >>>>> >> >>>>> >> We should track that work too, but this draft can focus on the DNS >>>>> use case. >>>>> >> >>>>> >> Shumon. >>>>> >> >>>>> >>>>> -- >>>>> 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 >>>>> >>>> _______________________________________________ >>>> 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 >>> >>
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
