Re: [dns-privacy] [Ext] Fwd: Opportunistic encryption between recursive and authoritative servers

I think I largely agree with Paul Wouters here.

>From my perspective, in order to enable non-opportunistic
recursive-to-authoritative DNS we need two things:

1. A way to indicate that the server ought to have TLS.
2. A way to authenticate the server when you get there.

As Paul says (2) is a solved problem, either via WebPKI or TLSA
records.

(2) seems slightly more difficult, and I defer to DNS experts, but
I've seen a number of proposals here ranging from the principled to
the unprincipled (naming the server ns-i-speak-tls.example.com), so I
imagine the problem is soluble.

If you use TLSA records, you obviously need DNSSEC validation, but
that doesn't seem like that big a deal if you're already running a DNS
recursive.

If you use WebPKI, DNSSEC *does* help here in that it prevents whoever
served you the NS records for the authoritative from lying to you, but
it's not essential. For instance, if you do TLS to the authoritative
for .com and it refers you to ns-i-speak-tls.example.com, then an
on-path attacker cannot force you to not speak TLS, so this is a strict
improvement.

I don't deny that opportunistic TLS is of *some* benefit, but given
that non-opportunist is much stronger and doesn't seem much harder,
I don't think we should proceed with it. I especially do not think
that we should proceed with a version where both discovery of TLS
support *and* authenticating the server are optional. If we somehow
find that TLS discovery is difficult, then the right thing to do
is something HSTS-like, where the server has to have a valid cert
(or TLSA) but the client may discover that TLS is required through
an insecure path.

-Ekr

On Sat, Sep 12, 2020 at 9:34 AM Paul Hoffman <paul.hoffman@icann.org> wrote:

> On Sep 12, 2020, at 6:19 AM, James <james.ietf@gmail.com> wrote:
> >
> > 1. The absence of protocol agility bothers me - whilst I do not think
> the use case described in this document lends to DoH in particular being
> suitable, DoQUIC and not-yet-existent protocols could also be applicable.
>
> There is nothing in the current proposal that specifies the protocol that
> the two sides use. Additional protocol discovery methods can be added; we
> just didn't have any other desired protocols at this time.
>
> > Is there any reason besides simplicity you didn't consider using the
> ALPN as identifier?
>
> Simplicity counts. :-) However, if you want to use an ALPN method, this
> document certainly does nothing to prevent that.
>
> > 2. I disagree on the points around authentication and section 2 could be
> updated to better encourage adopters to implement matching TLSA records for
> the certificate they present during the TLS handshake - with a clear
> statement that recursives are not required to query this record type before
> TLS negotiation, nor explicitly fail if it mismatches.
>
> There is no value in opportunistic encryption to use DANE or any other way
> of authenticating the TLS server. Paul Wouters has said that he does not
> support encrypting more DNS traffic using opportunistic encryption, but so
> far has not written up his use case for regular (authenticated) encryption
> where some DNS lookups would be blocked due to inability to authenticate.
> Maybe you could write up such a use case and send it to this WG so they can
> compare use cases?
>
> --Paul Hoffman_______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>