Re: [DNSOP] DNS Grease?

[Shumon Huque <[e-mail]>]

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.

Shumon.

On Tue, Feb 27, 2024 at 5:59 PM David Schinazi <[e-mail]>
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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> wrote:
>> >>
>> >> On Tue, Feb 27, 2024 at 12:01 AM Mark Andrews <[e-mail]> wrote:
>> >>>
>> >>>
>> >>>> On 27 Feb 2024, at 15:53, George Michaelson <[e-mail]>
>> 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: [phone]              INTERNET: [e-mail]
>>
>> _______________________________________________
>> DNSOP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>