Re: [Resolverless-dns] Paper on Resolver-less DNS

[Ted Hardie <[e-mail]>]

Hi Erik,

Thanks for your reply.

On Thu, Aug 15, 2019 at 1:25 PM Erik Sy <[e-mail]>
wrote:

> Hi Ted,
>
> On 8/15/19 19:57, Ted Hardie wrote:
> >  From my perspective, the push-based DNS record approach is most risky
> > for this latter set of risks.  The document currently says:
> >
> >     First, clients are only allowed to send application data over an
> >     established connection ifthey validated the server’s identity via
> >     a server authentication mechanism or a fallback DNS lookup. Figure
> >     2 presents the validation strategy applied by user agents on DNS
> >     records retrieved via resolver-less DNS
> >
> >
> > I can't reproduce the diagram here, but my reading is that you can use
> > this DNS data if you have cached TLS resumption ticket or equivalent;
> > in that case, you can start the 0-RTT exchange knowing the other side
> > will be able to see the application data only if they have the right
> > cryptographic materials.  This misses the risk that establishing a
> > connection may leak private information*.
>
> The problem you are describing is not introduced by resolver-less DNS. A
> traditional DNS resolver can conduct the exact same attack by
> distributing fake DNS records and observe the client's connection
> establishment.
>
>
Agreed, but your proposal appears as written to allow any web server to try
the attack, where it was formerly limited to a configured resolver.  Unless
I misunderstand the proposal, that a significant change in attack surface.


> >   It also create a new, fun dependency in the already confusing
> > interaction of cache lifetimes.  The DoH style method creates an
> > interdependence between DNS TTL and HTTP cache lifetimes; this creates
> > one with the ticket lifetime.
>
> I feel like you possibly misunderstood the validation strategy. I
> proposed an opportunistic approach, where the client always attempts a
> connection establishments towards the IP address retrieved via
> resolver-less DNS.


You're right, I misread it.  I thought you were saying that the client
should try only in the case where it had the TLS resumption ticket and
should fall back *before attempting the resolution* otherwise.  You may
want to update the text pointing to Figure 2 or Figure 2 to make that
clearer.


> Subsequently, if the connection does not provide
> server authentication, the client evaluates a fallback DNS record
> retrieved via the traditional DNS.


This seems to indicate that the attack I mentioned earlier is much easier
to mount as both tracks in Figure 2 allow it.  It also raises the risk that
a client will receive a server authentication from a CA not intended by the
domain owner (our friend the enterprise, an attacker, a government, etc.).
We have some mitigations for that, but they are not complete.

Unless you somehow limit the number of domains a web server can provide DNS
records for in some way that approximately matches their own URL authority,
this seems fairly risky to me.   You can eliminate the risk for a DNSSEC
validating application if the DNS records allow the validation to occur.
But that is not, at least yet, common.

regards,

Ted


Thus, I do not understand why an
> interdependence with the ticket lifetime is created.
>




>
> Erik
>
> >   RFC 5077 says this:
> >    A client SHOULD delete the ticket and associated state when the time
> expires.
> >    It MAY delete the ticket earlier based on local policy.  A server MAY
> >    treat a ticket as valid for a shorter or longer period of time than
> >    what is stated in the ticket_lifetime_hint.
> > If you know a server sets 0 or a long lifetime, in other words, you
> > may be able to guess that a session ticket is available, but otherwise
> > it is a crapshoot either for the benign DNS-record supplying host or
> > an attacker.
> >
> > Given the large number of cases that will have to follow fallback DNS
> > lookup for the authentication, I think this a useful building block
> > only for very popular services (since they are likely to be in the
> > cache).  Given the other resources they have and the reputational risk
> > of allowing random sites to provide DNS records related to them, I'm
> > not yet sure that this is worth it.
> >
> > Ted
> >
> > *Imagine you are a government which wishes to detect when citizens use
> > GRINDR, as you disapprove of same sex encounters.  You can have
> > government  and affiliated sites push GRINDR DNS records using this
> > method; when someone with a fresh TLS ticket for GRINDR tries to
> > connect, you get their IP address and whatever other data leaked in
> > the exchange.  You can limit this risk in various ways (e.g. by
> > requiring the presented TLS certificate of the DNS-record supplying
> > host have the domain in its list of alternative names), but this
> > limits the effectiveness of this method and also runs the risk that
> > governments may have root certificates that can generate those.
> >
> >
>
>
>
> --
> Resolverless-dns mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/resolverless-dns
>