Subject: [dns-privacy] Possible use case: Opportunistic encryption for recursive to authoritative

From: Paul Hoffman <[email-masked]>
Date: Thu, 6 Aug 2020 14:59:23 +0000

Greetings again. The following is a short text-based version of my slides from last week's WG meeting. I'd like to find out if this is one of the use cases that the WG would be interested in dealing with.

Use case: Opportunistic encryption for recursive to authoritative

In this use case, a resolver operator says “I’m happy to use encryption with the authoritative servers if it doesn’t slow down getting answers by much”, and an authoritative server says “I’m happy to use encryption with the recursive resolvers if it doesn’t cost me much”.

Opportunistic encryption is defined in RFC 7535. From the abstract: "Protocol designs based on Opportunistic Security use encryption even when authentication is not available, and use authentication when possible, thereby removing barriers to the widespread use of encryption on the Internet."

The assumptions behind the use case are:
• More encryption is good for the Internet
• Resolver vendors are smart and motivated
• Most resolvers don’t validate with DNSSEC and may never want to
• Authoritative operators don’t care much about encryption, but some would turn it on because more encryption is good for the Internet
• Other use cases for authentication stronger than opportunistic may appear and would co-exist with this one

The other slides had thoughts about possible solutions that implement this use case, but before we go there, I wanted to find out if more than a handful of people here are interested in this use case. If so, I could turn the above into a draft with some possible solutions for us to bang on.

--Paul Hoffman

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 6 Aug 2020 11:18:25 -0400

I think opportunistic or unauthenticated encryption is worth pursuing.
However, your quote also says "use authentication when possible", and I
agree.  I would like to avoid selecting an opportunistic encryption design
that doesn't match well with our authenticated encryption design, so I
think that means we need to develop them together.

On Thu, Aug 6, 2020 at 10:59 AM Paul Hoffman <[email-masked]> wrote:

> Greetings again. The following is a short text-based version of my slides
> from last week's WG meeting. I'd like to find out if this is one of the use
> cases that the WG would be interested in dealing with.
>
> In this use case, a resolver operator says “I’m happy to use encryption
> with the authoritative servers if it doesn’t slow down getting answers by
> much”, and an authoritative server says “I’m happy to use encryption with
> the recursive resolvers if it doesn’t cost me much”.
>
> Opportunistic encryption is defined in RFC 7535. From the abstract:
> "Protocol designs based on Opportunistic Security use encryption even when
> authentication is not available, and use authentication when possible,
> thereby removing barriers to the widespread use of encryption on the
> Internet."
>
> • Authoritative operators don’t care much about encryption, but some would
> turn it on because more encryption is good for the Internet
> The other slides had thoughts about possible solutions that implement this
> use case, but before we go there, I wanted to find out if more than a
> handful of people here are interested in this use case. If so, I could turn
> the above into a draft with some possible solutions for us to bang on.
>
> --Paul Hoffman
>
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 6 Aug 2020 15:32:43 +0000

> I think opportunistic or unauthenticated encryption is worth pursuing.  

Thanks.

> However, your quote also says "use authentication when possible", and I agree.  I would like to avoid selecting an opportunistic encryption design that doesn't match well with our authenticated encryption design, so I think that means we need to develop them together.

Fully agree. For every use case we adopt, the instantiation of it should not prevent other use cases from working well.

--Paul Hoffman

---

From: "John R. Levine" <[email-masked]>
Date: 6 Aug 2020 15:44:58 -0400

Yes, this is worth doing.  Agree with comments that it has to be 
compatible with non-opportunistic encryption.

R's,
John

PS: RFC 7435.

> The other slides had thoughts about possible solutions that implement this use case, but before we go there, I wanted to find out if more than a handful of people here are interested in this use ca…

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 6 Aug 2020 15:49:26 -0400

(speaking not as a chair)

I think this is worth doing.

tim

On Thu, Aug 6, 2020 at 3:45 PM John R. Levine <[email-masked]> wrote:

> > Greetings again. The following is a short text-based version of my
> slides from last week's WG meeting. I'd like to find out if this is one of
> the use cases that the WG would be interested in dealing with.
> >
> > • Authoritative operators don’t care much about encryption, but some
> would turn it on because more encryption is good for the Internet
> > The other slides had thoughts about possible solutions that implement
> this use case, but before we go there, I wanted to find out if more than a

---

From: Puneet Sood <[email-masked]>
Date: Fri, 7 Aug 2020 21:18:16 -0400

-Puneet

---

From: Rob Sayre <[email-masked]>
Date: Fri, 7 Aug 2020 18:21:53 -0700

> I think this is worth doing.

I agree. The part that I worry about is the computational cost of
reestablishing links after an outage. Is there a way to model this?
(Perhaps this work has already been done)

thanks,
Rob

---

From: Puneet Sood <[email-masked]>
Date: Fri, 7 Aug 2020 21:28:43 -0400

On Fri, Aug 7, 2020 at 9:22 PM Rob Sayre <[email-masked]> wrote:
>
> On Fri, Aug 7, 2020 at 6:18 PM Puneet Sood <puneets=[email-masked]> wrote:
>>
> I agree. The part that I worry about is the computational cost of reestablishing links after an outage. Is there a way to model this? (Perhaps this work has already been done)

Outage of the authoritative or resolver? Can you explain your concern
in more detail?

For a resolver an outage is similar to a cold start - the cost of
connection setup will be amortized over all the queries done during
the lifetime of the sessions.

-Puneet

---

From: Rob Sayre <[email-masked]>
Date: Fri, 7 Aug 2020 18:35:24 -0700

> Outage of the authoritative or resolver? Can you explain your concern

I meant an outage of the authoritative, or some substantial network link
connected to it.

> the lifetime of the sessions.

I agree that the recursive resolver's reliability concerns don't change
much with encrypted DNS.

Assuming this traffic is encrypted, which I am in favor of, the CPU load on
the authoritative server will increase after an outage or network problem.

Is this already factored in?

thanks,
Rob

---

From: Manu Bretelle <[email-masked]>
Date: Fri, 7 Aug 2020 18:56:33 -0700

Yes. I think it is worth doing.
Manu

---

From: "John Levine" <[email-masked]>
Date: 7 Aug 2020 22:04:42 -0400

>Is this already factored in?

How is that diffferent from now? If a DNS server is offline and comes
back online, it will see a bunch of queries. Or maybe not, if thrre
are other servers sharing the load, and depending on whether caches
remember authoritative servers that didn't answer and avoide
re-querying them for a while.

R's,
John

---

From: Rob Sayre <[email-masked]>
Date: Fri, 7 Aug 2020 19:12:28 -0700

On Fri, Aug 7, 2020 at 7:04 PM John Levine <[email-masked]> wrote:

> In article <
> [email-masked]> you
> write:
> back online, it will see a bunch of queries.
>

The issue is that connection establishment will be expensive, which is
something separate from getting a bunch of queries. As others have pointed
out, this cost will be amortized to almost nothing most of the time. After
an outage, this connection establishment cost will have to be dealt with in
parallel.

I don't have an opinion on whether this should be implementation guidance,
or even in the spec.

thanks,
Rob

---

From: Paul Wouters <[email-masked]>
Date: Thu, 6 Aug 2020 23:04:39 -0400 (EDT)

> I think opportunistic or unauthenticated encryption is worth pursuing. 

In general, yes. but ...

>       In this use case, a resolver operator says “I’m happy to use
>       encryption with the authoritative servers if it doesn’t slow
>       down getting answers by much”, and an authoritative server says
>       “I’m happy to use encryption with the recursive resolvers if it
>       doesn’t cost me much”.
>
>       Opportunistic encryption is defined in RFC 7535.

Poorly and confusingly and not as how people have used the term in the
past. So that document has just ruined the term. [I was asked to
co-author and refused]

The "opportunistic" part really means, "we will try encryption, but if
for whatever reason it does not work, we will fallback to
unauthenticated or even cleartext".

That is different from "Hmm, I'm busy, I'll just do cleartext for now".

Email is good example of where TLS is used alot with bogus certs, and
thus basically doing unauthenticated encryption. It's useful as it helps
against passive attacks.

In this case though, for auth servers, I see no reason to do
unauthenticated encryption. There are usually two reasons for
unauthenticated encryption. The first is that the party wants to
remain anonymous (eg most HTTPS clients). The second is that it is
too hard for entities to get a veriable ID in a trustworth PKI.

In the case of encrypted DNS to authoritative servers, those servers
obviously can have an cryptographic ID based on FQDN. And
"opportunistic" then really means "you should do it and hardfail if
there is an issue".

>       • More encryption is good for the Internet

Sure.

>       • Resolver vendors are smart and motivated

Some are, and a lot are not.

>       • Most resolvers don’t validate with DNSSEC and may never want

This is not true anymore. And even if it were, we should encourage those
to upgrade. At the IETF, we have done a REALLY bad job at keeping secure
DNS as an optional feature. The more we treat it that way, the more
others will treat it that way. We should really do the opposite. DNS
without DNSSEC is legacy. It's irresponsible. It's vulnerable. It's
being actively abused. Upgrade your DNS.

Then, you automatically get to AUTH servers having a DNSSEC based PKI.
You can give them a public key record type like TLSA, and do encryption.
You allow plaintext, and in 10-20 years we turn off plaintext.

>       • Authoritative operators don’t care much about encryption

I don't think that is true either. If they could install an ACME like
client and get fully automated optional encryption, I bet most would
just turn it on.

>       • Other use cases for authentication stronger than opportunistic
>       may appear and would co-exist with this one

Opportunistic for _this case_ is just too weak. We have a PKI system
with DNSSEC that is core to these DNS servers already. We basically
get the PKI for free, so just do it authenticated.

Another item that keeps coming up is people fearing an extra RTT on a
DNS connection to an AUTH servers to pull the public key. DNS already
has caching and for DNS encryption to yield anonimity, it has to be done
with nameservers hosting thousands or millions of zones anyway. Or else
encryption doesn't buy you anything. You can take that 1 RTT for
ns0.dreamhost.com or ns1.godaddy.com to get encryption for a few
thousand domains. No need back DS hacking of public keys.

>       The other slides had thoughts about possible solutions that
>       implement this use case, but before we go there, I wanted to
>       find out if more than a handful of people here are interested in
>       this use case. If so, I could turn the above into a draft with
>       some possible solutions for us to bang on.

We should work on adding encryption and moving towards an encryption
only solution. Not wishy-washy opportunistic with fallbacks. Not for
DNS.

Paul

---

From: Brian Haberman <[email-masked]>
Date: Sat, 8 Aug 2020 14:57:00 -0400

Does anyone have numbers on how many authoritative servers use anycast
for load balancing?

Brian

---

From: Ask Bjørn Hansen <[email-masked]>
Date: Sat, 8 Aug 2020 14:54:29 -0700

> On Aug 8, 2020, at 11:57 AM, Brian Haberman <[email-masked]> wrote:
> 

I don’t have data (and haven’t looked into it recently), but I think it’s a very safe assumption that

- most of the authoritative servers don’t use anycast
- most authoritative queries (for an average resolver) go to servers that use anycast

Ask

p.s. If you meant “for load balancing” to narrow which anycast deployments you are counting then it’s impossible to figure out unless you talk to each operator to find out what their motivations to use anycast were — performance, load balancing, resiliency, …

---

From: Paul Ebersman <[email-masked]>
Date: Sat, 08 Aug 2020 16:09:39 -0600

ask> I don't have data (and haven't looked into it recently), but I think
ask> it's a very safe assumption that

ask> - most of the authoritative servers don't use anycast

ask> - most authoritative queries (for an average resolver) go to
ask>   servers that use anycast

I'd disagree. There's been huge consolidation in the DNS operator
business and the vast majority of domain names are served by a fairly
small number of really large operators' auth servers.

Anycast for auth makes sense for robustness and resilience while not
inflating the number of listed NSs (keeping packet size small).

Combine that with most of the world using a smaller number of recursive
operators who also widely distibute via anycast and you wind up with
auth and recursive operators being in most of the same cities and data
centers and close to each other. This means cache misses aren't that
much slower than cache hits. Clients get fast answers, zones are
robustly and quickly served, everyone wins.

Whether centralization as a trend is good has already been argued on
this list and others plenty of times. ;)

There is definitely a choice or tradeoff between speed/robustness and
privacy.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 8 Aug 2020 23:39:57 +0000

Sorry to break in, but what does the question of number of anycast auth servers have to do with this use case? Or did y'all mean to start this as a thread for draft-ietf-dprive-phase2-requirements, in which it could be relevant?

--Paul Hoffman

---

From: Peter van Dijk <[email-masked]>
Date: Mon, 10 Aug 2020 10:53:28 +0200

On Thu, 2020-08-06 at 23:04 -0400, Paul Wouters wrote:
> obviously can have an cryptographic ID based on FQDN.

This is not obvious. It would be great if it was; but it isn't.

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

---

From: Peter van Dijk <[email-masked]>
Date: Mon, 10 Aug 2020 11:00:59 +0200

On Fri, 2020-08-07 at 19:12 -0700, Rob Sayre wrote:
> The issue is that connection establishment will be expensive, which is something separate from getting a bunch of queries. As others have pointed out, this cost will be amortized to almost nothing most of the time. After an outage, this connection establishment cost will have to be dealt with in parallel.
> 
> I don't have an opinion on whether this should be implementation guidance, or even in the spec.

In the DS pinning draft, we explicitly decided to leave this out of scope, as we wouldn't want to prescribe resolver behaviour for other discovery methods (such as opportunistic). Sensible handling of connection establishment and pooling feels like a separate topic to me, so I don't think it should be part of any discovery document. I am unsure it should be an IETF spec at all.

Kind regards,

---

From: Brian Haberman <[email-masked]>
Date: Mon, 10 Aug 2020 07:38:35 -0400

Hi Paul,

> Sorry to break in, but what does the question of number of anycast auth servers have to do with this use case? Or did y'all mean to start this as a thread for draft-ietf-dprive-phase2-requirements,…

I asked the question in relation to the use case since the use of
anycast with any stateful security mechanism tends to raise concerns. If
authentication of the authoritative is of interest, there is also the
issue of managing consistent credentials across all servers responding
to the same anycast address.

Regards,
Brian

---

From: Tony Finch <[email-masked]>
Date: Mon, 10 Aug 2020 23:28:40 +0100

Paul Wouters <[email-masked]> wrote:
>
> At the IETF, we have done a REALLY bad job at keeping secure DNS as an
> optional feature. The more we treat it that way, the more others will
> treat it that way. We should really do the opposite. DNS without DNSSEC
> is legacy. It's irresponsible. It's vulnerable. It's being actively
> abused. Upgrade your DNS.
>

+1

(and to the rest of the message too)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Isle of Man: North or northwest, veering northeast for a time, 3 or 4,
occasionally 5. Slight. Thundery showers, becoming mainly fair. Moderate or
good, occasionally poor.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 11 Aug 2020 21:49:57 -0400 (EDT)

> This is not obvious. It would be great if it was; but it isn't.

Sorry, I did not realise it was not obvious to everyone, so let me
clarify:

_853._dot.ns0.nohats.ca. IN TLSA <blob>
_443._doh.ns0.nohats.ca. IN TLSA <blob>

This uses the unique FQDN of each nameserver's name. You can have
multiple TLSA records if you use different keys on some of your
nameservers (eg some outsourced to an ANYcloud provider)

Note that this scales with the nameserver. For example by publishing the
above, the libreswan.org domain would also have dot/doh published as it
is using the same nameservers.

I would not understand why one would insert another PKI system to
identify nameservers as. It would just add dependencies and different
protocols to the solution.

Paul

---

From: Peter van Dijk <[email-masked]>
Date: Wed, 12 Aug 2020 12:51:34 +0200

(I changed the subject because this has turned into a solution
conversation, instead of a use case conversation)

> _443._doh.ns0.nohats.ca. IN TLSA <blob>

Yes, that part seems obvious (if we assume the records live with the
child, which I guess is obvious from your 'national MITM' argument in
other threads). Many other aspects are not obvious. Some examples
follow.

Delegation NS records are not signed, so do we stick -those- (or a hash
of the NSset perhaps?) into DS?

Can we find those TLSA records without leaking the names of the name
servers we are looking for, or do we decide that name server names are
not a privacy leak?

Do we move delegation-revalidation from 'possibly later' to 'always do
that first', so that we get signed NS records before we look for TLSA?

Do we expect resolvers to issue a couple of TLSA queries per NS before
getting to the actual end user's question?

'Put TLSA records in your zone' is not a protocol. I'm sure we can
define a protocol that revolves around TLSA, but your description is
not yet it. That is what I mean by 'this is not obvious'.

> nameservers (eg some outsourced to an ANYcloud provider)

Assuming you use vanity names in the outsourcing (i.e. ns5.nohats.ca is
actually a CloudFlare name server). If you don't use vanity names, the
scaling mentioned just below comes for free because the outsourced
operator would own the TLSA records (i.e. nohats.ca IN NS
paul.cloudflare.com).

> is using the same nameservers.

This, to me, is the main selling point of tying key publication to NS
names instead of zone names.

Kind regards,

---

From: Vladimír Čunát <[email-masked]>
Date: Wed, 12 Aug 2020 14:44:19 +0200

> In this use case, a resolver operator says “I’m happy to use encryption with the authoritative servers if it doesn’t slow down getting answers by much”, and an authoritative server says “I’m happy…

This motivation confuses me a bit, but perhaps it's just me.  I'd expect
the extra performance costs to be quite close to authenticated
encryption, at least in principle.  And the extra privacy gain feels
relatively small in comparison.

In any case, there may be other common motivations for going
opportunistic.  For example the fact that for years we don't seem to
really move towards consensus about how exactly the authentication could
be done, but that motivation would be incompatible with desires like
developing these two approaches together - and I must admit I'd really
like to minimize incompatibility among the future approaches (DoT and
DoH come into mind).  I'm sorry if I sound too negative.

--Vladimir

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 12 Aug 2020 16:00:56 +0000

On Aug 12, 2020, at 5:44 AM, Vladimír Čunát <[email-masked]> wrote:
> encryption, at least in principle.  

Yes, definitely.

> And the extra privacy gain feels

The privacy gain is preventing passive snoopers from being able to see the traffic. That seems important to some people, not to others.

> DoH come into mind).

> • Other use cases for authentication stronger than opportunistic may appear and would co-exist with this one

As folks with other use cases for authenticated (normal!) encryption clarify their use cases, nothing in the opportunistic use case should make their work any harder.

--Paul Hoffman

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 12 Aug 2020 20:11:12 +0300

> of the NSset perhaps?) into DS?

Note that DNS does not guarantee coherence between record types, so
that would presumably need to be individual NSnames.

> servers we are looking for, or do we decide that name server names are

I think that the destination IP mostly gives away the name server name.

It is zone name that should be treated as sensitive if at all possible,
and should not be disclosed to unauthenticated servers.

> that first', so that we get signed NS records before we look for TLSA?

I don't see obvious connection between this and delegation-revalidation.
 
> getting to the actual end user's question?

Issuing the TLSA queries can be problematic if the nameserver is
in-zone. Things get even worse if nameserver is located in child zone
of zone it serves (thankfully, I do not think the latter happens much).

And thinking about it, one would also need to use dedicated connection
(or unencrypted UDP) for the queries, because otherwise leaks information
about the zone if the nsname is inside one of the zones it is serving.
Reusing the connection would also need post-hoc authentication, which is
nontrivial to implement correctly.

Getting around these would need stapling.

Also, if nameserver already has authenticated connection to the same
nameserver, there is no need to open another one to issue queries for
different zone.

> not yet it. That is what I mean by 'this is not obvious'.

And presumably the records would have to have usage 2 or 3, as there
are no built-in trust anchors (or at least I hope so!).

> names instead of zone names.

In general it is useful to consider who should control a piece of data
and how to give that party actual control of it.

In this case, nameserver operators should control their authentication
keys.

-Ilari

---

From: Paul Wouters <[email-masked]>
Date: Wed, 12 Aug 2020 15:50:33 -0400 (EDT)

> other threads). Many other aspects are not obvious. Some examples

It seems regardless of where in the DNS these cryptographic ID's are
placed, that we agree on using the DNS, and thus DNSSEC ?

The "obvious" part only referred to "use DNS records to authenticate
DNS authoritative servers".

The rest of this email is about one of the specific solution proposals.

> of the NSset perhaps?) into DS?

I don't think so. The DS is signed, and following that path, it hardly
matters where the NS records point to. Do you fear that you will receive
bad NS records from the parent, who will than MITM you by relaying
DNSSEC payloads from the real authoritative server, and thus losing privacy
that way? While that is true, there is not much the child can do to
prevent this, other than 1) monitoring and 2) use CNS records so you can
verify the parental glue based on the DS published key. So that at least
ensures it again only comes down to DS record forging the parent would
have to do (see also delegation_only draft)

> servers we are looking for, or do we decide that name server names are

Hiding nameserver names is pointless, as you will just open up an
encrypted TLS connection to those IP addresses anyway. Any attacker can
do a reverse lookup of that IP. There are commercial entities selling
current and historic NS/WHOIS information. So yes, I don't think you
can gain any privacy by protecting the nameserver names.

> that first', so that we get signed NS records before we look for TLSA?

That could be a local policy? Just like the hardening options in unbound
are now a local policy.

> getting to the actual end user's question?

Yes. The price per nameserver is pretty small. Especially seeing some
nameservers already verify parental glue at the child zone with DNSSEC.
It could possibly even come in as Additional Data that way to save
an RTT.

> not yet it. That is what I mean by 'this is not obvious'.

We were talking about different things then. Hopefully this email
cleared that up.

> operator would own the TLSA records (i.e. nohats.ca IN NS

I don't understand the "vanity name" ? nameervers have unique names,
whether vanity or not, with the exception of any cast servers. We would
hope anycast servers would share the same or a small subset of keys that
can be handles with one or a few TLSA records at the same nameserver
name.

> names instead of zone names.

Yes, and to circle back to Paul Hoffman's point. I think this is an
essential property. The nameserver operators own the key and they
should be able to change their keys without DS updates by another
party - especially when those nameservers are hosting thousands of
domains.

What is then left is the question "is there any information worth
putting into the DS record with respect to encrypted connections
to nameservers for the domain" ?  I think we could have a bit of
information that says "I expect my nameservers have DoT or DoH",
which would allow resolvers to skip attempting this if the bit is
not found. Although a recursive might still decide to try and lookup
TLSA records anyway to support registrars/registries that cannot or
will not allow these DS records.

So as for the solution space, I now think no bits are needed
within the DS record, but it could very well be that someone
still has a good use for it that we want to support.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 12 Aug 2020 20:56:48 +0000

> DNS authoritative servers".

That phrase over-simplified. A more accurate phrasing would be "use a chain of DNS records to authenticate DNS authoritative servers". There are many ways that the chain could break, or might not even exist. The web PKI is full of single-link trust anchors. There are many ways that trusting a single link could be dangerous as well.

Some of us don't find either of those as obvious as you do.

--Paul Hoffman

---

From: Vladimír Čunát <[email-masked]>
Date: Thu, 13 Aug 2020 01:50:08 +0200

On 8/12/20 9:50 PM, Paul Wouters wrote:
> that way?  [...]

That parent may not be using a secure transport (e.g. root isn't
expected to), in which case anyone on path may be a MITM.  I suppose in
that case we could use the NS to obtain DNSSEC proof for itself, but
adding this half-secure phase would seem to complicate stuff, and you
probably don't want to ask deeper than the apex until MITM is disproven
(leaking additional labels and allowing the MITM to deepen the attack).

---

From: Paul Wouters <[email-masked]>
Date: Wed, 12 Aug 2020 21:58:15 -0400

On Aug 12, 2020, at 19:50, Vladimír Čunát <[email-masked]> wrote:
> That parent may not be using a secure transport (e.g. root isn't expected to), in which case anyone on path may be a MITM.  I suppose in that case we could use the NS to obtain DNSSEC proof for itself, but adding this half-secure phase would seem to complicate stuff, and you probably don't want to ask deeper than the apex until MITM is disproven (leaking additional labels and allowing the MITM to deepen the attack)
> 

Query minimalisation and unbound’s hardening options for infrastructure records would do this already with today’s software configuration.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 18 Aug 2020 17:38:47 -0400

> >       Opportunistic encryption is defined in RFC 7535.

Minor correction, for the record, 7435.

> unauthenticated or even cleartext".

In 7435 it means "when it is discovered to be possible", as opposed to
(e.g. https) simply mandatory.  Now what "discovered to be possible"
can mean different things in different protocols:

    - Some protocols, like basic STARTTLS in SMTP, are vulnerable to
      active attacks, but do a decent job of protecting most conent
      against passive wiretap.  (Traffic analysis can still reveal a
      great deal about communication flows, even absent the clearttext
      payload).

    - Other protocols, like opportunistic DANE TLS (RFC7672), are
      resistant to downgrade attacks, but still "opportunistic"
      because the use of DANE TLS is not an a priori requirement,
      rather support for the protocol by the server is discovered
      in real time, and the protocol is applied to servers with
      signed TLSA records, and otherwise ordinary STARTTLS (and
      perhaps even cleartext if STARTTLS appears to be absent
      or broken) is used.

> too hard for entities to get a veriable ID in a trustworth PKI.

If the signalling channel that indicates support for resolver to auth
TLS is authenticated and downgrade resistant, then it indeed makes sense
to consider opportunistically (i.e. based on real-time discovery)
enforcing authentication.

A bit more caution may however be appropriate in the case of DNS than
with SMTP.  Some early adopters of DANE for SMTP (a small, but not
entirely negligible minority, around 4% by SMTP server count, but only
~500 out of >2 million DANE-enabled domains) are having a bit of trouble
keeping the TLSA records accurate, but given the asynchronous nature of
email, are doing mostly OK, provided they fix the records in a few hours
to even a day or two.  A similar transient outage in DNS would not
generally be acceptable.

However, the very problem that they are having of keeping the certs on
the SMTP server matching the keys on the DNS server, is far easier to
solve on the DNS servers, provided they are authoritative for the
zone(s) with their own names, in which case including the correct TLSA
RRs can be largely automated, in much the same way that the RRSIG
and NSEC chain generation is automated.  The primary server just needs
a secure channel to retrieve new public keys for the secondaries.

So before standardising opportunistic DANE for DNS, I look for a draft
that covers the key management lifecycle.  If there's a solid way to
automate key rollover after initial enrollment, then we can expect
to see DANE authentication to "just work" in DNS.

Otherwise, the "opportunistic" protocol would be more modest in
its goals and would only achieve unauthenticated TLS when it
appears to be possible, without downgrade protection.

> get the PKI for free, so just do it authenticated.

Right, but we should also do it *well*, which means that key lifecycle
automation should be part of the design from day one.

-- 
    Viktor.