Hi All,
Thanks Paul and Tony for digging into this. I've been thinking
about this from a user perspective, but my desired user
perspective behaviour influences the recursive resolver behaviour.
As I see it, the problem with downgrade attacks is when the user
is unaware of the fact that this is occuring. My user persepctive
requirement is that I know which of the following states my DNS
queries are being made by the recursive resolver: cleartext,
encrypted (but unautheniticated) or encrypted and authenticated.
I would like some visual representation of the status, similar
to the http/https visualisation in modern web browsers. But,
that is a client side implementation choice. To do it though,
we need to know what the status is.
Thus, I am proposing that this information is included in the
client (stub) to recursive resolver protocol. Could EDNS be used
to do this?
With this information available, one can do opportunistic encryption
and/or authentication and not require downgrade attack prevention but
push that risk to the end user. This may be unwise, but I leave
that the community's wisdom.
Regards,
Hugo Connery
On Tue, 2018-10-02 at 19:57 +, Paul Hoffman wrote:
> On Oct 2, 2018, at 11:26 AM, Tony Finch wrote:
> >
> > Paul Hoffman wrote:
> > > On Oct 2, 2018, at 3:12 AM, Tony Finch wrote:
> > > > Paul Hoffman wrote:
> > > > >
> > > > > I do not have a scenario where the client (the resolver in
> > > > > this case)
> > > > > needs downgrade protection for privacy.
> > > >
> > > > In that case there's no need to worry about authentication at
> > > > all.
> > > > (But I disagree.)
> > >
> > > And I disagree that there is "no need to worry". As I said in my
> > > initial
> > > message, a resolver operator might want to take advantage of it
> > > if it is
> > > available.
> >
> > I don't understand: first you say you don't need downgrade
> > protection,
> > then you say you want authentication.
>
> Yes, exactly.
>
> > This isn't consistent.
>
> Yes, it is. Note the difference between "need" and "want".
>
> > You aren't
> > taking advantage of authentication if you are vulnerable to a
> > downgrade
> > attack.
>
> If I have a path with authentication and a path without, and I prefer
> (not demand) the path with authentication, I am taking advantage of
> it.
>
> > In that case the authentication is worthless.
>
> We disagree. To me (and clearly to many others), it has worth when it
> is used.
>
> >
> > > > More generally, I don't think the term "opportunistic" is very
> > > > helpful,
> > >
> > > but it is the hard-fought agreement of the IETF. See RFC
> > > 7435.
> >
> > Yeah, and the point I am making is that it is important to pick
> > apart the
> > teo options described in RFC 7435's abstract. They have very
> > different
> > deployment characteristics and security guarantees. For protocols
> > like
> > SMTP or DNS there isn't an easy identifier that can be reliably
> > authenticated,
>
> Why not? IP addresses work just fine in both of those cases. The web
> world has decided that domain names are good enough identifiers for
> them, so other worlds might use them as well.
>
> > so authenticated encryption needs extra deployment work
> > (e.g. DANE) to be reliable,
>
> DANE works as well, but it is not the only possibility, depending on
> your use case. If you want to stay within the single-root DNSSEC
> model, DANE works great today, and there have already been proposals
> here for protocol extensions to make domain names and IP addresses
> work as well if we authenticate them on the parent side of a zone
> cut.
>
> > and if you do that work you get downgrade
> > protection as a bonus. If you don't do the extra work you can do
> > unauthenticated encryption, but you remain vulnerable to active
> > attacks.
> > If you do the extra work without including downgrade protection
> > then you
> > might as well not have bothered.
>
> Again, we disagree. Some resolver operators want to get good security
> when they can get it, and are willing to do a little work to get it.
>
> > Perhaps I should say that this strict security can only apply if
> > both the
> > server advertises it and the client looks for it; if either of
> > those don't
> > apply then you get unauthenticated opportunistic encryption, which
> > is OK,
> > but we can do better when both ends want to be secure.
>
> Yes, that would be good to say. :-) It then does not denigrate the
> people who don't need strict security but want to use what RFC 7435
> describes as opportunistic.
>
> --Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
