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

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

On Wed 2016-04-06 11:08:55 -0300, Colm MacCárthaigh wrote:
>  On Wed, Apr 6, 2016 at 6:03 AM, Daniel Kahn Gillmor <[e-mail]> wrote:
>
>  > 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.
>
>  I'd expect many operators to re-use ticket encryption keys for far too
>  long, as we see with HTTPS today, so the effect is that a dns server bug
>  may unlock years of 0RTT data. For DNS, the query is always likely to fit
>  in there.

This would be a good argument against doing any sort of session
resumption, i think, not just 0-RTT.

>  > 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.
>
>  There's a simpler attack too; if the RRSet contains multiple RRs, it's
>  common for resolvers to rotate the order of the RRs in a fixed and
>  predictable order. So you can query a name you suspect was queried, then
>  replay the target query, then query the name again, and confirm your
>  suspicion.

Just to make sure i understand this attack: suppose the rotation of two
RRs returned for a given response goes:

  A,B
  B,A
  A,B
  ...

Then the attacker would query, note the order, replay, then query again.
if the order received each time was the same, it's strongly suggestive
that it was the correct guess.  Is that the proposed attack?

>  This requires only a copy of the target 0RTT section, and access
>  to query the resolver, so a typical wifi scenario would do. Multi-RR
>  responses are very common these days too.

It strikes me that we should discourage privacy-sensitive resolvers from
employing this pattern. though i'm not sure where that documentation
would go or how to write it.  Is there a term for this kind of stateful
response history leakage?

thanks for pointing it out.

         --dkg