Subject: Re: [dns-privacy] [Ext] Re: ADoT requirements for authentication?

From: Eric Rescorla <[email-masked]>
Date: Fri, 1 Nov 2019 07:13:01 -0700

On Thu, Oct 31, 2019 at 11:56 PM Vladimír Čunát <[email-masked]>
wrote:

> On 11/1/19 1:37 AM, Eric Rescorla wrote:
> > Hmm..... I think that's only true if you are assuming that the NS
> > record for the leaf is DNSSEC secured, but that doesn't seem like a
> > safe assumption.
>
> Generally speaking, I believe it's fine to add assumptions about DNSSEC
> validation, if that makes the ADoT protocol "better" in some way.  (and
> I expect it will)  It seems that DNSSEC will be much easier than this
> new stuff.
>

Easier for who? The advantage of transport security in this setting is that
the authoritative can just deploy it for all their users without any
interaction with the user.

By the way, I'm personally not yet 100% convinced by TLS and might e.g.
> add QUIC into consideration
>

Well, DoQ seems like an interesting direction, but I'm not sure what you
mean by
"not 100% convinced by TLS".

-Ekr

---

From: Vladimír Čunát <[email-masked]>
Date: Fri, 1 Nov 2019 15:39:14 +0100

On 11/1/19 3:13 PM, Eric Rescorla wrote:
> Easier for who? The advantage of transport security in this setting is
> that the authoritative can just deploy it for all their users without
> any interaction with the user.

I don't follow you - where's the user interaction?  To deploy DNSSEC, I
click a checkbox in my registrar's UI.  That's all.  Actually, here in
.cz you usually even need to make effort not to get DNSSEC.  Or do you
refer to the recursive resolver as "user"?

Not even stubs (like Firefox) should communicate with authoritatives, so
these still won't need to start caring about validating themselves, if
that's the direction you mean.

> Well, DoQ seems like an interesting direction, but I'm not sure what
> you mean by

Not convinced by the relatively long (first-time) handshakes; I see no
other problem, and the overwhelming TLS deployment is a huge advantage
(libs, bugs, tools).  TLS just wasn't designed for sessions that only
need to transport 1kB.

Other options: I can't remember if DTLS can do a faster handshake
(probably not), but over longer term QUIC will surely have larger
deployment.  DoH would cover both TLS and QUIC, but the http layer seems
pointless here, and I can't see demand in this WG anyway.  A specialized
protocol might be even a better fit in terms of handshake and other
properties (say DNSCrypt, DNSCurve or even a new one), but I *suspect*
these paths wouldn't be worth it - another transport protocol just for
DNS privacy.

--Vladimir

---

From: Brian Dickson <[email-masked]>
Date: Fri, 1 Nov 2019 10:16:11 -0500

On Thu, Oct 31, 2019 at 7:38 PM Eric Rescorla <[email-masked]> wrote:

>
>
> On Thu, Oct 31, 2019 at 2:41 PM Brian Dickson <
> [email-masked]> wrote:
>
>> IMNSHO, ADoT at the leaf + QNAME minimization is all that is required for
>> privacy.
>> I.e. No need for ADoT anywhere other than at the leaf zone's name server
>> (whose NS name might not be in-bailiwick, FYI).
>>
>
> Hmm.... I think that's only true if you are assuming that the NS record
> for the leaf is DNSSEC secured, but that doesn't seem like a safe
> assumption.
>

Let me re-emphasize this from the original statement: "FOR PRIVACY".

DNSSEC security is orthogonal to privacy, and is not a requirement FOR
PRIVACY.

I.e. it is always true.

Brian

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 1 Nov 2019 08:29:06 -0700

On Fri, Nov 1, 2019 at 7:39 AM Vladimír Čunát <[email-masked]>
wrote:

> that the authoritative can just deploy it for all their users without any
> click a checkbox in my registrar's UI.  That's all.  Actually, here in .cz
> you usually even need to make effort not to get DNSSEC.  Or do you refer to
> the recursive resolver as "user"?
>

Sorry, I mean the domain owner.

> (libs, bugs, tools).  TLS just wasn't designed for sessions that only need
> to transport 1kB.
>
> these paths wouldn't be worth it - another transport protocol just for DNS
> privacy.
>

QUIC and DTLS  have the same handshake performance. TLS has one more round
trip because of the TCP round trip. If you want something faster, you need
to have the public key of the server in the record pointing to it so that
the client can send in 0-RTT the first time.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 1 Nov 2019 08:34:02 -0700

On Fri, Nov 1, 2019 at 8:16 AM Brian Dickson <[email-masked]>
wrote:

>>> IMNSHO, ADoT at the leaf + QNAME minimization is all that is required
>>> for privacy.

I don't believe that that's correct in this case. The issue here is that in
order to provide confidentiality for the queries (in this case to the
authoritative) you need to authenticate the resolver. And that means
authentically learning the name of the resolver. So, for instance, if I go
the learn the NS for .com and the attacker gives me www.attacker.com, then
he can learn my queries. The name of the resolver can be authenticated by
DNSSEC or (less strongly) by having each query protected via secure
transport.

-Ekr

---

From: Brian Dickson <[email-masked]>
Date: Fri, 1 Nov 2019 10:34:29 -0500

On Fri, Nov 1, 2019 at 9:13 AM Eric Rescorla <[email-masked]> wrote:

>
>
> On Thu, Oct 31, 2019 at 11:56 PM Vladimír Čunát <
> [email-masked]> wrote:
>

Perhaps someone who operates authoritatives at scale should speak to this?
Regarding DNSSEC ease of deployment:

   1. The DNSSEC deployment/operation constraint is a performance-at-scale
   issue. *The majority of the CPU cost of DNSSEC is on the signing, which
   does not depend on query volume.*
   2. Serving DNSSEC-signed zones may have some overhead due to NSEC/NSEC3
   responses for NXDOMAIN or NODATA (no RRTYPE) responses. *Non-NXDOMAIN
   responses are larger, which consumes bandwidth but largely has no
   incremental CPU cost.*
   3. NB: NSEC3 has additional overhead due to the requirement to hash
   queries first, which depends heavily on particular NSEC3 parameters.
   4. Enabling DNSSEC widely on authoritative servers is primarily a
   moderate cap-ex exercise, i.e. provisioning adequate signing capacity.
   5. Deploying DNSSEC for all users is very feasible, and *at least one
   significant authority operator intends to enable one-click deployment for
   all users in the very near term.*

Regarding ADoT ease of deployment:

   1. The vast majority of authority traffic is UDP today (e.g. 99% or
   more).
   2. ADoT requires TCP, and additionally requires TLS.
   3. Deploying the certificates required for ADoT is very manageable, i.e.
   easy.
   4. The operational cost of serving ADoT answers is prohibitive, due to a
   number of factors:
      1. Maintaining state, for TCP and for TLS
      2. Set-up overhead for TLS
      3. Ongoing encryption of traffic after set-up, e.g. AES computational
      cost, vs "copy bytes" (possible with DMA and no CPU)
      4. Deployment of ADoT without providing means for managing these
      costs is highly unlikely to happen
      5. Developing means to manage ADoT costs (in the standards, and in
      implementations) is highly non-trivial.
   5. *Deploying ADoT is not cheap, not easy, and won't happen fast*.
   (Cheap, easy, fast, choose two, currently zero are available to choose.)

Brian

---

From: Brian Dickson <[email-masked]>
Date: Fri, 1 Nov 2019 10:45:29 -0500

On Fri, Nov 1, 2019 at 10:34 AM Eric Rescorla <[email-masked]> wrote:

> I don't believe that that's correct in this case. The issue here is that
> in order to provide confidentiality for the queries (in this case to the
> the learn the NS for .com and the attacker gives me www.attacker.com,
> then he can learn my queries. The name of the resolver can be authenticated
> by DNSSEC or (less strongly) by having each query protected via secure
> transport.
>
>
Unfortunately (and I agree that this is unfortunate) the design for DNSSEC
does not protect the NS record in the parent with a signature.

The secure delegation does provide a signed DS, which means the child
domain's DNSKEY can be validated, which protects the data on the child zone.

However, the NS record used for the delegation, being unsigned, means the
attacker can still MITM traffic towards the child zone.

The validity of the child zone's NS records is signed, as would the
corresponding A records if the NS *name* found in the child zone is also in
a DNSSEC signed zone.
(There is still the possibility of what amounts to "name chaining", e.g. if
the NS name of the zone serving the child zone's NS name, is itself in a
third zone, etc.)

Protecting against this MITM requires not only DNSSEC on the child, but
potentially DNSSEC on other related zones. It also requires that the
resolver obtain the NS record and related A/AAAA records from the child,
and then validate the certificate at the name of the NS, using CA
validation or TLSA validation. TLSA validation avoids interoperability
issues on CA trust, and avoids potential circular dependencies. TLSA
validation only requires the use of the single DNS root of trust.

So yes, DNSSEC is necessary, but compared to current resolver
implementations (which don't always fetch the child NS data and validate
it), is not yet sufficient.

Brian

---

From: Vladimír Čunát <[email-masked]>
Date: Fri, 1 Nov 2019 16:46:54 +0100

On 11/1/19 4:34 PM, Eric Rescorla wrote:
>     DNSSEC security is orthogonal to privacy, and is not a requirement
>     FOR PRIVACY.
>
>
> I don't believe that that's correct in this case. The issue here is
> that in order to provide confidentiality for the queries (in this case
> to the authoritative) you need to authenticate the resolver. And that
> means authentically learning the name of the resolver. So, for
> instance, if I go the learn the NS for .com and the attacker gives me
> www.attacker.com <http://www.attacker.com>, then he can learn my
> queries. The name of the resolver can be authenticated by DNSSEC or
> (less strongly) by having each query protected via secure transport.

Yes, we do want authoritative to be authenticated by the resolver, and
DNSSEC might help with that.  (As DNSSEC root TA seems more suitable for
this than some web PKI CA list.)  However, some people here also want
additional "opportunistic mode" where authentication isn't compulsory,
so I think that might be a compromise - without DNSSEC you'll only get
protection against passive attackers.

---

From: Ted Hardie <[email-masked]>
Date: Fri, 1 Nov 2019 09:36:47 -0700

Hi Brian,

On Fri, Nov 1, 2019 at 8:35 AM Brian Dickson <[email-masked]>
wrote:

>
>    1. The operational cost of serving ADoT answers is prohibitive, due to
>    a number of factors:
>    1. Set-up overhead for TLS
>       2. Ongoing encryption of traffic after set-up, e.g. AES
>       computational cost, vs "copy bytes" (possible with DMA and no CPU)
>
> You do realize that exactly this set of arguments has been used in the
past, to say that web servers would not be able to switch to TLS by
default?  And yet, the queries per second for popular sites served over TLS
keeps going up and up, and the elastic compute and delivery of services
means that similar methods are available at relatively low incremental
costs?

For an authoritative serving a typical zone (an enterprise, a modest web
site, a government agency), none of these incremental costs matter, given
the expected query load.  They matter for TLDs and popular second level
zones like co.uk, and we should care as a result.  But there is no need to
despair.  If you are willing to see DNS data delivery as a standard
application scaling question, rather than as a special case, there are a
lot of tools available already.

>    1. Deployment of ADoT without providing means for managing these costs
>       is highly unlikely to happen
>       2. Developing means to manage ADoT costs (in the standards, and in
> There's a lot of work to crib from, and there are also, bluntly, people
who can sell you this capacity if you don't want to care.

>    1. *Deploying ADoT is not cheap, not easy, and won't happen fast*.
> It's our job to make this better. Bold-faced assertions which don't look
at wider contexts aren't much help there, I'm afraid.

regards,

Ted

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

---

From: Brian Dickson <[email-masked]>
Date: Fri, 1 Nov 2019 11:58:25 -0500

On Fri, Nov 1, 2019 at 11:37 AM Ted Hardie <[email-masked]> wrote:

> Hi Brian,
>
> On Fri, Nov 1, 2019 at 8:35 AM Brian Dickson <
>>    1. The operational cost of serving ADoT answers is prohibitive, due
>>    to a number of factors
>>
>>
Correction/clarification: This should have read "of serving ADoT on all
traffic" (is prohibitive, or likely so).

The main gist of this is a desire to establish requirements that avoid the
need for all authority traffic to be ADoT in order to achieve privacy.
(The presumption is that ADoT is in effect an agreement between recursive
and authoritative, and requires the consent of the authoritative.)

Brian

---

From: "John R Levine" <[email-masked]>
Date: 1 Nov 2019 17:54:36 -0400

> does not protect the NS record in the parent with a signature.

The real issue here is that the DNS was designed with the assumption that 
you don't care where you get your records from.  The NS delegation is a 
hint, but it's just a hint, e.g., the set of NS in the child zone needn't 
match the parent.  DNSSEC reinforces that by validating the records 
indepedent of the path.

If we now think that validating the path is a key security feature, I 
wouldn't disagree but we should acknowledge how big a change that is to 
the DNS model.  The changes are not trivial and are likely to be painful.

Regards,
John

PS: there's always dnscurve