On Tue, 16 Feb 2021, Ben Schwartz wrote:
On Tue, Feb 16, 2021 at 11:19 AM Paul Wouters <[email protected]> wrote:
On Feb 16, 2021, at 10:23, Ben Schwartz
<[email protected]> 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.
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:
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".
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.
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
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
