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

From: Paul Hoffman <[email-masked]>
Date: Wed, 16 Jun 2021 17:13:03 +0000

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.

--Peter and Paul

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 18 Jun 2021 19:43:20 -0700

On Wed, Jun 16, 2021 at 10:13 AM Paul Hoffman <[email-masked]>
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.

-Ekr

> --Peter and Paul_______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 20 Jun 2021 01:24:33 +0000

On Jun 18, 2021, at 7:43 PM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
>> On Wed, Jun 16, 2021 at 10:13 AM Paul Hoffman <[email-masked]> wrote:
> 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.

--Paul Hoffman

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 19 Jun 2021 18:40:03 -0700

On Sat, Jun 19, 2021 at 6:24 PM Paul Hoffman <[email-masked]> 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
> > 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

---

From: Bill Woodcock <[email-masked]>
Date: Sun, 20 Jun 2021 14:47:59 +0200

> On Jun 20, 2021, at 3:40 AM, Eric Rescorla <[email-masked]> wrote:
> 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.

My personal opinion is that unauth is a problematic half-measure, so I don’t imagine I’ll be using it.  But that’s my personal opinion, and has no bearing on the question of whether the unauth mode should be formalized.  If others see value in it, then, absolutely, it should be formalized so that a common understanding of how it should be done will exist, and interoperability will be maintained.

Likewise, I REALLY WISH the authenticated mode would get moved forward more quickly.

But tying the two together in any way at all seems bad to me.  I don’t see any value at all to turning two documents into three, with externalities, nor, if only one of these modes becomes popular in the long run (which seems the most probably outcome to me) in having it be expressed in an incomplete document with an externality to another document which references a third document that nobody cares about.

So I think I come to the same conclusion as ekr, albeit for different reasons.

                                -Bill