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

Philip Homburg <pch-ietf-dprive@u-1.phicoh.com> Thu, 08 June 2023 13:07 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 35F6DC14CF1E for <dns-privacy@ietfa.amsl.com>; Thu, 8 Jun 2023 06:07:44 -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 CtRIVL7qABXl for <dns-privacy@ietfa.amsl.com>; Thu, 8 Jun 2023 06:07:39 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [IPv6:2a10:3781:2413:1:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04A24C14CF1A for <dns-privacy@ietf.org>; Thu, 8 Jun 2023 06:07:36 -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 m1q7FM5-0000LSC; Thu, 8 Jun 2023 15:07:09 +0200
Message-Id: <m1q7FM5-0000LSC@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> <m1q6YGM-0000KoC@stereo.hq.phicoh.net> <3B79D45A-1F95-4A4A-9F8D-D3D9C424B4B2@icann.org> <m1q6oAa-0000KqC@stereo.hq.phicoh.net> <E68DAF11-E748-4F3C-AAD3-4E5921B652D9@icann.org>
In-reply-to: Your message of "Wed, 7 Jun 2023 23:12:21 +0000 ." <E68DAF11-E748-4F3C-AAD3-4E5921B652D9@icann.org>
Date: Thu, 08 Jun 2023 15:07:08 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/ty4CEhfxzC7EKQGHPsyYbJ40bEU>
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: Thu, 08 Jun 2023 13:07:44 -0000

In your letter dated Wed, 7 Jun 2023 23:12:21 +0000 you wrote:
>> The experiment could just be to gain operational experience. We can be up=
>front
>> that we don't know what will happen, and encourage people to be careful.
>
>That's true with every new protocol from the IETF. It would be good to
>understand what is different about this protocol for such an experiment.

This is certainly not for every protocols. Some protocols describe a new
application domain and have no existing traffic. Other protocols are
in use in some shape or form before becoming IETF standards.

The question here is, do we really understand the operational implications?
My answer is no. And in that case it is prudent to have an experimental 
protocol. Not go ahead with something that is broken, en then have a protocol
with many rounds up patches, confusing future implementors for ever.

>> They are following RFC 7858 (DoT) and are running a recursive resolver on
>> this port.
>
>Serving from port 853 in RFC 7858 (DoT) only applies to the client-facing
side of recursive resolvers. It doesn't apply to authoritative servers at all.

Correct. Port 853 is in use on the addresses used by some
authoritative servers to serve the role of client-facing recursive resolver.

And that will certainly confuse any recursive resolver that tries to implement
this draft.

> It is not updating RFC 7858 at all. RFC 7858 explicitly applies to
> the stub resolver and the client-facing side of recursive resolvers.
> This draft applies to the server-facing side of recursive resolvers
> and authoritative server. There is zero overlap.

Except that are talking about a single port.

Essentially this draft is squating on a port already in use. There is overlap
because some of the addresses that have the client-facing side of recursive
resolvers on port 853 appear as the address of NS records.

> That was discussed in the WG, and rejected.

That creates a broken situation that needs to be resolved carefully. 
Bassicaly, a choice that makes it hard to publish this as a standard at this
time.

> Again, you haven't shown any current practice of authoritative
> servers serving on port 853. If you can show that, it would very
> helpful.

Are you claiming that there is no example of this?

> This is unclear. If a recursive resolver has an NS record with
> addresses, when would those addresses ever be the client-facing
> side of a different resolver?

Not client-facing. This draft deals with the autoritative-facing side of
recursive resolvers. And an NS record is exactly what gets a recursor to
connect an authoritative.

> >> to TLS or QUIC: probe traffic will increase. The DNS traffic will
> >> only switch if the authoritative server operators turn on the
> >> service. The increase in probe traffic is covered throughout the
> >> document, but if you think that adding more in a particular place
> >> would help reduce negative impacts, please say where and we can
> >> add it.
> >
> > No, I'm saying it should be experimental because we don't know and should
> > experiment.
> 
> Please be specific about what we don't know so that we can be
> specific in the draft.

There are known-unknowns and unknowns-unknowns. The example I gave of
a client-facing recursive server on 853 that is shared with an authoritative
on port 53 is a clear example of a previous unknown-unknown that just
happened to become visible during testing.

There is no point in trying to give a complete list of unknown-unknowns.

Sitting in a chair thinking about what could happen is no substitute for 
real world experience. We just don't have that experience.

Section 4.2.1 of RFC 2026 says this about Experimental:

"The "Experimental" designation typically denotes a specification that
"is part of some research or development effort.  Such a specification
"is published for the general information of the Internet technical
"community and as an archival record of the work, subject only to
"editorial considerations and to verification that there has been
"adequate coordination with the standards process (see below).  An
"Experimental specification may be the output of an organized Internet
"research effort (e.g., a Research Group of the IRTF), an IETF Working
"Group, or it may be an individual contribution.

Where does it say that anything needs to measured? Who came up with that
requirement? It says specifically "[...] or development effort."

This is actually what we are doing. We try to develop a new protocol between
recursive resolvers and authoritative. We have an experimental protocol can
we can use the coming time to evaluate and refine it.

I'll stop here. I'm my opinion we lack the real world exprience to turn this
into a standard.