Stephane,
I think this was a useful exercise - I enjoyed reading this template and
it made sense.
Comments on your comments are inline:
>
>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.
That¹s reasonable.
>
>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 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.
>
>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 totally agree - this was an oversight on our part.
>
>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 :-)
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
>:-) I decided to use //
Yes, good.
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
