Re: [dns-privacy] [Ext] Revised opportunistic encryption draft

[Brian Dickson <[e-mail]>]

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

>
>
> On Fri, Oct 30, 2020 at 1:46 PM Paul Hoffman <[e-mail]>
> wrote:
>
>> On Oct 30, 2020, at 12:32 PM, Eric Rescorla <[e-mail]> wrote:
>> >
>> >
>> >
>> > On Fri, Oct 30, 2020 at 10:03 AM Paul Hoffman <[e-mail]>
>> wrote:
>> > On Oct 30, 2020, at 9:11 AM, Paul Wouters <[e-mail]> wrote:
>> >> > 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, ...).
>> >>
>> > How is this different from the transition of the Web to HTTPS?
>>
>
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.


>
> 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.
>
>
I agree with EKR. (Try not to be shocked, anyone.)


>
> 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.
>
>
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.


>
>
>> > 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.
>>
>
> The value proposition here is the confidentiality of the query. Defending
> that against active attacks requires authenticating the server.
>

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

Brian