Re: [dns-privacy] [Ext] Moving forward on draft-ietf-dprive-unauth-to-authoritative

Eric Rescorla <ekr@rtfm.com> Sun, 20 June 2021 01:40 UTC

Return-Path: <ekr@rtfm.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 8A9E33A12BD for <dns-privacy@ietfa.amsl.com>; Sat, 19 Jun 2021 18:40:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.004
X-Spam-Level:
X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mm0hSsB-XLtj for <dns-privacy@ietfa.amsl.com>; Sat, 19 Jun 2021 18:40:40 -0700 (PDT)
Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0A353A12BB for <dprive@ietf.org>; Sat, 19 Jun 2021 18:40:40 -0700 (PDT)
Received: by mail-io1-xd2f.google.com with SMTP id l64so11515641ioa.7 for <dprive@ietf.org>; Sat, 19 Jun 2021 18:40:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bZmT4XTlJ7UBflv0YzTH2XSQh+1taupIBxWibyCyZWM=; b=ZQK6A8tebE3WUrEcPNfv/rZj82W8a9QtrRsZI67N/hhO6qcesJt6jI3NgrrQqhIkqm s1AFrkX83XwusEnlAjUKzEvLw0sWmPMHi8ky1KHi0ox1p2zQfJbXoY/RmPPbNaEzo2nq l47mPN2gMzq/yD8qBiOD1YZp62QsAyTRlrZqGeIs9mh4wYinz3cTUKnrDVaXJvxssXp6 sUda8PtdaPzUNxgJwHfKwkUk2toSebmPatoH20uFVDnwBZmqRapQs0uOZlNZAa1xMmIJ HC8oU7zJn8OoBBEptLn67gmfFvnIhaQznPe9lNAfxyYVkuj5PMYSBjr5/g2JsqPNmrjM 0dqA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bZmT4XTlJ7UBflv0YzTH2XSQh+1taupIBxWibyCyZWM=; b=qnatMXikR7BXxWa+54RVczW42fDLMiqKfPkAofbcmbsYtGnITe4uMzpCKkemh3JUtf CuLM4RahilYK1anLjwH2wrNUDnF/6AHnrsPiw0G52LLJg2hbsVS5vuflT1TWcYGft60A qDvnnpMPoBTw3LTQfP5oqv7bjb+Fcjp+5e0CHwKnH+t6MxAEEDLmED1Wt0Z/Lxyp5ZV7 7VG7vXFrfQu75aa+FQZ7blB2xOfyrfoBmEO8sS2PD/PMmHQJeEK1WU0sc0fcL8HWYzRM nJ9QpteTC7MXQPuuW6ktA1tRT0U52dkVoz/XRNu4c8mGjlwOoFYMtPhfLCEMQEdLxs8i 2w2A==
X-Gm-Message-State: AOAM533uPXv569t7UXrHKUh8ynQwhXki6ftukOFxz56tRfkIEswwNZrQ dH+wk+HTJZLEAHUVSk2tUaDl3d2oA6AQb42dxfMY8w==
X-Google-Smtp-Source: ABdhPJywe+23JPXxvUAw46ASvRraPa5m2axkzTc8QXjGSmh5c5fytb+C/JYC+FyqcBAf+k7sj2Kj8klo1uz7FDobx/8=
X-Received: by 2002:a05:6602:1810:: with SMTP id t16mr13836406ioh.48.1624153239299; Sat, 19 Jun 2021 18:40:39 -0700 (PDT)
MIME-Version: 1.0
References: <9928187B-8A36-48BA-8C93-2E1A7EAAA2C2@icann.org> <CABcZeBN7b6iTS54oOKQT2SKT_+4TsAM5DkF3bjpSZKC2K+KzJw@mail.gmail.com> <834FE0FD-F720-4781-BD35-7B26E36D7DED@icann.org>
In-Reply-To: <834FE0FD-F720-4781-BD35-7B26E36D7DED@icann.org>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 19 Jun 2021 18:40:03 -0700
Message-ID: <CABcZeBP2rASq+6bfpjh38msC3i+YUobbehyf7rD4fe=Xgxj_6Q@mail.gmail.com>
To: Paul Hoffman <paul.hoffman@icann.org>
Cc: "dprive@ietf.org" <dprive@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e3bcf505c528a4cd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/zTstKfQmI89kxqG4GJhn1CNfl2I>
Subject: Re: [dns-privacy] [Ext] Moving forward on draft-ietf-dprive-unauth-to-authoritative
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 20 Jun 2021 01:40:45 -0000

On Sat, Jun 19, 2021 at 6:24 PM Paul Hoffman <paul.hoffman@icann.org> wrote:

> On Jun 18, 2021, at 7:43 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> >
> >
> >
> >> On Wed, Jun 16, 2021 at 10:13 AM Paul Hoffman <paul.hoffman@icann.org>
> wrote:
> >> Greetings again. Based on the WG discussion of the last few weeks, we
> can see that the folks with the fully-authenticated use case do not yet
> agree on a signaling mechanism. Given that, we have just published a new
> version of draft-pp-dprive-common-features that lists "SVCB on the client
> side" as one discovery mechanism, and a new version of
> draft-ietf-dprive-unauth-to-authoritative that points to that mechanism.
> When the folks with the fully-authenticated use case do agree on a
> signaling mechanism, that can be added to the -common-features draft.
> >>
> >> We would like the WG chairs to have a formal call for
> draft-pp-dprive-common-features to be a WG document soon so we know how to
> deal with it before the draft cutoff before the next IETF meeting. If the
> WG wants it as a WG document, great; if not, we would pull back all those
> features into draft-ietf-dprive-unauth-to-authoritative and the WG would
> have to decide what to do for the eventual fully-authenticated draft.
> >>
> > I think (unsurprisingly) I am not in favor of this. Let's figure out
> what we are trying to do and roughly the approach we want to follow. Until
> then, adopting drafts is premature.
>
> The WG can work on the already-adopted unauthenticated use case, and the
> fully-authenticated use case can catch up when there are authors interested
> in keeping the discussion on their protocol moving.
>

I don't see any need to personalize this discussion.

In any case, to the extent to which the WG is going to work solely on the
unauthenticated version, it can do so in the existing draft. Having a draft
which purports to contain "common features" between the authenticated and
unauthenticated use cases is not helpful when basic questions remain.

-Ekr