On Mon, Mar 23, 2015 at 3:11 PM, Stephane Bortzmeyer <[email protected]> wrote:
> On Sun, Mar 08, 2015 at 11:28:00PM -0700, > [email protected] <[email protected]> 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: > Perhaps you are missing the point of the document. > > 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. > That is out of scope. > 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 > 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. > 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). > 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. > > 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 :-) > 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 decided to use // > I am glad you like that. Aziz
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
