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

[Viktor Dukhovni <[e-mail]>]

On Thu, Aug 06, 2020 at 11:04:39PM -0400, Paul Wouters wrote:

> >       Opportunistic encryption is defined in RFC 7535.

Minor correction, for the record, 7435.

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

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.

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

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.


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

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

-- 
    Viktor.