IETF Logo Mail Archive

Re: [DNSOP] DNS Grease?

David Schinazi <dschinazi.ietf@gmail.com> Tue, 27 February 2024 22:59 UTC

Return-Path: <dschinazi.ietf@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C96DBC151090 for <dnsop@ietfa.amsl.com>; Tue, 27 Feb 2024 14:59:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level:
X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pR6gBYCjWawK for <dnsop@ietfa.amsl.com>; Tue, 27 Feb 2024 14:59:38 -0800 (PST)
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10BCDC151091 for <dnsop@ietf.org>; Tue, 27 Feb 2024 14:59:38 -0800 (PST)
Received: by mail-ej1-x62a.google.com with SMTP id a640c23a62f3a-a34c5ca2537so649831966b.0 for <dnsop@ietf.org>; Tue, 27 Feb 2024 14:59:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709074776; x=1709679576; darn=ietf.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=7NBawopR+gmoYKcaouVD7BIKUY3x515fNefjcaRtG2k=; b=QXx8HjXBJ2rEZpC/+cfSfCcx4Px4+xxV983YOWP4FoZlHcA2Gyb2ClNgEOpPF0QBav w0Y+R9CCOqAdyL4Jpn/Vb7jekRwbpy5GbsLl6cn85ek9IDUTcrMMi0lJoC4bTb12GFoU mL56rYEJBuAFt2sR5tHXRCGORjU5YsY37njtcaXFFqmlKO5Vpx+PGgWkszUgY1xBwZ9E zwc2iaIjh7syW1+dKoAV+pq4tO7ZUSCQZb2kjy07WocEWL4TJleR7b+gcvqSTdRcvapm DMM3mMz33n3PphXEGMvFp+oeIGFnphVO40pBJmXy670IzpnE6t9pb5gRqFRYni03gvTC OFqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709074776; x=1709679576; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=7NBawopR+gmoYKcaouVD7BIKUY3x515fNefjcaRtG2k=; b=J9mrUFAE8/3IqhTSALOU/RVtw2+iiOGUmOCFzVSXd1suBiq34b3xPR8yY5DihaTA95 gDo43B/VdBln8n42O+/Obt2dtHSJobMTbpK5iwNEZ8WkT2k53P/fRc5D0fz44V7kEjgX 6DJdi9gDFe4MZMCufz8U2cVVTzGXXcO8rDQoLrqulwuEIRRgRyMwudHKrj+r7NBEifw+ S5wIWO10oZTkB41BqocpoDGSDtxD9AhXWkDZNZNxzaKEnJt6LSuHoRfBd1djouBp6gkD gOT+CALV5fFiO6pRqgVudLdQk5hbZFf4EAS/GX36BbjOYQ/CJfukI5Ys5zZaw3OtZEyP hcmg==
X-Gm-Message-State: AOJu0Yx825jqvzNnrxVyMZKyC4mUfruop4IzIWZ1RNO+X6jLXnHba2zF FMqbBZ7q8mULkMG/PQuFKq24ygW5I5EzVKtgBLC4+TcfXpyGt1vxb71KgKbgZOuPVI9N8D2KOTM HzIslpkc1FoiQ+o0OEyuPPFLNknm0+qtDv8E=
X-Google-Smtp-Source: AGHT+IE+q91m6t0HgBj6vb+V7hRPAxm+LA0L+gSzDljEVmDWVaUYSUduU15RCmAUIPeTAQwkJagKp1nqrke5IKtDezk=
X-Received: by 2002:a17:906:408b:b0:a3f:c38c:afa2 with SMTP id u11-20020a170906408b00b00a3fc38cafa2mr7818852ejj.21.1709074775964; Tue, 27 Feb 2024 14:59:35 -0800 (PST)
MIME-Version: 1.0
References: <CAHPuVdUiRbUT6ODa8UDSSkyjuzHgkQxJ5xrb9_OZH5oR7aWYDg@mail.gmail.com> <CAKr6gn3CTaRc82Wak+vn5vehK0CCzZ6meREHhi0vdhd9Zgd-gg@mail.gmail.com> <96CE9D37-480F-4B7A-B9A1-65D8F7AC9078@isc.org> <CAHPuVdVOGGVHhVm0j0SBj8T1r1+ZGD+mUew_W7XFgaJ70VSq1g@mail.gmail.com> <CAKr6gn0NyYXjRxtOo2-CXSniYRGRQ8sUYVFUZn9BtAsbryoPCA@mail.gmail.com> <68F5F9FD-3A76-4FF0-8224-4C036135EF0E@isc.org>
In-Reply-To: <68F5F9FD-3A76-4FF0-8224-4C036135EF0E@isc.org>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Tue, 27 Feb 2024 14:59:24 -0800
Message-ID: <CAPDSy+6iMsffp2q4JtH+0O4fy9YX5Q7gTpdKP3hM5WQ0TNtVQQ@mail.gmail.com>
To: "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ea8168061264fa27"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/yjF5Rz3WbeWSw5lqh4jw2Wf3x5Q>
Subject: Re: [DNSOP] DNS Grease?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Feb 2024 22:59:38 -0000

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 <marka@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 <ggm@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 <shuque@gmail.com> wrote:
> >>
> >> On Tue, Feb 27, 2024 at 12:01 AM Mark Andrews <marka@isc.org> wrote:
> >>>
> >>>
> >>>> On 27 Feb 2024, at 15:53, George Michaelson <ggm@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: marka@isc.org
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>

v2.23.0 | Report a Bug | By Email