Subject: Re: [dns-privacy] I-D Action: draft-am-dprive-eval-00.txt

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 23 Mar 2015 14:11:15 -0500

On Sun, Mar 08, 2015 at 11:28:00PM -0700,
 [email-masked] <[email-masked]> wrote 
 a message of 41 lines which said:

>         Title           : Evaluation of Privacy for DNS Private Exchange
>         Authors         : Aziz Mohaisen
>                           Allison Mankin
> 	Filename        : draft-am-dprive-eval-00.txt

I tried to apply the methodology to qname minimisation but only had a
partial success:

Eval(Qname_minimisation (algo=aggressive, qtype=ns),
   System_Settings([R], [R-A]),  
   Attacker_Model(Type-2, A),    
   Privacy_Mechanism{
           Mechanism_name = Qname_minimisation
           Parameters{
               Algorithm = aggressive,
               Qtype_used = NS
          }
       },
   System_settings{
       Entities = R 
       Links = R-A
   }, 
   Attacker_model{
       Type = Type-2
       Compromised_entities = A // The attacker controls the auth. server
       Links = R-A    // And/or can sniff the link
   }
   Privacy_guarantee =  unlinkability
   Privacy_measure =  a complicated function of the depth of A (root
   name servers will see less information than TLD servers) and of the
   length of the original name (if the original qname was only two
   labels long, the TLD servers will have exactly the same
   information as before qname minimisation). TODO: add also the
   qtype in the equation.

   Return privacy_guarantee, privacy_measure

}

It seems that defining the actual privacy measure will be more
complicated than with the existing examples.

Some of them seem a bit optimistic. For instance:

Eval(TLS_enc (SHA256, ECDSA, port 53, uniform, NA),
...
Attacker_Model(Type-1B, S-R)). {
...
Privacy_measure (unlinkability) = 1

The way I read it, it means an attacker on the link from stub to
resolver would have zero linkability between two DNS requests. Philip
Hallam-Baker already mentioned the case
<https://github.com/bortzmeyer/my-IETF-work/issues/5> of the info you
can get just by observing the *length* of requests (something that
TLS_enc does not hide).

I also question the terminology "Compromised_Entities". From a privacy
point of view, it is irrelevant if the authoritative servers is
managed by people who willingly send data to the NSA (or the FSB or
the PLA or the DGSE) or if it is compromised by cyberwarriors of one
on the above agencies. The result is the same. We should use the
vocabulary of RFC 6973 ("Observers")

I do not really understand what you have to indicate in
System_Settings, and [syntax] see why we have to repeat things like
System_Settings and Attacker_Model. Allison will probably explain that
at the DPRIVE meeting in one hour :-)

Also, having a syntax to add comments in the formal text would be nice
:-) I decided to use //

---

From: "Mankin, Allison" <[email-masked]>
Date: Mon, 23 Mar 2015 20:14:32 +0000

Stephane,

I think this was a useful exercise - I enjoyed reading this template and
it made sense.  

>complicated than with the existing examples.

That¹s reasonable.

>can get just by observing the *length* of requests (something that
I would consider the correlation of lengths of requests and other matters
such as timing of responses from caches to be side channels.  Or to mean
that we have only unlinkability, but not undetectability. Indeed some
information is implied about the PII, but the PII itself is not linked to
these queries.  We haven¹t captured the questions involved when someone
can deduce that very few (Unlucky Few) are the sources of queries from a
recursive downstream.  That seems closer to being a complication on
linkability.  

>vocabulary of RFC 6973 ("Observers")
I totally agree - this was an oversight on our part.

>at the DPRIVE meeting in one hour :-)
As I have only 10 minutes, I won¹t have time to speak to this, but the
point is taken.  I did find it very easy to read your template, and
readability is an important goal here.  We can take another look and see
if we have applied Ockham¹s razor sufficiently.

>Also, having a syntax to add comments in the formal text would be nice

Yes, good.

---

From: Aziz Mohaisen <[email-masked]>
Date: Mon, 23 Mar 2015 15:52:17 -0400

> I tried to apply the methodology to qname minimisation but only had a
Perhaps you are missing the point of the document.

>    information as before qname minimisation). TODO: add also the

That is out of scope.

> Privacy_measure (unlinkability) = 1

That is why we have this matter open for discussion and anyone who can
should help. Whether to evaluate all possible mechanisms being discussed in
the working group shouldn't be dependent on how complex they are to
analyze.

> can get just by observing the *length* of requests (something that
You can always be creative about all the kinds of theoretical threats that
a length of a domain name can reveal about the user privacy. However, a
priority should be made to understand and address the imminent threats --
regardless of what solution is going to be used for that.

> at the DPRIVE meeting in one hour :-)
Because some of the proposed mechanisms don't follow a single standard of a
system setting, and get somewhat creative about adding new entities.

> Also, having a syntax to add comments in the formal text would be nice
I am glad you like that.

Aziz