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

[Colm MacCárthaigh <[e-mail]>]

On Sat, Apr 9, 2016 at 2:58 AM, Daniel Kahn Gillmor <[e-mail]>
wrote:
>
> >  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.
>

I intend more as an argument against the kind of session resumption that is
in TLS. Elsewhere the protocol has all sorts of reasonable limits on key
re-use, and they're enforced with decent mechanisms. But there's a gigantic
out in that ticket encryption keys are "outside" of  the protocols own
scope and so frequently they end up being a very weak point in the chain.
We should do something about that. I don't mean that session resumption as
a concept is a bad one.  I do mean that folks will hard-code those keys,
not rotate them nearly frequently enough, and that since DNS queries fit in
the 0RTT data the reality will be that a single key compromise could
uncover years of queries. Seems like a pretty big deal.

>  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?
>

Yep - you have it. It's easier too when there are more RRs, since the
signal is stronger, but an attacker can repeat the attack as many times as
necessary to gain confidence that they've identified the query.


> >  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?
>

Bind9 calls it "cyclic" rrset-order:

https://www.safaribooksonline.com/library/view/dns-bind/0596004109/ch03s19.html

but I'm not sure if it comes from a recommendation in any RFC - I couldn't
find one from a quick search.


-- 
Colm