Re: [dns-privacy] DNS + 0-RTT

[Daniel Kahn Gillmor <[e-mail]>]

On Tue 2016-04-05 14:07:27 -0300, Tim Wicinski <[e-mail]> wrote:
> As many of you are aware, with the TLS1.3 spec, there is some security 
> concerns around DNS+TLS1.3 0-RTT.  dkg put together some threat models 
> and instead of forwarding some long thread, I figure I would put this 
> out there and let Mr. Gilmor lay out his theories.

Thanks for the nudge, Tim!

There are several different subtle security considerations with 0-RTT:

 a) no client authentication
 b) limited forward secrecy
 c) no replay protection
 d) client linkability

I assume we're not talking about DTLS here, so i'm going to omit any
concerns about:

 e) UDP-style spoofing/flooding/reflection attacks

Have i missed anything?

Also, i might be confused below about the state of 0-RTT and how it
relates to PSK and session-resumption, though i'm more confident in my
understanding based on the TLS WG discussion yesterday.  But please
correct me if i'm confused!

client auth
-----------

For standard DNS traffic, i think we don't care about property (a).
that's good!

forward secrecy
---------------

IIUC for (b), the failing forward secrecy window is constrained by the
duration of the PSK/session resumption ticket.  That's doesn't seem
particularly worrisome to me for DNS.

replay protection
-----------------

For DNS we don't particularly care about replay attacks initially, but
replayable traffic might have some privacy implications.

For example, if Mallory can monitor the traffic to and from the DNS
resolver, and a TLS-wrapped DNS request is made that is answered from
the cache, then the attacker has no additional information about what
the answer is.

But if the request is replayable, Mallory can capture it, and replay it
at different intervals (when parts of the cache might be expired) to try
to coax the recursor to call out to the authoritative resolvers, which
might provide more information about the original query.

This is a minor leak, but probably not something to completely ignore.

client linkability
------------------

(this is in some sense the inverse of "no client authentication": we're
worried that the protocol might allow the server (or others) to identify
clients with greater precision than the client wants)

The TLS client doing 0-RTT can be linked by the server to their previous
session. If the client constrains itself to using each resumption ticket
exactly once, then it limits its linkability exposure to the DNS server.
If the client reuses the resumption ticket, then its sessions are
linkable by any network monitor.

Note that persistent TLS sessions that carry multiple DNS queries of
course have the same "linkability exposure" for queries within a single
TLS session, so it's not *just* a problem for 0-RTT.  and non-0-RTT
session resumption has exactly the same linkability exposure as 0-RTT,
aiui.  So this concern isn't specific to 0-RTT, but if a client wants to
limit its linkability exposure i think it will by definition limit its
use of 0-RTT.

What are the privacy risks of linkability?

 * The DNS server can establish a profile of a given user and their
   interests, even distinguishing between different users behind a LAN
   (or on a shared host with separate resolver sessions)

 * the DNS server (or network observer, in the case of reused session
   tickets) can track a given user as they move across the network,
   unless the client flushes its resumption cache upon network change.

Sadly, this linkability exposure risk is a net loss compared to
cleartext DNS, even compared with cleartext DNS with EDNS0 cookies :/

---------------

So, in conclusion, i think that DNS+TLS-1.3+0-RTT is not too scary.

That said, i'm not convinced that the savings of one round trip time is
particularly significant for the stub-to-resolver use case.  If the
connection is a long-standing connection that stays open (as we expect
for stub-to-resolver), the extra 1-RTT is amortized across lots of
queries; so it's not clear that connection setup speed is as important
in this case.

If we could have a story about how to mitigate the replay attack
concerns (which are already pretty minor), then the linkability concerns
are the only thing that remain, and those can be mitigated by
client-side policy about session ticket reuse (which would basically
extend to policy about when to use 0-RTT and when not to)

I'd be curious to think through how this all relates to TCP Fast Open if
anyone wants to brainstorm it with me.

       --dkg