Subject: Re: [dns-privacy] WG Call for Adoption: draft-pp-recursive-authoritative-opportunistic

From: Manu Bretelle <[email-masked]>
Date: Mon, 1 Feb 2021 12:49:05 -0800

I support adoption.

I think opportunistic encryption will help drive adoption with safe
fallbacks which in turn will help building operational experience, as well
as will provide opportunities for a feedback loop between implementers and
operators, learn, iterate, tweak, and come with best practises that will
inform long term solutions.

As someone working at an authoritative that provides ADoT [0], I would love
to see more diverse adoptions than the current handful of resolver
operators as the current data is currently skewed toward 1 specific
use-case.

Manu

[0] https://engineering.fb.com/2018/12/21/security/dns-over-tls/

On Fri, Jan 29, 2021 at 5:24 AM Brian Haberman <[email-masked]>
wrote:

> All,
>      This starts a DPRIVE WG call for adoption for
> draft-pp-recursive-authoritative-opportunistic
> (
> https://datatracker.ietf.org/doc/draft-pp-recursive-authoritative-opportunistic/
> ).
> The focus of the call is the protocol defined in the draft. Please reply
> to the mailing list with your views on the WG adopting the document and
> your supporting arguments.
>
>      This call will end on February 12, 2021 at 11:59pm UTC.
>
> Regards,
> Brian & Tim
>
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 8 Feb 2021 06:26:49 -0800

I do not believe we should adopt this document.

While I think it would be useful to have a mechanism for auto-upgrading
recursive-to-authoritative resolution to TLS, and that may involve some
level of insecure discovery, the whole emphasis on opportunistic in this
draft goes in the wrong direction. The intent should be to get to the state
where you are secure from active attack as soon as possible. In particular,
I'm not aware of any valid reason why we should endorse the use of
unverifiable certificates as described in S 5.

-Ekr

---

From: Paul Wouters <[email-masked]>
Date: Mon, 8 Feb 2021 10:32:27 -0500

On Feb 8, 2021, at 09:27, Eric Rescorla <[email-masked]> wrote:
> While I think it would be useful to have a mechanism for auto-upgrading recursive-to-authoritative resolution to TLS, and that may involve some level of insecure discovery, the whole emphasis on opportunistic in this draft goes in the wrong direction. The intent should be to get to the state where you are secure from active attack as soon as possible.

I agree. If you can’t secure the DNS with DNSSEC + TLSA at this point in time, and need to fall back to unauthenticated encryption for DNS, you might as well give up entirely. Especially since a MITM is very simple to do as attackers know the IPS of the authoritative servers. 

DNS is a PKI. Unauthenticated encryption for DNS at this point in our DNSSEC deployment makes no more sense.

As I have stated previously, I am not in favour of adoption for this document.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 8 Feb 2021 17:11:06 +0000

It feels weird to have people object to this proposed protocol when they have done little to describe a better one, even after multiple requests for them (or anyone!) to do so.

Many of us would *love* to compare the opportunistic protocol proposal to a fully-authenticated protocol proposal, but cannot do so with short and clearly-incomplete statements about what such a protocol would entail. (I try not to speak for other people, but many people have said in the WG meetings that they support the opportunistic proposal but also want to see a fully-authenticated proposal.)

The two most important areas for description (at least to me) are at least one discovery mechanism that is not subject to downgrade, and what are the risks of a fully-authenticating resolver operator sending failure responses to stubs when the same resolution requests sent to an opportunistic resolver operator would be fully resolved and encrypted. Other folks here might have other things they want to see in the fully-authenticated proposal.

Without a fleshwd-out proposal for a fully-authenticated protocol to compare to, saying that this WG should not try to fulfill its charter to help encrypt recursive to authoritative traffic just seems wrong.

--Paul Hoffman

---

From: Jim Reid <[email-masked]>
Date: Mon, 8 Feb 2021 18:01:41 +0000

> On 8 Feb 2021, at 17:11, Paul Hoffman <[email-masked]> wrote:
> 

Paul, just because the WG *can* choose to do something doesn’t necessarily mean it *should*.

I’m not convinced there’s much to be gained from encrypting recursive-to-authoritative DNS traffic. Or that this will ever get deployed at scale. Have the use cases and requirements been documented for the problems this ID is intended to solve?

However my main concern are the unintended consequences from the standards track(?) RFC that eventually emerges. That could get baked into RFPs for DNS service or ICANN registry contracts, creating major operational and deployment problems for anycast providers who’d be on the hook for servicing bazillions of presumably encrypted queries per second.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 8 Feb 2021 19:02:07 +0000

> Paul, just because the WG *can* choose to do something doesn’t necessarily mean it *should*.

Quite right. My response was to the assertion that the WG should stop work altogether without being able to consider what a hopefully-future proposal for fully-authentication encryption would entail.

> I’m not convinced there’s much to be gained from encrypting recursive-to-authoritative DNS traffic.

That certainly depends on the definition of "much", but I am assuming that the WG already chose this when it considered the charter. Are you proposing that we re-open the charter again? (I kinda hope not, but would understand if folks want to think about how much value there would be to doing this work.)

> Or that this will ever get deployed at scale.

It is by definition easier to deploy opportunistic encryption than fully-authenticated encryption for both resolvers and authoritative servers.

> Have the use cases and requirements been documented for the problems this ID is intended to solve?

Yes, in the draft itself, since the first version. If they are not clear or are incomplete, I would certainly want to hear about it.

> However my main concern are the unintended consequences from the standards track(?) RFC that eventually emerges. That could get baked into RFPs for DNS service or ICANN registry contracts, creating…

Again, that would inherently be more onerous for fully-authenticated encryption. But if you are concerned about RFPs and contracts in general, a discussion of that should be added to the eventual protocol document.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Mon, 8 Feb 2021 16:02:32 -0500

> Without a fleshwd-out proposal for a fully-authenticated protocol to compare to, saying that this WG should not try to fulfill its charter to help encrypt recursive to authoritative traffic just se…

We went over this in great detail with Peter van Dijk’s “put pubkey in the DS record” proposal where he wrote something fleshed out and we discussed it at great length, touching on things like RRT’s vs parent or child being in change control vs TLSA _prefix records on NS records vs domain records.

We are discussing disagreement on basic concepts here, not on finishing up details after WG adoption of the idea. The only consensus I’ve seen so far is the problem statement.

Once we get a rough consensus on a type of solution, we can think about fleshing it out. This document is fleshed out but doesn’t seem[*] to have consensus on its basic premise of its solution.

Paul
[*] the chairs will make that call

---

From: Paul Wouters <[email-masked]>
Date: Mon, 8 Feb 2021 16:14:21 -0500

On Feb 8, 2021, at 14:02, Paul Hoffman <[email-masked]> wrote:
> That certainly depends on the definition of "much", but I am assuming that the WG already chose this when it considered the charter.

PaulH is right on this. The problem statement and charter is clear. Whether we can find an acceptable solution that will lead to widespread deployment with the right minimum security properties is what’s under discussion.

> It is by definition easier to deploy opportunistic encryption than fully-authenticated encryption for both resolvers and authoritative servers.

Very marginally easier and at an expense of clarity and simplicity.  

>> However my main concern are the unintended consequences from the standards track(?) RFC that eventually emerges. That could get baked into RFPs for DNS service or ICANN registry contracts, creatin…

IETF is not the protocol police.  We make standards people can choose to use. If others make these standards contractual requirements then you should raise those concerns there, not here. Our concerns here should be things like feasibility, deployability, operating cost etc. Perhaps our protocol will have an optional seat belt, and perhaps ICANN will require seatbelts. Then talk to ICANN. 

Paul

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 8 Feb 2021 16:25:37 -0500

I believe when Brian sent the call out, he did say
"The focus of the call is the protocol defined in the draft."
The details do need to be fleshed out, but the chairs felt
the working group saw this as a starting point.

Also, as it was pointed out, the chairs have not seen any proposals
involving fully-authenticated encryption.  This will allow some focus.
It could very well be that the working group adopts this, and can't come
to agreement on solutions.

tim

On Mon, Feb 8, 2021 at 4:02 PM Paul Wouters <[email-masked]> wrote:

> > Without a fleshwd-out proposal for a fully-authenticated protocol to
> compare to, saying that this WG should not try to fulfill its charter to
> help encrypt recursive to authoritative traffic just seems wrong.
>
> We went over this in great detail with Peter van Dijk’s “put pubkey in the
> DS record” proposal where he wrote something fleshed out and we discussed
> it at great length, touching on things like RRT’s vs parent or child being
> in change control vs TLSA _prefix records on NS records vs domain records.
>
> We are discussing disagreement on basic concepts here, not on finishing up
> details after WG adoption of the idea. The only consensus I’ve seen so far
> is the problem statement.
>
> Once we get a rough consensus on a type of solution, we can think about
> fleshing it out. This document is fleshed out but doesn’t seem[*] to have
> consensus on its basic premise of its solution.
>
> Paul

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 9 Feb 2021 00:10:59 +0000

I just re-read that.

I support adoption with a target of being experimental. (It's
a bit of a fig leaf, but is correct in this case I think.)

I think this will be useful in proportion to the extent
to which the WG figure out ways in which this opportunistic
mode can evolve towards an authenticated mode. That's not
currently in the draft.

To try answer Ekr's main criticism of this: ISTM the current
absence of any authenticated mechanism proposals does weaken
your objection significantly. If we don't know how to solve
the problem with authentication, but can see a credible way
to experiment with an opportunistic approach, then I think
documenting the latter is reasonable, esp if it provides a
step on the path to an authenticated solution.

To try answer Paul's: sad as it is, "If you can’t secure the
DNS with DNSSEC + TLSA at this point in time,..." is still
really counterfactual. One *could* secure the DNS with DNSSEC
but ~99% of zones have not done that despite many years of
elapsed time and the s/w now being available.

Jim is correct I think in his criticism - I would hope that
the WG would be willing to abandon this if it turns out that
the eventual RFC would be purely wishful thinking or would do
some actual damage.

Cheers,
S.

---

From: Brian Haberman <[email-masked]>
Date: Sat, 13 Feb 2021 09:27:11 -0500

All,
     The WGLC for adoption for this draft has completed. The chairs have
determined that there is consensus to adopt this document as a DPRIVE
working group document.

     The authors should publish the next version of the document as
draft-ietf-dprive-recursive-authoritative-opportunistic-00. The intended
status of the document will be a part of the WG discussion on this draft.

Regards,
Brian & Tim

On 1/29/21 8:24 AM, Brian Haberman wrote:
> (https://datatracker.ietf.org/doc/draft-pp-recursive-authoritative-opportunistic/).

---

From: Brian Haberman <[email-masked]>
Date: Mon, 15 Feb 2021 08:04:13 -0500

Hi all,
     In the name of transparency, I just want to let the WG know that
there has been an objection raised by several participants over the
declaration of consensus to adopt this draft. Once we work through the
process, I will follow-up with further details.

Regards,
Brian

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 19 Feb 2021 15:59:50 +0000

Belated reply from the DPRIVE AD after he read the whole thread (but not yet the other one) even if replying on this first email.

It is clear that the adoption call was not overwhelmingly in favor of adoption. But, there were supporters for adoption.

The level of rough consensus for adoption should be lower than for a last call as the WG goal is to improve it. Moreover, let's not forget that there are many adopted documents that were never published...

In short, I fully support the chairs' decision to adopt this document.

Let's all work on this document, and improve it.

Regards

-éric

-----Original Message-----
From: dns-privacy <[email-masked]> on behalf of Brian Haberman <[email-masked]>
Date: Saturday, 13 February 2021 at 15:27
To: "[email-masked]" <[email-masked]>
Subject: Re: [dns-privacy] WG Call for Adoption: draft-pp-recursive-authoritative-opportunistic

    All,

    Regards,
    Brian & Tim