Subject: [dns-privacy] Revised opportunistic encryption draft

From: Paul Hoffman <[email-masked]>
Date: Fri, 30 Oct 2020 01:01:26 +0000

Greetings again. Based on the list discussion of the -00 draft, I have revised the draft with the use case and a proposed method for opportunistic encryption of recursive-to-authoritative communication. The new draft more clearly delineates what is use case and what is the proposed method, simplifies the proposed method, and is clearer where the overlap will be if the WG adopts a use case and method for authentication-required communication.

Please see
   https://tools.ietf.org/html/draft-pp-recursive-authoritative-opportunistic-01
This isn't a WG document yet, but if the WG wants it, I think it could work well within the charter, and with the discussion of draft-ietf-dprive-phase2-requirements.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Fri, 30 Oct 2020 12:11:06 -0400 (EDT)

> This isn't a WG document yet, but if the WG wants it, I think it could work well within the charter, and with the discussion of draft-ietf-dprive-phase2-requirements.

I still believe the cost of authenticating a DNS(SEC) server is so low
these days (with ACME available at no cost and with full automation)
that this draft is better not done.

One thing that stands out:

 	The recursive resolver MAY note the
 	authentication failure and act on it (such as by logging it or noting
 	it in the cache), as long as the failure does not prevent the TLS
 	session from completing.

I believe what is meant here is certificate validation (identity
authentication) and not (session) authentication. For example, an attack
modifying the TLS handshake parameters would lead to an authentication
failure and such a failure MUST NOT be ignored.

The Transport Cache section should probably mention negative cache
too.  That ia,s clarify that the cache is used not only positive TLS
authentication information but also the lack there of.

I'm not sure why the AUTHINFO section was removed?

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 30 Oct 2020 17:02:52 +0000

> that this draft is better not done.

The cost in terms of CPU cycles is indeed low. That is not the cost that is being considered when choosing opportunistic encryption. There is a real cost to the system if entire zones get server failures due to authentication mistakes made by the authoritative servers (not renewing certificates, errors in TLSA records, upstream validation problems that cause TLSA records not to validate, ...) or resolvers (dropping trust anchors that are in use, bad validation logic for TLSA, ...).

> authentication) and not (session) authentication.

Arrrgh, you are absolutely correct here. I've even made this mistake before.

> For example, an attack

Yep, and others. Will fix.

> authentication information but also the lack there of.

Good catch, yes.

> I'm not sure why the AUTHINFO section was removed?

Because you complained that the protocol was too complicated, and I agreed.

--Paul Hoffman

---

From: "John Levine" <[email-masked]>
Date: 30 Oct 2020 14:55:01 -0400

>This isn't a WG document yet, but if the WG wants it, I think it could work well within the charter, and with the discussion of draft-ietf-dprive-phase2-requirements.

I'm having some trouble following this draft since it looks like parts
of the text got scrambled, e.g.:

   In the opportunistic encryption described here, there is no need for
   the recursive resolver to authenticate the authoritative server
   because any authentication failure does not cause the TLS session
   from being set up.  

I get the gist of it, caches consult an oracle to see whether to use
DoT, and you have to find your own oracle. That seems uncontroversial,
but I fear it is so uncontroversial that it won't be useful.

As far as whether to validate the server's certificate, that seems to
me to be a policy decision based on your threat model. If your threat
is traffic being snooped in transit, you don't, if it's traffic being
stolen by hostile servers, you do. 

We leave for later the question of to what extent authenticating the
authoritative server might be a substitute for DNSSEC (keeping in mind
we know where to find dnscurve if that's what you want.)

R's,
John

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 30 Oct 2020 12:32:32 -0700

On Fri, Oct 30, 2020 at 10:03 AM Paul Hoffman <[email-masked]>
wrote:

> The cost in terms of CPU cycles is indeed low. That is not the cost that
> is being considered when choosing opportunistic encryption. There is a real
> cost to the system if entire zones get server failures due to
> authentication mistakes made by the authoritative servers (not renewing
> certificates, errors in TLSA records, upstream validation problems that
> cause TLSA records not to validate, ...) or resolvers (dropping trust
> anchors that are in use, bad validation logic for TLSA, ...).
>

How is this different from the transition of the Web to HTTPS? Sure, there
can be misconfigurations of various kinds, but good operational practices
can minimize these, and in return you get strong security.

-Ekr

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 30 Oct 2020 20:39:38 +0000

On Oct 30, 2020, at 11:55 AM, John Levine <[email-masked]> wrote:
>>  https://urldefense.com/v3/__https://tools.ietf.org/html/draft-pp-recursive-authoritative-opportunistic-01__;!!PtGJab4!vl19XNUhsMgJI-uBPf9MS755H4n4TwXtgXF2sb1KJaWgGj29kdvUieBrp6OXnpaCZE4BL36jAw$ 

And now I'm having trouble following your logic. Which oracle are you talking about? The draft only talks about "check on port 853 for DoT service".

> stolen by hostile servers, you do. 

The latter is not part of the explicit use case for this document. If others have that use case and want to write it up, that's great. However, they haven't, so we can't evaluate it.

> we know where to find dnscurve if that's what you want.)

That's for the other use case, yes.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 30 Oct 2020 20:46:17 +0000

On Oct 30, 2020, at 12:32 PM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Fri, Oct 30, 2020 at 10:03 AM Paul Hoffman <[email-masked]> wrote:
> How is this different from the transition of the Web to HTTPS?

The DNS data is already authenticated if they are using DNSSEC. Also, because the DNS is hierarchical, even a short-lived authentication failure at a particular server will take out the ability to get data for all zones beneath that one; this is not an issue in the web.

> Sure, there can be misconfigurations of various kinds, but good operational practices can minimize these, and in return you get strong security.

What extra value is the "strong security"? Is that value worth the risk of inability to get data from a zone? In the web world, the decision that the value was greater than the risk was based heavily on being able to authenticate the data using TLS. We don't have that same balance in the DNS.

Again, some folks might want to take the risk of a hierarchical failure in order to get additional authentication of data beyond what DNSSEC gives you. If so, a document stating that use case and a protocol to go with it would help find who else wants that.

--Paul Hoffman

---

From: "John R Levine" <[email-masked]>
Date: 30 Oct 2020 16:56:17 -0400

> And now I'm having trouble following your logic. Which oracle are you 
> talking about? The draft only talks about "check on port 853 for DoT 
> service".

I mean "oracle" as used in some kinds of mathematical proofs, a conceptual 
external black box that answers questions.  In this case the transport 
cache or perhaps whatever loads the transport cache is the oracle.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 30 Oct 2020 21:38:28 +0000

> -----Original Message-----
> From: dns-privacy <[email-masked]> On Behalf Of Paul
> Hoffman
> Sent: Friday, October 30, 2020 4:46 PM
> To: Eric Rescorla <[email-masked]>
> Cc: [email-masked]
> Subject: [EXTERNAL] Re: [dns-privacy] [Ext] Revised opportunistic encryption
> draft
>
> >> > I still believe the cost of authenticating a DNS(SEC) server is so
> >> > low these days (with ACME available at no cost and with full
> >> > automation) that this draft is better not done.
> >>
> >> The cost in terms of CPU cycles is indeed low. That is not the cost that is
> being considered when choosing opportunistic encryption. There is a real
> cost to the system if entire zones get server failures due to authentication
> mistakes made by the authoritative servers (not renewing certificates, errors
> in TLSA records, upstream validation problems that cause TLSA records not to
> validate, ...) or resolvers (dropping trust anchors that are in use, bad
> validation logic for TLSA, ...).
> >>
> The DNS data is already authenticated if they are using DNSSEC. Also,
> because the DNS is hierarchical, even a short-lived authentication failure at a
> particular server will take out the ability to get data for all zones beneath that
> one; this is not an issue in the web.
>
> > Sure, there can be misconfigurations of various kinds, but good operational
> practices can minimize these, and in return you get strong security.
>
> What extra value is the "strong security"? Is that value worth the risk of
> inability to get data from a zone? In the web world, the decision that the
> value was greater than the risk was based heavily on being able to
> authenticate the data using TLS. We don't have that same balance in the
> DNS.

This is an important point. Privacy can't increase the risk of a loss of availability, especially as we move closer to the DNS root.

Scott

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 30 Oct 2020 14:44:46 -0700

On Fri, Oct 30, 2020 at 1:46 PM Paul Hoffman <[email-masked]> wrote:

> >> The cost in terms of CPU cycles is indeed low. That is not the cost
> that is being considered when choosing opportunistic encryption. There is a
> real cost to the system if entire zones get server failures due to
> The DNS data is already authenticated if they are using DNSSEC.

I don't see how this is an operational difference. It's a difference in
value proposition. This whole discussion is predicated on the idea that
encrypting r2a is valuable; if it's not, we can just go home.

Also, because the DNS is hierarchical, even a short-lived authentication
> failure at a particular server will take out the ability to get data for
> all zones beneath that one; this is not an issue in the web.
>

As a practical matter, a TLS failure at a site like Google or Facebook has
a similar kind of impact. But those sites have figured out how to run with
high availability, and I anticipate that the big DNS servers who have a lot
of zones beneath them could do so as well.

> > Sure, there can be misconfigurations of various kinds, but good
> operational practices can minimize these, and in return you get strong
> security.
>
> authenticate the data using TLS. We don't have that same balance in the DNS.
>

The value proposition here is the confidentiality of the query. Defending
that against active attacks requires authenticating the server.

-Ekr

---

From: Brian Dickson <[email-masked]>
Date: Sat, 31 Oct 2020 13:52:57 -0700

On Fri, Oct 30, 2020 at 2:45 PM Eric Rescorla <[email-masked]> wrote:

>> low
I think a better comparison (better meaning more relevance and closer
tracking of the transition and operation) would be the transition of SMTP
to SMTP using TLS without downgrade susceptibility.

>> The DNS data is already authenticated if they are using DNSSEC.
To quote Daffy Duck, "Ha! That's it! Hold it right there! Pronoun trouble."
:-)

The problem with the above statement is who "they" is.

It's actually not a real problem, as I believe the correct "they" is being
referenced. I merely want to put more emphasis on which "they" this is, for
clarity in the rest of the conversation.

In this context, "they" is "whoever is operating the authoritative DNS
servers" for a zone or set of zones.

It should be noted that for a given zone, it is possible that more than one
set of DNS servers, operated by different DNS operators, can serve a given
zone. If there is >1 operator, the failure of one operator to maintain all
the DoTA mechanisms (certs, TLSA records, DNSSEC signatures) does not
impact the zone availability. Thus, the architecture of an optional (I
prefer that over opportunistic) encryption scheme regarding that side of
the connection is not fatally flawed if the mechanism(s) used involving
those mechanisms can fail, so long as they fail safe.

The important characteristic is that whatever method(s) are used, they need
to be completely downgrade resistant to all attack mechanisms, and they
need to fail safe.

> encrypting r2a is valuable; if it's not, we can just go home.
I agree with EKR. (Try not to be shocked, anyone.)

> of zones beneath them could do so as well.
I agree with EKR again.

I think the document we're discussing may need to be reworked in terms of
the way the optional ("opportunistic") encryption (DoTA) is controlled,
managed, and signalled. With a re-orientation of the perspective on that, I
think the choices become a lot clearer.

First, a simple assertion: DoTA is only possible/available if it is
configured by the authoritative DNS operator.
Thus, the control of the state of whether DoTA is available for zones
operated by that operator, resides entirely with the operator.
This also means that, depending on how DoTA availability is signalled or
detected, the methods of correcting faults in the DoTA operation can vary.
Thus, selecting signalling/detection mechanisms should take the corrective
actions available into consideration. IMHO this should actually dominate
the design.

Second, some analysis on the DNS operator's NS names, compared to the zone
names, is relevant, regardless of whether the operator is the zone
registrant or some other party.
Understanding this can help motivate elements of the design, or deciding
whether those are reasonable choices.
This includes costs, scaling, and operational practices, particularly for
which zones have (or require) DNSSEC, TLS certificates including TLSA
types, and operational practices.

Third, I'll restate it here: The important characteristic is that whatever
method(s) are used, they need to be completely downgrade resistant to all
attack mechanisms, and they need to fail safe.

Lastly, there is the standards process issue of whether any specification
for DoTA can or should be done without significant input from authoritative
DNS operators and implementers.
Clearly, any system needs to interoperate between recursives and
authoritatives, but my impression thus far is that the current document
hasn't yet adequately received or incorporated enough input from the latter
group.
Fortunately, that's easy to fix, and that's what I think this whole
conversation is about, and I'm hopeful that this input is considered
constructive, and can result in a much stronger document that will reach
consensus.
I do think this is valuable work, if it gets it right, and am happy to
participate/contribute to the process.

Apologies for the wall of text, BTW.

I'll start with the second item first.
I was originally thinking of discussing the impact of QNAME minimization
and contrasting that with zones whose NS names are the beneath the zone
name itself. But that's really irrelevant to this analysis, IMHO,
What is worth observing is that for any zone, the NS names and their
corresponding A/AAAA records are typically very stable (often not changing
for years at a time).
By comparison, the content of zones may be extremely large or very dynamic
or both, and may present potential challenges to implement DNSSEC signing
for such zones.
It is also worth observing that there is very little difficulty or cost
involved in obtaining and managing a small, static zone with an arbitrary
(mostly irrelevant) name, and to manage the DNSSEC signing of such a zone.
Put these two observations together and you get: it is possible to have a
large, dynamic, unsigned zone, whose NS names are in a different zone which
is small, static, and DNSSEC signed, with little to no cost.
A small static zone used for NS names, would only be used for the A/AAAA
record VALUES, plus any ancillary records such as TLSA records.
Who operates that NS name zone, is ORTHOGONAL to who operates the large
dynamic zone.
And, it is also worth noting, that at least some DNS operators offer
services where the zone owner manages the zone content on a hidden primary,
and the DNS operator is a secondary which also handles all the DNSSEC
operations.
So, the operational complexity of a DNSSEC-signed NS zone is as close to
the same level of complexity as managing a normal zone.

Now regarding the third item.
What does it mean for a signaling mechanism to be completely downgrade
resistant to all attack mechanisms, and to fail safe?
IMNSHO, this means the only reliable mechanism for signaling is the use of
DNSSEC.
The signaling is orthogonal to the TLS validation used for the certificates
on the authoritative server on port 853.
However, there is real value in leveraging the signaling itself for use on
certificate validation, in terms of security, performance, and flexibility.
The simplest signal is the mere presence of a DNS record that unambiguously
asserts that port 853 is to be used for any client wanting to do DoTA.
Any client which supports DoTA, upon validating the signal, must not fall
back to any other transport. This is what downgrade resistance means.

It is the responsibility of the authoritative operator to ensure the
operational state of the server matches the signal.
The signal should be present IFF (if and only if) the server can be reached
on port 853 and the TLS validation is correct and DNSSEC checks return a
state of valid.
The most unambiguous signal possible, is the presence of a TLSA record on
_853._tcp.<NS_name>.
This also relates to the first item: how to correct operational errors, if
anything in the signal vs TLS validation breaks.
Removing the TLSA record(s) turns off the signal, and the signal persists
only for the TTL of the TLSA record.
This is a potentially very fast response mechanism, for any of a variety of
situations.
This also provides support for the need to roll a TLS certificate rapidly
for security reasons (e.g. private key compromise).
If the TLSA record is used for validation, other mechanisms (e.g. OCSP or
CRL) are not strictly necessary. They are, however, still optional,
depending on the TLSA type selected by the operator.

Note that the signal presence is technically orthogonal to the decision to
USE the TLSA record for TLS verification.
However, if the resolver has already obtained the TLSA record to confirm
the use of DoTA, it would involve extremely little effort to then use the
TLSA record itself for TLS certificate verification.
This may actually improve TLS validation performance, particularly if the
TLSA record has been cached by the DNS resolver.
Reminder: these TLSA records and TLS certificates are ONLY used for
securing the DNS resolution step from the resolver to the authoritative
server.
This has nothing to do with the zone contents served by the authoritative
server, including whether the zone itself is DNSSEC-signed.

Finally, a word on managing TLSA records. TLSA records MUST be served on a
DNSSEC-signed zone.
However, the TLSA records themselves can be managed on an unsigned hidden
primary if there is a DNSSEC-signing secondary server.

So, to summarize:

   - Using NS names in a separate zone or zones (for each DNS operator) is
   scalable, and facilitates DNSSEC signing, at little to no incremental cost
   and little to no operational complexity
   - Using TLSA records at _853._tcp.<NS_NAME> in a signed zone provides an
   unambiguous signal to use optionally TLSA, in a downgrade-resistant manner.
   - TLSA records also provide TLS certificate information which is signed
   and can be (I'd suggest this as a SHOULD) used for validating the
   certificate(s) used for DoTA
   - Any failure is fail-safe, as all of the failures cannot result in
   fallback to non-853 connections, or acceptance of bogus DNS records, or
   bypass of TLS validation.
   - DNSSEC signing operations can be outsourced without requiring
   outsourcing the primary hosting of the NS name zone. Outsourcing both is
   also possible (hosting NS name zone on DNSSEC-supporting DNS operator).
   - Resolvers wanting to opt-in to DoTA would need to check for TLSA
   records (and DNSSEC validate them) as a signal
   - Resolvers wanting to opt-in to DoTA would have the option to use
   traditional CA validation alone, but this is highly recommended against.
   - TLSA records for TLS certificates can be any of the four types that
   the TLSA spec supports: 2 x CA-validation-also (EE or intermediate), 2 x
   non-CA-validation-also (EE or intermediate).
   - The non-CA-validation-also TLSA record type DOES NOT preclude use of
   certs from a public CA; it only "loosens" the validation of those certs to
   the TLSA record itself, which IMNSHO is actually stronger than the WebPKI
   validation.
   - This creates a possible DoTA signaling and TLS validation path that is
   not strictly reliant on WebPKI (meaning WebPKI failures would not break DNS)
   - The TLSA record type (and thus validation mechanisms and cert choices)
   are exclusively under the control of the owner of the zone containing the
   NS names (which may or may not be the operator of those NS name zones!!)
   - All of the signaling and validation would use existing DNS mechanisms
   and infrastructure. No new cache types would be required.
   - This is also compatible with multiple-operator DNS zones which may
   include a hybrid of TLS and non-TLS supporting operators.
      - In particular, this means different resolver policies can be
      implemented, including prefer-DoTA-but-use-non-DoTA-if-necessary or
      only-use-DoTA-servers

I don't think any of this is particularly controversial, and exactly
mirrors what already has been deployed for SMTP use of TLSA.
The success of SMTP and operational experience IMNSHO strongly supports
this as a viable way of implementing opt-in DoTA.

>> What extra value is the "strong security"? Is that value worth the risk
>> of inability to get data from a zone? In the web world, the decision that
>> the value was greater than the risk was based heavily on being able to

This is the crux of the issue, in a nutshell.

Brian