Subject: [dns-privacy] Start of WGLC for draft-ietf-dprive-problem-statement - please review.

From: Warren Kumari <[email-masked]>
Date: Mon, 23 Feb 2015 17:36:28 -0500

Dear DPRIVE WG,

The authors of draft-ietf-dprive-problem-statement have indicated that
they believe that the document is ready, and have asked for Working
Group Last Call.

The draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dprive-problem-statement/

This document was discussed at the DPRIVE meeting at IETF91 - some
notes here: http://tools.ietf.org/wg/dprive/minutes?item=minutes-91-dprive.html

The document has also been worked on in GitHub, here:
https://github.com/bortzmeyer/my-IETF-work
It has also received a fair bit of on-list discussion.

Please review this draft to see if you think it is ready for
publication and send comments to the list, clearly stating your view.
Even if you previously expressed support for the document (e.g during
adoption), please respond to the WGLC showing that you still support
it.

This WGLC ends Mon 09-Mar-2015.

In addition, to satisfy RFC 6702 ("Promoting Compliance with
Intellectual Property Rights (IPR)"):
Are you personally aware of any IPR that applies to
draft-ietf-dprive-problem-statement?  If so, has this IPR been
disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879,
3669, and 5378 for more details.)

Thanks,
Warren Kumari
(as DPRIVE WG co-chair)

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 26 Feb 2015 03:13:19 +0000

This document is very good stuff, many thanks. I think it ought
go forward regardless of how my comment below is dealt with.

One issue I don't think is covered well enough is the potential
(I don't know if this is actual) risk of re-identification via
sets of DNS queries.

Imagine the adversary identifies a user somehow, and then records
that that user sends queries for a set of names within some time
window. Perhaps due to a browser "opening all" bookmarks in tabs,
or due to some sequencing of application startups on reboot. In
any case, the adversary recognises some pattern in DNS queries
that is unlikely to be seen at random.

If the adversary later sees a matching set of DNS queries within
a time window, then the adversary may have re-identified the victim
without any other knowledge, and e.g. might be able to see the IP
address of the victim and then leverage that to launch further
attacks or simply to add additional tracking information to the
victim's surveillance "history." Equally, the adversary might get
this wrong, and incorrectly claim re-identification with possible
bad consequences for an incorrectly re-identified second victim.

I think (more) explicitly calling out such threats would be a fine
thing. If there are studies that have quantified any of this then
referencing those would be great - I've not gone looking and don't
know of any off the top of my head, sorry. I also wonder if such
signals, if detectable (and I bet a beer they are), might be just as
detectable on the upstream side of a recursive if the adversary has
tempora-like access.

Cheers,
S.

---

From: Brian Haberman <[email-masked]>
Date: Thu, 26 Feb 2015 07:43:47 -0500

Hiya Stephen,

> go forward regardless of how my comment below is dealt with.

I agree!

> (I don't know if this is actual) risk of re-identification via

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.

Regards,
Brian

> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 26 Feb 2015 12:51:23 +0000

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

S.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 26 Feb 2015 09:15:53 -0500

On Thu, Feb 26, 2015 at 7:51 AM, Stephen Farrell <[email-masked]>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Hiya,
>

For what it is worth, I did include padding in my spec, specifically to
defeat traffic analysis based on packet length. Otherwise it would be easy
for an intelligence agency to identify people going to a site by putting in
a very long DNS name and looking for queries of a specific length.

Now I don't want to make that a point of distinction vs the VeriSign
proposal as they could add padding. But I think it does show that a lot of
thought has to go into the process and that we cannot 'simply reuse' TLS.
If we are going to be padding packets in TLS then why not just do what I do
and leverage the expensive, complicated part of TLS, the key exchange and
replace the easy part, the packet framing?

I am not yet done with my architecture paper. But one of the consequences
of Snowdonia is that traffic analysis is now part of the threat model and
we have to start getting to grips with it.

It is not possible to protect against every type of traffic analysis with
end to end security. DPRIV is an end to end security enhancement
implemented as a session layer replacement so there will be some types of
traffic analysis we cannot defend against.

There is more than one level of traffic analysis that is relevant:

Network Layer: Packet size, IP address, Timing
Link Layer: Packet path

If you want to have complete traffic analysis protection then you have to
work at the Network and Link layers as well as the session layer because
that is where the attacks take place.

It is possible to add noise at the session layer to provide a degree of
security. But we have to be realistic about what we can achieve. We can
certainly neuter mass surveillance and most forms of passive attack. We
can't be effective against an active attack without a lot of overhead.

Rolling up multiple queries into a single query is another technique I use
that helps reduce the information leakage (besides improving efficiency).

One thing I would like some help with is understanding what the padding
quanta should be. I am not sure this needs to go in the spec but we should
have some idea. My naive approach is simply to add a random chunk of data
then pad every message to a multiple of 64 bytes or the MTU.

---

From: John Heidemann <[email-masked]>
Date: Thu, 26 Feb 2015 23:30:32 -0800

>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

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 27 Feb 2015 02:58:13 -0500

> are not considered here".

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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 27 Feb 2015 09:56:20 +0000

On 27/02/15 07:58, Tim Wicinski wrote:
> 
> 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.

I also agree. At the relevant time (which is not now), I reckon
the WG should consider whether some form(s) of padding are worth
including or not. And also what kind of guidance to offer about
side-channels, which is arguably a different threat.

But the problem statement I think should note the potential to
re-identify based on at least sets of queries seen with today's
DNS. Whether those are down to opening all bookmarks as tabs in
one go, or due to re-boot behaviour, I'd say there's a strong
enough fingerprint there that the problem statement should not
be silent on the topic.

S.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 27 Feb 2015 12:27:54 +0100

On Thu, Feb 26, 2015 at 03:13:19AM +0000,
 Stephen Farrell <[email-masked]> wrote 
 a message of 74 lines which said:

> One issue I don't think is covered well enough is the potential (I
> don't know if this is actual) risk of re-identification via sets of
> DNS queries.

I assume you know draft-iab-privsec-confidentiality-threat, currently
under review. In its -03 version, there are a lot of mentions of
"inference", inference being defined as "information extracted from
analysis of [raw information]". Isn't it sufficient, for
draft-ietf-dprive-problem-statement, to mention the importance of
inference and to add a reference to
draft-iab-privsec-confidentiality-threat?

> referencing those would be great

Do note draft-ietf-dprive-problem-statement-02 mentions these sort of
risks in its section 3 and in the references  [dns-footprint],
[dagon-malware] and [darkreading-dns]. If it's not sufficient,
more/better references are welcome.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 27 Feb 2015 12:32:03 +0100

On Thu, Feb 26, 2015 at 12:51:23PM +0000,
 Stephen Farrell <[email-masked]> wrote 
 a message of 40 lines which said:

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

Do note that draft-bortzmeyer-dnsop-privacy-sol-00 (now expired, I may
revive it if there is interest) mentions traffic analysis and possible
counter-measures such as padding, in its section 2.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 27 Feb 2015 11:53:27 +0000

Hiya,

> draft-iab-privsec-confidentiality-threat?

I'd argue that a specific mention here would be warranted, even
if that's partly redundant with the IAB document.

But hey it's fair for you to ask for text too, so I had a quick
look and found [1] which seems fairly on the money. (Via [2] which
may have even better refs.) How's about adding something like:

"
2.6 Re-identification

Re-identification of a user via DNS queries is also a potential
threat. If the adversary knows a user's identity and can watch
their DNS queries for a period, then that same adversary may be
able to re-identify the user solely based on their pattern of
DNS queries later on regardless of the location from which
the user makes those queries. For example, one study [1] found
that such re-identification is possible so that

   "73.1% of all day-to-day links were correctly established, i.e.
   user u was either re-identified unambiguously (1) or the
   classifier correctly reported that u was not present on day
   t+1 any more (2)"

While that study related to web browsing behaviour, equally
characteristic patterns may be produced even in machine-to-machine
communications or without a user taking specific actions, e.g. at
reboot time if a characteristic set of services are accessed by
the device.

The IAB privacy and security programme also have a work in progress
[draft-iab-privsec-confidentiality-threat] that considers such
inference based attacks in a more general framework.
"

S.

[1] Herrmann, D., Gerber, C., Banse, C., & Federrath, H. (2012).
Analyzing characteristic host access patterns for re-identification of
web user sessions. In Information Security Technology for Applications
(pp. 136-154). Springer Berlin Heidelberg.
http://epub.uni-regensburg.de/21103/1/Paper_PUL_nordsec_published.pdf

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 27 Feb 2015 11:59:23 +0000

Sorry, that's missing the ref [2] which was:

[2]
http://scholar.google.es/scholar?q=dns+re-identification+&btnG=&hl=es&as_sdt=0%2C5#

(And for fun - the DNS name in that URL gives away the location
to which I'm currently travelling - did we capture that too?:-)

S

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 27 Feb 2015 13:28:57 +0100

On Fri, Feb 27, 2015 at 11:53:27AM +0000,
 Stephen Farrell <[email-masked]> wrote 
 a message of 55 lines which said:

> How's about adding something like:
> 
> 2.6 Re-identification

OK for me, thanks for the text. Any advice from the WG? (I don't want
to make important changes in the middle of a WGLC if there is no
consensus.)

---

From: Brian Haberman <[email-masked]>
Date: Fri, 27 Feb 2015 07:56:55 -0500

Hi Stephane,

> to make important changes in the middle of a WGLC if there is no

Adding this text is fine by me.

Regards,
Brian

---

From: Warren Kumari <[email-masked]>
Date: Fri, 27 Feb 2015 10:09:24 -0500

> to make important changes in the middle of a WGLC if there is no

<no hats>
Sounds good to me...

We've also been somewhat avoiding (or, we mention it every now and
then but generally agree we cannot solve it) the timing side channel.

If you can:
A: watch the queries going into a DPRIVE recursive nameserver
and
B: watch the queries that it is making
and
C: the nameserver is not overly busy (whatever that means)
and
D: the query being looked up is not already in cache.
you can figure out what the user queried for.

i.e: I see user 192.0.2.12 make an encrypted query. 0.8ms later the
nameserver initiates a query for www.example.com. Hmmm, wonder what
caused that...

I don't have any suggested text, nor do I know if anything should go
in *this* doc, but if we mention the pattern attack, perhaps we should
mention timing as well?

W
</no hats>

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 27 Feb 2015 07:18:45 -0800

> to make important changes in the middle of a WGLC if there is no

Yep, looks a good addition.

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 27 Feb 2015 10:38:53 -0500

Seconded, just go ahead.

BTW are we planning to IETF last call this doc and publish as an RFC or is
this internal only? Yes we probably said but I can't keep which docs are
what in where straight.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 27 Feb 2015 16:46:33 +0100

On Fri, Feb 27, 2015 at 10:38:53AM -0500,
 Phillip Hallam-Baker <[email-masked]> wrote 
 a message of 78 lines which said:

> BTW are we planning to IETF last call this doc and publish as an RFC
> or is this internal only?

The charter is silent about it. My goal is certainly to have this
document published as a RFC, we need clear documentation of privacy
properties of IETF protocols, like RFC 6973 says.

Now, whether or not an IETF Last Call is necessary, I don't know.

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 27 Feb 2015 10:50:32 -0500

> Now, whether or not an IETF Last Call is necessary, I don't know.

Warren and I have discussed this, though not recently. The consensus (from the group and from ADs) is published as an RFC.  I know a few have felt the IETF are awash in "problem statements".

tim

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 27 Feb 2015 10:55:13 -0500

On Fri, Feb 27, 2015 at 10:50 AM, Tim Wicinski <[email-masked]> wrote:

> Warren and I have discussed this, though not recently. The consensus (from
> the group and from ADs) is published as an RFC.  I know a few have felt the
> IETF are awash in "problem statements".

I just want to know what sort of review to give it. I won't bother with
spelling errors and the like for non RFC docs.

---

From: Brian Haberman <[email-masked]>
Date: Fri, 27 Feb 2015 10:56:32 -0500

On 2/27/15 10:50 AM, Tim Wicinski wrote:
> Warren and I have discussed this, though not recently. The consensus
> (from the group and from ADs) is published as an RFC.  I know a few have
> felt the IETF are awash in "problem statements".
> 

I find more benefit in the problem statement RFCs than in the
use-cases/requirements/architectures RFCs that wither on the vine and
don't reflect reality when the protocol specifications are published.

Regards,
Brian

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 27 Feb 2015 15:58:47 +0000

> in *this* doc, but if we mention the pattern attack, perhaps we should

FWIW, I'm not sure. I don't think this'd count as a problem
with current DNS, except maybe in a really weird case where
the adversary can see ciphertext packets inside an IPsec VPN
and DNS queries in clear outside? Otherwise, it'd be like a
non-constant time crypto implementation and something to
bring up in the context of a specific solution proposal.

If one did want to include text, I guess there are references
to how equivalent timing correlations have been seen in Tor
that could be used to identify a source. (I'm not sure if
that's been done in the wild against Tor or only in lab
studies though.)

On balance I'd say maybe leave that one for solution docs
but I'd also not object if text like that was added as a
security consideration. (I could imagine the editor might
be wary of that though, in case it's the start of a slippery
slope;-)

Cheers
S.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 27 Feb 2015 16:00:12 +0000

> felt the IETF are awash in "problem statements".

Yeah, but this discusses a real problem and not a "problem" :-)

I hope this ends up as an RFC - it's too useful to not really

S.

---

From: Warren Kumari <[email-masked]>
Date: Fri, 27 Feb 2015 11:11:52 -0500

> this internal only? Yes we probably said but I can't keep which docs are

The plan was to RFCize it. It was not listed on the charter /
milestones because it was unclear then we wrote that if we wanted to
do this here or if it would be better in DNSOP.

We *could* go back and milestone it, but that sounds like unnecessary
administrative faffing.

W
P.S: Apparently I've decided today is verbification day...

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 27 Feb 2015 20:39:30 -0500

> to make important changes in the middle of a WGLC if there is no

This text looks OK to add to me.

     --dkg

---

From: Rich Kulawiec <[email-masked]>
Date: Sat, 28 Feb 2015 08:12:54 -0500

> (I don't know if this is actual) risk of re-identification via

I've been studying the twin problems of anonymization and
re-identification attacks for the past several years, and would
like to add a general comment about this issue.

One study after another, in disparate fields, has shown that
data that everyone agrees is anonymized, isn't really -- and thus is
subject to re-identification attacks.  Sometimes those attacks can
be conducted based solely on the putatively-anonymized data set;
sometimes they can be conducted by combining that data set with
other ones.  And one of the disturbing things about that latter
circumstance is that "other ones" isn't necessarily restricted to
data sets which are public: the ongoing parade of massive data
leaks (e.g., Target, Home Depot, Anthem) has ensured that potential
attackers have a plethora of resources to choose from, depending
on what's been made available, what it costs, what their resources
are, etc.

A second disturbing thing is that the quantity of data required
to conduct such attacks is often surprisingly small.  The first
link below demonstrates a re-identification attack that is successful
in about 90% of cases...but relies on only four (4) data points.

Some illustrative examples:

	Yet Another Report Showing "Anonymous" Data Not At All Anonymous 
	https://www.techdirt.com/articles/20150209/06111829955/yet-another-report-showing-anonymous-data-not-all-anonymous.shtml

	Anonymity and the Netflix Dataset
	https://www.schneier.com/blog/archives/2007/12/anonymity_and_t_2.html

	Poorly anonymized logs reveal NYC cab drivers' detailed whereabouts
	http://arstechnica.com/tech-policy/2014/06/poorly-anonymized-logs-reveal-nyc-cab-drivers-detailed-whereabouts/

	A Systematic Review of Re-Identification Attacks on Health Data
	http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0028071

One person whose work I've been following in this regard is
Arvind Narayanan.  He's at Princeton, and he has a blog here:

	http://33bits.org/

There are many thoughtful entries in that blog, but I think one of the
best is this one:

	De-anonymization is not X: The Need for Re-identification Science
	http://33bits.org/2009/10/14/de-anonymization-is-not-x-the-need-for-re-identification-science/

My take, based on everything I've read, is that we're only at the
beginning of our understanding this problem.  We really do, as that
last blog entry points out, need science in this area, and we don't have
it yet.  But based on what we *do* know to date, it seems to be prudent
to use the working assumptions that (1) nearly all data sets are not as
anonymized as we'd like to think they are and thus (2) nearly all data
sets are subject to some form of re-identication attack and (3) those
re-identification attacks may be alarmingly successful even if they use
very sparse data.

Now as to applicability in this particular area: I have been thinking a
great deal about something related that I'll glibly label as "Auto-update
considered harmful" for lack of a better term.  Auto-update mechanisms
generate very predictable patterns of DNS queries and other traffic
(likely: HTTP/HTTPS), and I hypothesize that it's possible to fingerprint
individual systems and users based on those.  I further hypothesize that
it's possible to ascertain not only what software users have installed,
but what versions of software they have installed, *even if the traffic
is encrypted*.  But these are nascent hypotheses and I've yet to devise
an experimental methology to test them, so for purposes of dns-privacy,
I'll just say that Stephen's point is a VERY good one and fully merits
the attention of this group.

---rsk