Re: [dns-privacy] draft-am-dprive-eval-02

[Bob Harold]

On Mon, Nov 2, 2015 at 4:29 AM, Tim WIcinski  wrote:

>
> (no hats)
>
> With this new version, I think the document is useful and provides a solid
> discussion of how to quantify privacy mechanisms for a DNS implementer who
> is not a security subject matter expert.
>
> tim
> On 11/2/15 6:22 PM, Andrew Sullivan wrote:
>
>> Despite my comments against the hum at the mic, I have read this
>> document and think it should certainly be adopted.  I just don't want
>> Yet Another Meaningless Commitment.  (If you looked before and can't
>> fact it again, give it a try.  It's much improved.)
>>
>> A
>>
>>
>
This looks useful.  I have a few concerns.

https://tools.ietf.org/html/draft-am-dprive-eval-02

pg 3, section 2  "reasability" -> "readability"
Also, these sentences seem redundant:
"The verbatim source of most of those definitions is from
   [RFC6973], which are included as an aid in reasability."
and
"For the terms from [RFC6973], we include their
   definitions rather than simply referencing them as an aid to
   readability."

pg 5, sec 2.4, end of first paragraph:
"In this section, we outline
   such definitions we further notes on their indications."
That sentence seems incomplete around the word "we".  Perhaps "we" ->
"with".

pg 12, sec 6, last paragraph, "Composed (Multiple) Mechanisms":
"than either of the two along." -> than either of the two alone."

pg 14, sec 7.2  says:
"the probability that one query
   is comes from a given individual is (1/10 = 0.1).  The probability
   that two queries are issued by the same initiator is 0.1^2 = 0.01,
   which represents the linkability probability.  The unlinkability
   probability is given as 1-0.01 = 0.99."

Does "same initiator" mean "a given individual"?  Or just "second packet is
from same initiator as the first packet"
I think we should distinguish between linking to an initiator and linking
between packets::
-- The probability that two queries are issued by "a given individual" is
0.1^2 = 0.01
-- The probability that two queries are issued by the same initiator,
meaning the second packet is from the same initiator as the first, is 0.1.

pg 17, sec 7.4
I am not familiar with the details of IPSEC, but from the text it appears
to hide the port number.  But does it hide the destination IP?  If not, and
if most DNS resolvers have a separate IP from other services, then
"undetectability" is very low, since any communication with the IP of the
DNS resolver is most likely a DNS query.
(For purposes of the illustration, perhaps you should clearly state the you
are assuming a resolver on a shared IP that does much more than just DNS
resolution.)

-- 
Bob Harold
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] draft-am-dprive-eval-02

[Wendy Seltzer]

On 11/02/2015 04:22 AM, Andrew Sullivan wrote:
> Despite my comments against the hum at the mic, I have read this
> document and think it should certainly be adopted.  I just don't want
> Yet Another Meaningless Commitment.  

I think the document is useful, particularly in its overview of many
different aspects of privacy and pointers to thinking about information
linkage, rather than just the sensitivity of any given data point.

A few additional concepts might be helpful in the section on
quantification (around p7).

* k-anonymity [Sweeney]: k measures the smallest subset among which
information identifies an individual in a population; smaller subsets
offer less crowd-privacy.

* external or auxiliary information: information outside the specified
transaction or query that may be linked with that returned by the query.
(For example, time-stamped web server logs could be linked with
similarly timed DNS queries, making the query record more sensitive.)

* differential privacy [Dwork]: a measure of privacy over interactive
database queries, where the database-holder can tune the output to avoid
revealing more than (epsilon) about a subject, over repeated queries.
Possibly worth noting that's not what we're likely to be able to
measure/offer here.

* unicity [Montjoye]: knowing an individual is in the data-set, how many
data-points are necessary to identify them uniquely.

p5: Is it worth saying explicitly that "PII" is different from
"sensitive information"? By saying that information is personally
identifying, we're indicating that it uniquely identifies an individual.
That opens the door to linkage with sensitive information, even if the
PII is itself non-sensitive.

p11 Mix networks. worth mentioning the latency-privacy tradeoff?

p11 Dummy Traffic. In many instances, dummy traffic (or chaff) is easily
distinguished from real traffic, or still permits identification,
particularly with repeated observations. [Oya]


References:
[Sweeney]
http://dataprivacylab.org/dataprivacy/projects/kanonymity/kanonymity.pdf
[Dwork] http://research.microsoft.com/pubs/64346/dwork.pdf
[Oya] https://petsymposium.org/2014/papers/Oya.pdf
[Montjoye] http://www.nature.com/articles/srep01376?ial=1 (unicity)

A few typos:
p4 s/suite/suit/ also, the paragraph is incomplete.
p6 s/computed a monitor/computed by a monitor/
p9 s/obeserver/observer/
p11 s/recordr/record requested/

Best,
--Wendy

-- 
Wendy Seltzer -- wselt...@w3.org +1.617.715.4883 (office)
Policy Counsel and Domain Lead, World Wide Web Consortium (W3C)
http://wendy.seltzer.org/+1.617.863.0613 (mobile)

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] draft-am-dprive-eval-02

[Andrew Sullivan]

Despite my comments against the hum at the mic, I have read this
document and think it should certainly be adopted.  I just don't want
Yet Another Meaningless Commitment.  (If you looked before and can't
fact it again, give it a try.  It's much improved.)

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] draft-am-dprive-eval-02

[Tim WIcinski]

(no hats)

With this new version, I think the document is useful and provides a 
solid discussion of how to quantify privacy mechanisms for a DNS 
implementer who is not a security subject matter expert.


tim
On 11/2/15 6:22 PM, Andrew Sullivan wrote:

Despite my comments against the hum at the mic, I have read this
document and think it should certainly be adopted.  I just don't want
Yet Another Meaningless Commitment.  (If you looked before and can't
fact it again, give it a try.  It's much improved.)

A



___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy