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

[Erik Sy <[e-mail]>]

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.

>   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. Subsequently, if the connection does not provide
server authentication, the client evaluates a fallback DNS record
retrieved via the traditional DNS. 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.
>
>