On 2/27/15 2:30 AM, John Heidemann wrote:
On Thu, 26 Feb 2015 12:51:23 +0000, Stephen Farrell wrote:
Hiya,
On 26/02/15 12:43, Brian Haberman wrote:
Are you thinking of looking at patterns of qname values/labels or
just some number of packets going towards a DNS resolver within a
certain time frame?
If it is the latter, I think it is out of scope since that type of
analysis can be done on any type of traffic. If it is the former,
I agree that such analysis can be prevented with encryption of DNS
queries going to the resolver.
I was thinking of the former, so in scope:-)
However, even considering the latter, if we define some confidentiality
service and if that does include some form(s) of padding then it may
also be possible to mitigate analysis based on message sizes and numbers
of packets. That is jumping ahead a whole bunch of steps though.
This kind of deanonymization is one class of side-channel attack.
If we start down that path, there are many, many side-channels that leak
information that could potentially do similar things. If one looks at
side-channel attacks on crypto protocols, folks get very clever, and one
can see dozens of years of cleverness. (The wikipedia page lists 6
classes of side-channel attack on crypto.)
We shouldn't minimize side-channel attacks, BUT in the interests of
finishing a document, it seems like at some point the document needs to
say something like "there are other classes of side-channel attack that
are not considered here".
-John Heidemann
Perhaps with a reference to the literature on side-channel attacks. But I
agree, unless there are specific attacks that can be spelled out, we should
avoid getting bogged down.
tim
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
