Re: [dns-privacy] [Ext] WGLC : draft-ietf-dprive-unilateral-probing

Philip Homburg <pch-ietf-dprive@u-1.phicoh.com> Tue, 06 June 2023 15:06 UTC

Return-Path: <pch-b538D2F77@u-1.phicoh.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 938ECC151B20 for <dns-privacy@ietfa.amsl.com>; Tue, 6 Jun 2023 08:06:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 C4T1EHVycgss for <dns-privacy@ietfa.amsl.com>; Tue, 6 Jun 2023 08:06:50 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [45.83.6.19]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3112C151B01 for <dns-privacy@ietf.org>; Tue, 6 Jun 2023 08:06:47 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #158) id m1q6YGM-0000KoC; Tue, 6 Jun 2023 17:06:22 +0200
Message-Id: <m1q6YGM-0000KoC@stereo.hq.phicoh.net>
To: dns-privacy@ietf.org
Cc: Paul Hoffman <paul.hoffman@icann.org>
From: Philip Homburg <pch-ietf-dprive@u-1.phicoh.com>
Sender: pch-b538D2F77@u-1.phicoh.com
References: <64e17d73-ea1a-00cb-a8a5-b5cfb39c37ae@innovationslab.net> <45ada5a8-b483-dae7-eb56-88411fb2f75c@innovationslab.net> <7a3cd83a-b80d-f00d-b050-0a1d4845146b@innovationslab.net> <D7C916AC-E47D-45FE-9976-188DAE0775EF@icann.org> <CADyWQ+HMj5NH1g_oCTNxYkGDmp2L3EwmMyOv2-bXeXvp5kvm0A@mail.gmail.com> <6B55CCC0-069F-43DD-B9DA-024E4334D6F4@icann.org> <20c5ac1666e4428b8ffa70c7b9e8a19c@verisign.com> <CADyWQ+HJ7ZLWfwxr6vb9HsERMJXuu-1zD_=cr4S+mZ1ieWrYwQ@mail.gmail.com> <0007CDA7-ADD3-43BB-B5D3-3B1810206E0E@icann.org> <8fbed8926b3f4e28b9f3f76a85e0b619@verisign.com> <CANMuhxt5cE--GUtapEL69dFkAFSU5dF3psMCgNRKj8_dXpsFLA@mail.gmail.com> <ABE27A4A-BA96-4505-A3E3-1FE83CAA5A63@icann.org>
In-reply-to: Your message of "Tue, 6 Jun 2023 13:43:50 +0000 ." <ABE27A4A-BA96-4505-A3E3-1FE83CAA5A63@icann.org>
Date: Tue, 06 Jun 2023 17:06:22 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/WqVH6m6-1_djBl7ui3HlYwrypjU>
Subject: Re: [dns-privacy] [Ext] WGLC : draft-ietf-dprive-unilateral-probing
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Addition of privacy to the DNS protocol <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Jun 2023 15:08:37 -0000

> One large problem with publishing a protocol as "experimental" is
> there is not objective way to exit that status. There are no criteria
> that say "this experiment succeeded" or "this experiment failed".
> 
> It will take much less IETF effort to fix the charter now than it
> will to move the already-deployed protocol to standards track. We
> might as well bit the bureaucratic bullet now and just fix the
> charter. If most folks agree, I can do that work.

This draft seems fine as an experiment, but as standard, maybe there are
some operational considerations that need to be addressed.

The first is that at the moment some people are serving different content on
port 853, from what they are serving on port 53. I can't quickly find
anything in this draft on how to reach those people or how to deal with
that. Current users of port 853 are not implementing this draft. So it
may take then considerable time to sort out this issue.

If this draft becomes a standard, 'almost overnight' traffic seen by
authoritative servers may switch from almost exclusively UDP to port 53, to
TLS or QUIC to port 853. It seems that the draft is rather weak in looking at
the operational impact that could have.

We also don't know much on how this affects recursive resolvers. The draft
says in Section 4.6.10: "a recursive resolver following this guidance may
also choose not to initiate new connections for encrypted transport". It
is not great to have security related standards where the implementor may or
may not implement the feature that is discussed.

Maybe we should first experiment, and then create an updated document that
becomes a standard.