Subject: [dns-privacy] Authentication in draft-ietf-dprive-opportunistic-adotq

From: Paul Hoffman <[email-masked]>
Date: Mon, 15 Feb 2021 22:24:43 +0000

Greetings again. One of the issues that seems to most bother people who don't like the idea of opportunistic ADoT(Q) is the handwaviness of "but authenticate if you can". That comes from RFC 7435, which is the informational RFC that defines opportunistic security (OS). To quote from section 1.2 of that document:
   To achieve widespread adoption, OS must support incremental
   deployment.  Incremental deployment implies that security
   capabilities will vary from peer to peer, perhaps for a very long
   time.  OS protocols will attempt to establish encrypted communication
   whenever both parties are capable of such, and authenticated
   communication if that is also possible.  Thus, use of an OS protocol
   may yield communication that is authenticated and encrypted,
   unauthenticated but encrypted, or cleartext.  This last outcome will
   occur if not all parties to a communication support encryption (or if
   an active attack makes it appear that this is the case).

So far, the proposals for opportunistic ADoT(Q) in this WG have followed that by talking about authentication, but so far no one has given a reason to require authenticated transport given the presence of DNSSEC in the DNS protocol. There have been comments on the list (but without any supporting Internet Drafts) that some resolvers might want to only serve answers that they got in a fully authenticated fashion, and those same people objected to the consideration of opportunistic ADoT(Q) because it would make the possible later definition of a fully-authenticated protocol more difficult.

I propose a way forward: make the two protocols obviously different so that they don't affect each other. For those who want opportunistic ADoT(Q), change the current design so that deploying it would not make creating and deploying a fully-authenticated protocol more difficult; for those who want a fully-authenticated protocol, design it so that it does not make designing and deploying opportunistic ADoT(Q) more difficult.

Does this sound like a good approach going forward. It gives those supporting fully-authenticated protocol as much time as they need to come up with a working protocol design, without stopping progress on the proposal that has already gotten a fair amount of support in the WG.

--Paul Hoffman

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 15 Feb 2021 14:31:05 -0800

On Mon, Feb 15, 2021 at 2:25 PM Paul Hoffman <[email-masked]> wrote:

> Greetings again. One of the issues that seems to most bother people who
> don't like the idea of opportunistic ADoT(Q) is the handwaviness of "but
> authenticate if you can". That comes from RFC 7435, which is the
> informational RFC that defines opportunistic security (OS). To quote from
> section 1.2 of that document:
> So far, the proposals for opportunistic ADoT(Q) in this WG have followed
> that by talking about authentication, but so far no one has given a reason
> to require authenticated transport given the presence of DNSSEC in the DNS
> protocol.

The reason is straightforward: if you do not provide authentication for the
server, then you do not have confidentiality in the face of an active
attacker. I'm pretty sure I've said this before, so I'm surprised at the
claim that "no one has given a reason"

I propose a way forward: make the two protocols obviously different so that
> they don't affect each other. For those who want opportunistic ADoT(Q),
> change the current design so that deploying it would not make creating and
> deploying a fully-authenticated protocol more difficult; for those who want
> a fully-authenticated protocol, design it so that it does not make
> designing and deploying opportunistic ADoT(Q) more difficult.
>
> Does this sound like a good approach going forward. It gives those
> supporting fully-authenticated protocol as much time as they need to come
> up with a working protocol design, without stopping progress on the
> proposal that has already gotten a fair amount of support in the WG.
>

This doesn't sound like a very good idea to me. IMO we should only specify
a protocol that authenticates the server.

-Ekr

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 15 Feb 2021 22:36:24 +0000

On Feb 15, 2021, at 2:31 PM, Eric Rescorla <[email-masked]> wrote:
> The reason is straightforward: if you do not provide authentication for the server, then you do not have confidentiality in the face of an active attacker. I'm pretty sure I've said this before, so I'm surprised at the claim that "no one has given a reason"

You have indeed said it before, and it is indeed essential if having confidentiality in the face of an active attacker is required. The draft has always said that is not a requirement.

> This doesn't sound like a very good idea to me. IMO we should only specify a protocol that authenticates the server.

Who do you mean by "we" in that sentence? So far, no one has specified a first draft of such a proposal, even after repeated requests over many months.

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 15 Feb 2021 22:36:45 +0000

Hiya,

On 15/02/2021 22:24, Paul Hoffman wrote:
> Does this sound like a good approach going forward.

Not to me sorry;-(

A. I don't understand the proposal.

B. I want an oppo protocol to be a stepping stone to
an authenticated one. There must be some changes to
tale that last step of course, but they need to be
something that can co-exist with the oppo variant and
also be trivially easy for those deploying (e.g. no
need to change anything other than a cert maybe). I'm
not clear if you're proposal would make that harder
but it sure sounds like it would. (That said I'm not
aware of any practical-to-deploy-soon authenticated
scheme and don't want to wait for DNSSEC to take over
the universe, much as I'd be happy if it did.)

S.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 15 Feb 2021 22:37:50 +0000

Hiya,

> a protocol that authenticates the server.

Fair enough that that's your preference. How's that gonna
work and be deployable though?

Ta,
S.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 15 Feb 2021 14:49:19 -0800

> work and be deployable though?

The reason we have WGs is to work out such matters in detail, no? And in
particular, I think the WG should try to figure out the problem space
before designing.

However, it seems like there's a relatively obvious strawman proposal here:

- We invent some mechanism that allows you to specify in an NS record that
the server takes TLS (as a hacky example, "servers have to be named
<some-sentinel>.example.com").
- Servers are authenticated via the WebPKI, with the name as listed above.

I'm sure there are plenty of things that people won't like about this
(e.g., I imagine that some people would like to use DNSSEC), and the signal
I just invented is gross. Maybe in the process of deciding what people
don't like about this, we can understand the problem space better.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 15 Feb 2021 14:49:31 -0800

On Mon, Feb 15, 2021 at 2:36 PM Paul Hoffman <[email-masked]> wrote:

> > The reason is straightforward: if you do not provide authentication for
> the server, then you do not have confidentiality in the face of an active
> You have indeed said it before, and it is indeed essential if having
> confidentiality in the face of an active attacker is required. The draft
> has always said that is not a requirement.
>

Which is one of the reasons I disagree with the draft. However, that's very
different from "no one has given a reason".

-Ekr

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 15 Feb 2021 22:52:20 +0000

> A. I don't understand the proposal.

Fair enough, because I didn't propose one yet, just asking the WG if they thought that would be helpful, given that the proponents of fully-authenticated have not yet shown interest in publishing a draft.

> an authenticated one.

Yes, definitely.

> There must be some changes to
> need to change anything other than a cert maybe).

That might be sufficient, or maybe there has to be one other thing, hopefully also trivial.

> I'm
> but it sure sounds like it would.

Optimally, it would not.

> (That said I'm not

Well, exactly.

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 15 Feb 2021 22:57:17 +0000

Hiya,

> <some-sentinel>.example.com").

Wasn't exactly that proposed but shot down already (for
DNS, not crypto, reasons)? Maybe I'm recalling wrong. I did
kinda like it mind - the hackiness appeals a bit to me:-)

S.

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

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 15 Feb 2021 14:58:47 -0800

> kinda like it mind - the hackiness appeals a bit to me:-)

I don't recall. My sense was that people didn't like it being WebPKI rather
than DNSSEC, but maybe there's some more fatal reason? If so, I'd certainly
appreciate a link to that shooting down.

-Ekr

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 15 Feb 2021 22:59:28 +0000

On Feb 15, 2021, at 2:49 PM, Eric Rescorla <[email-masked]> wrote:
> The reason we have WGs is to work out such matters in detail, no? And in particular, I think the WG should try to figure out the problem space before designing. 

Yes, please.

> - We invent some mechanism that allows you to specify in an NS record that the server takes TLS (as a hacky example, "servers have to be named <some-sentinel>.example.com").

That addresses just one part of the problem space, the authentication of the authoritative server. Another part, which people have brought up a few times, is discovery (which is part of the first of those proposals, but not the second). Yet another is how a client of the resolver would determine if a lookup error means "the name doesn't exist" or "the name exists but the resolver was not able to get an authenticated answer".

> I'm sure there are plenty of things that people won't like about this (e.g., I imagine that some people would like to use DNSSEC), and the signal I just invented is gross. Maybe in the process of deciding what people don't like about this, we can understand the problem space better.

The biggest one: which group of Internet users would want to use a resolver that will refuse to give useful answers if the answers aren't authenticated? Without understanding those users (as compared to a few people who would want to set up such a resolver), we can't evaluate such a design.

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 15 Feb 2021 23:04:01 +0000

> appreciate a link to that shooting down.

Forget, sorry. Can look tomorrow or maybe someone'll beat
me to it - best I recall is maybe that renaming loadsa NSes
is a non-starter, and getting that into the parent zone is
a double non-starter. Even if you somehow did it alongside
the current NS names for a while, load-balancing may break
whenever a non-supporting recursive randomly lands on the
<sentinel>.example.org instance.

Something like that anyway IIRC.

S

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 15 Feb 2021 15:05:41 -0800

> Something like that anyway IIRC.

Sure, I can believe that. I'm not any kind of DNS expert, but it's hard to
believe we can't invent *some* signal that you use to ask whoever served
you the NS records.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 15 Feb 2021 15:07:05 -0800

On Mon, Feb 15, 2021 at 2:59 PM Paul Hoffman <[email-masked]> wrote:

> > - We invent some mechanism that allows you to specify in an NS record
> that the server takes TLS (as a hacky example, "servers have to be named
> That addresses just one part of the problem space, the authentication of
> the authoritative server. Another part, which people have brought up a few
> times, is discovery (which is part of the first of those proposals, but not
> the second).

Yes, I agree there are two problems. This is one proposal in two pieces,
one for each problem.

Yet another is how a client of the resolver would determine if a lookup
> error means "the name doesn't exist" or "the name exists but the resolver
> was not able to get an authenticated answer".
>

I agree this has to be solved somehow, but I'm not really following why
it's that complicated. I'm not any kind of DNS expert, but I assume we can
invent a suitable error (SERVFAIL + extended error perhaps?).

> The biggest one: which group of Internet users would want to use a
> resolver that will refuse to give useful answers if the answers aren't
> authenticated? Without understanding those users (as compared to a few
> people who would want to set up such a resolver), we can't evaluate such a
> design.
>

I'm not sure I follow. There are two situations here:

1. The server ostensibly offers DoX but I couldn't connect.
2. The server doesn't offer DoX at all.

In case (2) I would expect the resolver to proceed as normal. I.e., you
would get an answer. In case (1) I would expect it to return an error (see
above). I'm not aware of any particular reason to expect that users would
find these behaviors objectionable. After all, we already had a transition
in which the recursives decided to DNSSEC enforcement and that seems to
have gone reasonably OK.

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 15 Feb 2021 23:15:22 +0000

On 15/02/2021 23:05, Eric Rescorla wrote:
> believe we can't invent*some*  signal that you use to ask whoever served
> you the NS records.

Yep. I think someone had a presentation a while back about
how all the approaches considered so far were dead ends or
impractical and why.

So it may be that a new RRTYPE is needed, in which case, I
gotta ask why that has a better chance than DNSSEC+DANE, as
those seem similarly challenging to me.

Of course, if there were something that strongly motivated
DNS actors (registrars, TLDs, server operators) that'd be
different but I don't think I've heard of anything that's
attractive like that and that meets this requirement. (So
there's no equivalent of the HTTPS RRTYPE here that's been
suggested so far and that appeals to almost all actors.)

Cheers,
S.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 15 Feb 2021 15:18:58 -0800

> how all the approaches considered so far were dead ends or

If someone could point me at that, I would be appreciative.

-Ekr

---

From: Paul Wouters <[email-masked]>
Date: Mon, 15 Feb 2021 18:23:26 -0500 (EST)

> kinda like it mind - the hackiness appeals a bit to me:-)

I think it was shot for many reasons. One of them being that a signal
for encrypted transport is not a per-domain property but a per-ns
property.

Here is a different sentinel:

_53._dns.ns0.example.com. IN TLSA x y z <base64ofCert>

Then do (D)TLS

Now you can choose:

1) Use DNS(SEC) for validation
2) Use WebPKI[*] for validation
3) TOFU
4) Take at face value

Of course, this runs into issues we talked about before. Revealing a
query for ns0.nohats.ca already loses privacy unless you are centralized
at godaddy. But even if you didn't leak anything, doing encrypted "stuff"
to the IP of ns0.nohats.ca itself already gives all of that away too.

Then we also talked about untrustworthy parents, which are an even bigger
concern for unauthenticated connections.

Then we also talked about TTLs needed for verification of parental glue
at the child and facilitating dnssec transparency on the DS record.

The key point I want to make here is that you need to faciliate
authenticated encryption even if you want to say "but since that is
too difficult/hard/slow for now, you could skip the authentication".

This means you _first_ need to specify how to do the authenticated
version before you start specifying the un-authenticated version. If you
don't do this, what you end up with is a resolver with two independent
mechanisms. It is then forced to first initiate the authenticated attempt,
upon some kind of failure, tries to do the unauthenticated (but completely
different) approach. And it cannot even do this in parallel because then
the authenticated method is downgraded from a privacy loss point of view
to the unauthenticated method - since once you send the DNS query
through the channel, you have given away all the information you were
protecting to begin with.

Paul W
[*] well, it's really trusting only LetsEncrypt CA[**]
[**] Which depends on insecure DNS records for authentication, so
      in reality you need DNSSEC or WebPKI is just reduced to TOFU

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 15 Feb 2021 15:39:50 -0800

On Mon, Feb 15, 2021 at 3:23 PM Paul Wouters <[email-masked]> wrote:

> that

I agree that in principle this is true, but ISTM that one could make the
same argument about Web servers, but as a practical matter we've
gotten pretty far with the reference containing the security indicator.
In any case, one could imagine using some HSTS-like mechanism
once you have connected, right?

> to the IP of ns0.nohats.ca itself already gives all of that away too.

Right. This seems like an inherent property, no? I.e., if an authoritative
only serves example.com, then encryption doesn't help much here.
The thing to avoid seems to be where ns.atlanta.example,
ns.biloxi.example, and ns.charlottesville.example all point to the same
server.

-Ekr

---

From: Daniel Migault <[email-masked]>
Date: Mon, 15 Feb 2021 22:14:13 -0500

I do agree that given the structure of the
DNS and the existing mechanisms in place -
Paul W mentioned the DNS is a PKI - the WG
should authenticate the DNS server.

It is unclear to me what advantages
opportunistic security provides as well as
how it presents a starting point to a fully
secured solution. Resolvers are already
providing part of the privacy and the
remaining privacy is not provided - as
mentioned by Eric.  The level of confidence
provided by opportunistic security seems even
lower given that the DNS server is point of
convergence as opposed to a random node for
example. It seems to me, that more thoughts
are need to evaluate how a more robust
solution could leverage from an opportunistic
solution.  I would propose the other way
around: the WG first focuses on a full
solution, and then see if any intermediary
steps may be helpful to reach its deployment.

Something - as suggested by Paul W - based on
the DNS service "_dns" seems a good starting
point.

Yours,
Daniel

-- 
Daniel Migault
Ericsson

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 16 Feb 2021 10:23:19 -0500

On Mon, Feb 15, 2021 at 5:25 PM Paul Hoffman <[email-masked]> wrote:
...

> I propose a way forward: make the two protocols obviously different so
> that they don't affect each other. For those who want opportunistic
> ADoT(Q), change the current design so that deploying it would not make
> creating and deploying a fully-authenticated protocol more difficult; for
> those who want a fully-authenticated protocol, design it so that it does
> not make designing and deploying opportunistic ADoT(Q) more difficult.
>

I don't see why there would be a conflict between
draft-ietf-dprive-opportunistic-adotq and any future authenticated
encryption RFC that we produce, so I don't see the need to impose a drastic
dividing line (e.g. different port numbers).

Here's a counter-proposal:
1. Mark draft-ietf-dprive-opportunistic-adotq "experimental".  This is in
line with previous work on opportunistic encryption, e.g. RFC 8164, and
accurately reflects the draft's status as both speculative and (hopefully)
transitional.
2. Replace Section 5 with the following language:

There is currently no defined mechanism for authenticated ADoT, so
resolvers MUST NOT authenticate the server except by private agreement with
the server operator.  Server operators SHOULD use self-signed certificates
to avoid implying an authentication mechanism that might conflict with a
future ADoT authentication standard.

As I've said before, I _do_ think this draft is valuable and presents a
worthwhile public experiment that will pave the way for authenticated
ADoT.  For DNS services that are used to DNS over UDP, running DNS over TLS
is a big, scary project.  This draft can provide a way to get some practice
with that in a low-risk setting, where TLS-related failures are not
significantly user-visible.  Once operators are comfortable with DNS over
TLS, I think it will be a lot easier to start rolling out some real
authentication.

On Mon, Feb 15, 2021 at 5:25 PM Paul Hoffman <[email-masked]> wrote:

> protocol. There have been comments on the list (but without any supporting
> Internet Drafts) that some resolvers might want to only serve answers that
> they got in a fully authenticated fashion, and those same people objected
> to the consideration of opportunistic ADoT(Q) because it would make the
> possible later definition of a fully-authenticated protocol more difficult.
>
> I propose a way forward: make the two protocols obviously different so
> that they don't affect each other. For those who want opportunistic
> ADoT(Q), change the current design so that deploying it would not make
> creating and deploying a fully-authenticated protocol more difficult; for
> those who want a fully-authenticated protocol, design it so that it does
> not make designing and deploying opportunistic ADoT(Q) more difficult.
>
> --Paul Hoffman_______________________________________________
> dns-privacy mailing list
> [email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 16 Feb 2021 15:41:07 +0000

On Feb 16, 2021, at 7:23 AM, Ben Schwartz <bemasc=[email-masked]> wrote:
> I don't see why there would be a conflict between draft-ietf-dprive-opportunistic-adotq and any future authenticated encryption RFC that we produce, so I don't see the need to impose a drastic dividing line (e.g. different port numbers).
> 
> 1. Mark draft-ietf-dprive-opportunistic-adotq "experimental".  This is in line with previous work on opportunistic encryption, e.g. RFC 8164, and accurately reflects the draft's status as both speculative and (hopefully) transitional.
> There is currently no defined mechanism for authenticated ADoT, so resolvers MUST NOT authenticate the server except by private agreement with the server operator.  Server operators SHOULD use self-signed certificates to avoid implying an authentication mechanism that might conflict with a future ADoT authentication standard.

That seems fine. (Well, "self-issued" is the proper term, and we'd have to elaborate a bit on how to do that, but yes). This also works well with PaulW's prooposed sentinel.

> As I've said before, I _do_ think this draft is valuable and presents a worthwhile public experiment that will pave the way for authenticated ADoT.  For DNS services that are used to DNS over UDP, running DNS over TLS is a big, scary project.  This draft can provide a way to get some practice with that in a low-risk setting, where TLS-related failures are not significantly user-visible.  Once operators are comfortable with DNS over TLS, I think it will be a lot easier to start rolling out some real authentication.

Indeed.

--Paul Hoffman

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 16 Feb 2021 16:57:38 +0100 (CET)

> Il 16/02/2021 00:23 Paul Wouters <[email-masked]> ha scritto:
> 
> Now you can choose:
> 

Thanks for noting this. In general, I think that any solution for the authentication of name servers should not depend on the WebPKI. The DNS is a foundational block of the Internet - if it stops working, all services stop working (except those based on the direct use of IP addresses), not just the Web. The DNS should have as less dependencies as possible, and certainly not depend on the policy and security mechanisms of specific application-layer protocols.

Also, requiring you to acquire a certificate from a Web CA would be quite a change from the traditional model in which you could just run your own zone without having to ask anyone for permission.  It would introduce a gatekeeping role and attribute it to a relatively small set of private parties (again, centralization).  The fact that certificates are currently available for free is not a solution, first because there is no guarantee that they always will, and second because this does not alleviate the gatekeeping concerns.

-- 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Paul Wouters <[email-masked]>
Date: Tue, 16 Feb 2021 11:18:51 -0500

> I don't see why there would be a conflict between draft-ietf-dprive-opportunistic-adotq and any future authenticated encryption RFC that we produce, so I don't see the need to impose a drastic divi…

I explained that in my previous message. Opportunistic normally is “do encryption, then you may omit authentication if that is too hard”. Opportunistic is not “try this technology and maybe in the future try this completely other technology”.  

> There is currently no defined mechanism for authenticated ADoT, so resolvers MUST NOT authenticate the server except by private agreement with the server operator.

That makes using a LetsEncrypt certificate violate the RFC’s MUST NOT. I strongly object to this as now you are actively weakening security.

>   Server operators SHOULD use self-signed certificates to avoid implying an authentication mechanism that might conflict with a future ADoT authentication standard.

Same here.

> As I've said before, I _do_ think this draft is valuable and presents a worthwhile public experiment that will pave the way for authenticated ADoT.  For DNS services that are used to DNS over UDP, running DNS over TLS is a big, scary project.  This draft can provide a way to get some practice with that in a low-risk setting, where TLS-related failures are not significantly user-visible.

The “big scary” part of using TLS is in the transport that is common for authenticated and unauthenticated TLS. And as I’ve said before, at this point in time generating a selfsigned cert is harder than getting a validated ACME certificate.

>   Once operators are comfortable with DNS over TLS, I think it will be a lot easier to start rolling out some real authentication.

I strongly disagree, please reread my previous message that describes how these solutions are identical except for how or if the authenticate the incoming certificate payload.

Paul

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 16 Feb 2021 16:28:43 +0000

Hiya,

On 16/02/2021 15:41, Paul Hoffman wrote:
> That seems fine. (Well, "self-issued" is the proper term, and we'd
> have to elaborate a bit on how to do that, but yes). This also works
> well with PaulW's prooposed sentinel.
I think I maybe said it before (sorry if this is a repeat)
but I'm against recommending self-issued certs. Even if
we're only aiming for oppo, we shouldn't be making it hard
to transition to auth if/when that becomes an option and
encouraging certs with expiry in 2038 does exactly that,
even if that's not what's intended. A "SHOULD" there is
just a bad idea.

S.

---

From: Andrew Campling <[email-masked]>
Date: Tue, 16 Feb 2021 16:43:50 +0000

> Also, requiring you to acquire a certificate from a Web CA would be quite a change from the traditional model in which you could just run your own zone without having to ask anyone for permission.…

+1 to the general points made above about reducing resilience and increasing centralisation - IMHO any developments that increase the current drift towards centralisation should be treated with caution and may well be counter to RFC 8890, ditto those that reduce resilience.  

Andrew

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 16 Feb 2021 12:00:37 -0500

On Tue, Feb 16, 2021 at 11:19 AM Paul Wouters <[email-masked]> wrote:

> I explained that in my previous message. Opportunistic normally is “do
> encryption, then you may omit authentication if that is too hard”.
> Opportunistic is not “try this technology and maybe in the future try this
> completely other technology”.
>

These are not different technologies; they're precisely different usage
profiles of the same standard (RFC 8310).

> the server operator.
> That makes using a LetsEncrypt certificate violate the RFC’s MUST NOT.
>

Serving under such a certificate would not violate this requirement.

> The “big scary” part of using TLS is in the transport that is common for
> authenticated and unauthenticated TLS.
>

I think the scary part is that an authenticated TLS failure (due to
misconfiguration, bug, overload, or rollback) results in an outage.
draft-ietf-dprive-opportunistic-adotq never results in an outage; you just
fall back to cleartext and pay a small latency penalty.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 16 Feb 2021 17:35:57 +0000

From: dns-privacy <[email-masked]> On Behalf Of Ben Schwartz
Sent: Tuesday, February 16, 2021 12:01 PM
To: Paul Wouters <[email-masked]>
Cc: Paul Hoffman <[email-masked]>; [email-masked]
Subject: [EXTERNAL] Re: [dns-privacy] Authentication in draft-ietf-dprive-opportunistic-adotq

   [SAH] [snip]

   I think the scary part is that an authenticated TLS failure (due to misconfiguration, bug, overload, or rollback) results in an outage.  draft-ietf-dprive-opportunistic-adotq never results in an outage; you just fall back to cleartext and pay a small latency penalty.

   [SAH] It’s more than that. TLS adds complexity, complexity adds fragility, and fragility leads to outages or compromises. NIST‘s National Vulnerability Database (https://nvd.nist.gov/) lists 950 TLS vulnerabilities since 1999, and 347 in the past three years. Authoritative name servers that don’t implement TLS don’t have to worry about any of them. Add TLS, and now we do. I do agree with what you said above about just falling back to cleartext in case TLS doesn’t “work” for some reason. A TLS failure MUST NOT have an impact on availability.

   Scott

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 Feb 2021 09:43:52 -0800

On Tue, Feb 16, 2021 at 9:01 AM Ben Schwartz <bemasc=
[email-masked]> wrote:

> misconfiguration, bug, overload, or rollback) results in an outage
>

Why is this scary? We have ample evidence that it's possible to run high
availability services using TLS at much larger scale than pretty much any
authoritative server.  I realize that this is outside of the experience of
some [0] DNS operators, but it's not like the knowledge isn't out there.

-Ekr

[0] Though not all. Cloudflare, for instance, runs an authoritative service.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 16 Feb 2021 21:37:08 -0500 (EST)

On Tue, 16 Feb 2021, Ben Schwartz wrote:

>             I don't see why there would be a conflict between draft-ietf-dprive-opportunistic-adotq and any future authenticated encryption RFC that we produce, so I
>             don't see the need to impose a drastic dividing line (e.g. different port numbers).
> 
> 
> I explained that in my previous message. Opportunistic normally is “do encryption, then you may omit authentication if that is too hard”. Opportunistic is not “try this
> technology and maybe in the future try this completely other technology”.  

Only for the part of the document that is specified. The "sentinel" part
(or as the document calls is "transport cache" loading, is not defined.
So that part might end up being outside of a traditional TLS mechanism.
It is also the most problematic part of the document.

> 1. Mark draft-ietf-dprive-opportunistic-adotq "experimental".  This is in line with previous work on opportunistic encryption, e.g. RFC 8164, and accurately reflects the
> draft's status as both speculative and (hopefully) transitional.

Again, it seems Opportunistic Security is mis0used here. The document
says to basically use traditional TLS, but ignore authentication
failures. That's not how Opportunistic Security is defined. It is
defined as setting up a private channel, and then attempting to
channel bind some security property, but if that is not available,
to continue without it.

The mechanism proposed is authenticated security, but leaves out
the part of which PKI model to use, plastering it over as
"opportunistic".

> Serving under such a certificate would not violate this requirement.

So when receiving a ACME based certificate via TLS, you must ignore the
content completely other than the public key part of it ? Even if you
have a PKI that's usable? That is the reverse of opportunistic. You
are requiring a downgrade attack.

> I think the scary part is that an authenticated TLS failure (due to misconfiguration, bug, overload, or rollback) results in an outage.  draft-ietf-dprive-opportunistic-adotq never
> results in an outage; you just fall back to cleartext and pay a small latency penalty.

This isn't a problem for DNS. For HTTPS this is a problem because you
cannot fall back on anything else. For DNS, there is always port 53
if you TLS channel is that broken that you cannot use it (authenticated
or unauthenticated). This again shows that the difference between
opportunistic and authenticated TLS for DNS is such a small difference,
I really don't see an advantage to promote and deploy opportunistic.

Especially with how the document suggests to implement this.

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

Of course there is an advantage - preventing MITM attack if you can
authenticate anyway. The opportunistic part refers to the part where
IF POSSIBLE, you still do authentication. This is defining mandatory
downgrade.

    The recursive resolver MUST look in its transport cache before
    sending DNS queries to an authoritative server.  If there is no entry
    for an authoritative server in its transport cache, the recursive
    resolver MUST use classic DNS over port 53.  It MAY then probe for
    encrypted transports, and cache that information for later
    connections.

This is the worst course of action. It sacrifices potential privacy to
save 1RTT. This is not security. It is not even opportunistic security.
It is guaranteed privacy loss unless you use an unspecified method to
preload the "transport cache". The "MAY" is very strange here too. If
you don't follow the MAY, your "transport cache" remains empty forever,
and all you get is port 53 cleartext.

If you are willing to sacrifice DNS privacy to avoid 1RTT of cost, then
you are not building security. You are building a very dangerous false
sense of security and privacy for users. In practise, you are just
sending out cleartext DNS.

The draft as currently specified is _harmful_ to user privacy.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Tue, 16 Feb 2021 21:41:42 -0500 (EST)

> 2) Use WebPKI[*] for validation

as PaulH pointed out, the TLSA RFC does not allow one to accept a TLSA
RRset without DNSSEC signature protection. To allow for deployment
without DNSSEC, you could instead use the CERT RRtype that has no such
requirement.

Paul W

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 17 Feb 2021 03:51:00 +0000

> without DNSSEC, you could instead use the CERT RRtype that has no such

Well, not exactly. (Yes, I said that to PaulW when we were talking, but I was not being precise.)

RFC 6698 both defines the TLSA RRtype and a protocol to use it. The protocol defined in RFC 6698 indeed requires the TLSA record to be validated with DNSSSEC. However, a new protocol, such as one here, could use the TLSA record type in a different protocol, such as the one PaulW has above. The document that defines that protocol would have to be completely clear about what it was doing and why.

--PaulH