I see, thanks for clarifying. So this proposal would require every implementation that chooses to ever deploy a new codepoint to implement this new extension, for all eternity. That seems brittle to me, as things would break in the presence of a single lazy implementer. What made GREASE viable was the fact that it only takes work from one popular implementation to create herd immunity, even if all other implementers are lazy. I don't think it would have been viable otherwise. David
On Wed, Apr 24, 2024 at 2:59 PM Brian Dickson <brian.peter.dick...@gmail.com> wrote: > > > 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
