Subject: [dns-privacy] New draft-ietf-dprive-unauth-to-authoritative and draft-pp-dprive-common-features

From: Paul Hoffman <[email-masked]>
Date: Wed, 19 May 2021 16:58:19 +0000

Greetings again. Peter and I have revised draft-ietf-dprive-unauth-to-authoritative and draft-pp-dprive-common-features based on recent mailing list traffic. One major change is that we realized that we could move even more sections from unauth-to-authoritative to common-features because they would apply to the fully-authenticated use case. Please review them to see if you agree.

If people like the idea of us splitting out common features, it would be good if it too became a WG document, particularly to help focus the discussions on the unauthenticated and fully-authenticated use cases.

--Paul Hoffman and Peter van Dijk

https://www.ietf.org/archive/id/draft-pp-dprive-common-features-01.txt
https://www.ietf.org/archive/id/draft-ietf-dprive-unauth-to-authoritative-01.txt

---

From: Peter van Dijk <[email-masked]>
Date: Mon, 24 May 2021 22:21:07 +0200

Hello DNSOP,

> https://www.ietf.org/archive/id/draft-ietf-dprive-unauth-to-authoritative-01.txt

A friendly ping - we moved a bunch of text from our adopted draft to the 'common' draft, so that 'discovery' and 'security properties' can be discussed separately. We think this even makes sense if the adox draft does not get adopted today, because it (or some other draft with stronger security properties than our unauth draft) might get adopted in the future.

So, chairs, can you please think about adopting draft-pp-dprive-common-features even before the adox draft is adopted?

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

---

From: Tim Wicinski <[email-masked]>
Date: Tue, 25 May 2021 17:16:00 -0400

All

The authors took the advice from the working group and extracted the more
common features
into a separate document.   The chairs would like the working group to give
some comments, as
we feel a document like this should be considered for adoption.

https://datatracker.ietf.org/doc/draft-pp-dprive-common-features/
https://www.ietf.org/archive/id/draft-pp-dprive-common-features-01.txt
Please read and comment on this draft.

thanks
tim

---------- Forwarded message ---------
From: Paul Hoffman <[email-masked]>
Date: Wed, May 19, 2021 at 12:59 PM
Subject: [dns-privacy] New draft-ietf-dprive-unauth-to-authoritative and
draft-pp-dprive-common-features
To: [email-masked] <[email-masked]>

Greetings again. Peter and I have revised
draft-ietf-dprive-unauth-to-authoritative and
draft-pp-dprive-common-features based on recent mailing list traffic. One
major change is that we realized that we could move even more sections from
unauth-to-authoritative to common-features because they would apply to the
fully-authenticated use case. Please review them to see if you agree.

If people like the idea of us splitting out common features, it would be
good if it too became a WG document, particularly to help focus the
discussions on the unauthenticated and fully-authenticated use cases.

_______________________________________________
dns-privacy mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: Paul Wouters <[email-masked]>
Date: Tue, 25 May 2021 17:28:13 -0400

On May 25, 2021, at 17:16, Tim Wicinski <[email-masked]> wrote:
> 
> 
> All
> 
> The authors took the advice from the working group and extracted the more common features 
> into a separate document.   The chairs would like the working group to give some comments, as

I had not responded on purpose. As indicated in the past, I find the gains of encrypting but not authenticating authoritative servers not very useful.

We have an existing authentication mechanism for authenticating authoritative servers (DNSSEC) that we should spend our energy on promoting instead of writing more RFCs about securing the transport leaving the transported data vulnerable to manipulation by an ever more centralized resolver farm.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 26 May 2021 00:07:09 +0000

> We have an existing authentication mechanism for authenticating authoritative servers (DNSSEC) that we should spend our energy on promoting instead of writing more RFCs about securing the transport…

The question from Tim was whether draft-pp-dprive-common-features should be adopted. I believe that there there is nothing in draft-pp-dprive-common-features that would prevent a protocol proposal such as PaulW has here (even though there is no draft for it). If I'm wrong, the -common-features draft should be amended to allow authenticating based on DNSSEC, since that seems like an obvious mechanism.

--Paul Hoffman

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 25 May 2021 17:09:11 -0700

On Tue, May 25, 2021 at 2:28 PM Paul Wouters <[email-masked]> wrote:

> I had not responded on purpose. As indicated in the past, I find the gains
> of encrypting but not authenticating authoritative servers not very useful.
>

I agree with this.

The fundamental question here is whether we want to build a mechanism for
authenticated ADoX or not; and if so, whether there are technical
mechanisms that make it possible/practical. I don't believe we have
consensus on this point (indeed, PaulW and I disagree on that), and so just
trying to pull out those mechanisms while avoiding this issue seems not
very productive.

-Ekr

We have an existing authentication mechanism for authenticating
> authoritative servers (DNSSEC) that we should spend our energy on promoting
> instead of writing more RFCs about securing the transport leaving the
> transported data vulnerable to manipulation by an ever more centralized
> resolver farm.
>

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 26 May 2021 00:17:38 +0000

On May 25, 2021, at 5:09 PM, Eric Rescorla <[email-masked]> wrote:
> The fundamental question here is whether we want to build a mechanism for authenticated ADoX or not

It might be better to think of this as "whether we want to build a mechanism for fully-authenticated ADoX now, but if not now, allow for it to be done easily in the future". Others on the list have already said that they are interested in unauthenticated as a stepping stone to later going to full authentication.

The purpose of the proposed -common-features draft is to make such fully-authenticated mechanism(s) easily definable regardless of when the WG wants to do so.

--Paul Hoffman

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 25 May 2021 18:43:21 -0700

On Tue, May 25, 2021 at 5:17 PM Paul Hoffman <[email-masked]> wrote:

> It might be better to think of this as "whether we want to build a
> mechanism for fully-authenticated ADoX now, but if not now, allow for it to
> be done easily in the future". Others on the list have already said that
> they are interested in unauthenticated as a stepping stone to later going
> to full authentication.
>
> The purpose of the proposed -common-features draft is to make such
> fully-authenticated mechanism(s) easily definable regardless of when the WG
> wants to do so.
>

I understand your motivation, but I think in this case it is misguided. The
controversial parts of fully authenticated are precisely the signaling
mechanisms in draft-rescorla-dprive-adox that you are attempting to pull
out here. If those are acceptable, then authenticated is comparatively easy.

-Ekr

> --Paul Hoffman_______________________________________________
> dns-privacy mailing list
> [email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 26 May 2021 14:21:36 +0100

Hiya,

> we feel a document like this should be considered for adoption.

I think it might be useful to adopt such a document. But
there is a risk that it turns out to be a waste of time
if it ends up more as a tool (ab)used in arguments about
which direction(s) to take rather than a bit of spec text
that's common to >1 approach. So, I'm not sure if adopting
this soon would be a good idea or not.

WRT a couple of other points mentioned in the thread:

- "Authenticated" has been used in two different ways. For
TLS, what's authenticated is the NS. For DNSSEC, what's
authenticated is the zone signing entity. Those are not
the same entities in almost cases so it'd be better to try
hard to not confuse those.

- SVCB in the parent zone will take years to happen, if
it ever does, other than sporadically. The equivalent "DS
in the parent" problem is IMO a major reason why DNSSEC
has not been a success. I've not seen any credible argument
as to why it'd be easier to get SCVB into parent zones.

On the draft itself:

- The draft seemed ambiguous to me about how the SVCB
gets into a resolver's cache, maybe that's ok to fix in a
bit, or maybe it'd differ with different approaches, but
the authors' intent wasn't clear to this reader.

- I didn't get the intended behaviour when the "use TLS"
signal is seen, but not for all NS instances. (Maybe that's
in the pesudocode, but I didn't read that bit sorry;-)

Cheers,
S.

PS: I'm one of those who do think an opportunistic mode
is worthwhile exploring as a stepping stone to an eventual
mode with TLS server auth.

---

From: Vladimír Čunát <[email-masked]>
Date: Wed, 26 May 2021 20:21:01 +0200

I like it in principle, so I say adopt.

I already see a significant problem, though I expect we can fix it 
somehow after adoption:

> After sending out all requests for SVCB records [...]

My understanding of section 3 implies that an implementing resolver MUST 
NOT ask any of the nameservers until *all* their SVCBs have been 
attempted, in the most common case where no encryption is supported by 
the nameserver-set.  That would *not* scale at all.  Even with 13 NSs 
it's a rather bad amplification factor, and it reminds me of the recent 
NXNS attack.

On the whole, if a NS set has (many?) names without encryption support, 
I'm afraid the corresponding zones may have to do without a guarantee of 
getting encryption, though glue might help.

On 26/05/2021 15.21, Stephen Farrell wrote:
> SVCB in the parent zone will take years to happen

The SVCB glue is just a slight optimization.  I don't think it can even 
save latency, just a packet per NS (and only in cases where the SVCB 
exists).

--Vladimir

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 26 May 2021 12:49:59 -0700

On Wed, May 26, 2021 at 11:21 AM Vladimír Čunát <[email-masked]>
wrote:

> I already see a significant problem, though I expect we can fix it somehow
> after adoption:
>
> NOT ask any of the nameservers until *all* their SVCBs have been attempted,
> in the most common case where no encryption is supported by the
> nameserver-set.  That would *not* scale at all.  Even with 13 NSs it's a
> rather bad amplification factor, and it reminds me of the recent NXNS
> attack.
>
As noted in my presentation, it's more than an optimization. It's an
important security function in cases where the sensitive domain name is the
apex.

-Ekr

---

From: Brian Haberman <[email-masked]>
Date: Wed, 26 May 2021 16:07:18 -0400

Just to clarify given some of the feedback provided... This is not a
formal call for adoption. Rather, the chairs are soliciting feedback to
better inform the draft development process.

Regards,
Brian

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 26 May 2021 21:09:14 +0100

Hiya,

> important security function in cases where the sensitive domain name is the

I agree with Eric on the above. And a similar thing is true
of the DS record for DNSSEC. And there's no evidence I've
seen that either is remotely practical for the vast majority
of 2LDs. (A few exceptional TLDs aside.) That's really a
pity, and I'd love to see things improve but that's where we
seem to be and have been for years.

Cheers,
S.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 26 May 2021 16:12:05 -0400

On May 26, 2021, at 15:50, Eric Rescorla <[email-masked]> wrote:
> 
> 
>> The SVCB glue is just a slight optimization.  I don't think it can even save latency, just a packet per NS (and only in cases where the SVCB exists).
>> 
> As noted in my presentation, it's more than an optimization. It's an important security function in cases where the sensitive domain name is the apex.

Can you clarify what you mean? Isn’t the APEX of the domain name the domain name?

I suspect you mean to say if the NS record is in bailiwick of the domain, eg ns0.nohats.ca serving the domain nohats.ca. 

If so, then the IP address and glue is also available in the parent zone and connecting encrypted to 193.110.157.102 is trivial to track down as talking to ns0.nohats.ca. How long does it take to run “dig ns $name.ca @a.ca-servers.ca” for all domain names you find ending in .ca ?

If not, then i would like to understand better what you are trying to protect.

Paul