> On 14 Nov 2015, at 21:23, Warren Kumari wrote: > > Hi there, > > At the Yokohama DPRIVE meeting you agreed to review > draft-am-dprive-eval ( > https://datatracker.ietf.org/doc/draft-am-dprive-eval/ ).
Hi, I have reviewed draft-am-dprive-eval. The document is much needed. I learnt a lot while reading it. A few comments: (Please forgive any lack of knowledge of the underlying formal methods used) §1 - the list of DNS private exchange mechanisms appears out of date e.g. it doesn't reference dns-over-dtls. (Are confidential-dns and privatedns still needed?) §1P5 - there is an un-necessary space before a full stop. §2 - I believe the references to RFC4949 in §2.2 and §2.3 should be to RFC6973 as RFC4949 does not define or even mention most of the terms attributed to it. §2.4P1 - s/we/with/ $4.1 - I found the name misleading. A better name might be “System Entities”? - I don’t think there is such thing as an “Authoritative resolver” - While reading this I wondered if a standalone validator should be one of the entities forming the system model. §4.2 - RFC7258 doesn’t actually use the term 'attack surface'. I understand what you mean but wonder if something like “In relation to [RFC7258] these are the links that are vulnerable to attacks where the monitor (eavesdropper) can collect sets of query information.”. - I don’t understand the second paragraph, in particular, what is the monitor model and where is it in Section 6 (or do you mean §5.3)? - This section seems to imply that it is only the links that are vulnerable. Should there be a discussion about the entities or is that what the second paragraph is about? §5 - defines the term “actors” but this term is never used again in its plural form. The singular term “actor” is used before and after this definition, maybe it should be defined in section 2. - Paragraph 2 states “we note that the only difference between an attacker and an obeserver(sic) is that an attacker is an unauthorized observer with all the capabilities it may have.” but then goes on to say “We also stress that for the context of DNS privacy, the term attacker may implicitly assume an intent.” implying a difference between an attacker and an observer. I certainly feel that there is a difference. - Also the meaning of attack and actor (attacker) is well described in RFC7258, could you just refer to that? - Why is the definition of “Risk Model” here and not in section 2? §5.2 - states “Additionally, this model can select links in order to target specific individuals.” is that not a capability of Passive Pervasive Monitors? - It also states “Note that we exclude malicious monitoring from this document since, by definition, a malicious actor has an intent associated with his actions.” But then §5 states “In this document we focus on two risk models, namely a pervasive monitor and a malicious monitor.”? §6 - a reference dns-over-dtls is needed. - I found the use of lowercase letters ’s’ and ‘r' in the description of 'Private Information Retrieval' for the user and record made it difficult to read. - Private Information Retrieval: s/recordr/record r/ - Private Information Retrieval: talks about issues with its use in DNS. Should that not be part of the evaluation section? - Note: I don’t really understand the second sentence. - Note: I think it should also mention draft-ietf-dnsop-edns-client-subnet - Encrypted Channel Mechanisms: states “Unlinkability of the queries may depend on the type of crypto-suite; it is provided as long as randomized encryption is used.”, to be clear are you suggesting randomisation of the cipher suites, TLS versions etc? - Composed (Multiple) Mechanisms: “randomized encryption (for undetectability)” should read “randomized encryption (for unlinkability and undetectability)” but then the composition is no better than randomized encryption on its own. §7 - was not at all what I expected when I finally got to it :) That is not a criticism it might say more about me than the draft! - I think it should have an example for each mechanism in §6 and for each monitor in §5 - I think it needs a discussion of how changing the System_Setting, Risk_Model or Privacy_Mechanism parameters changes the probability calculations. - where do the evaluation templates come from? Is it some standardised methodology or invented just for this draft? - the templates in the following sections use both ‘Type-1A’ and Type-1B’, but §5 only has Type-1 and Type-2? §7.1 - states “The dummy traffic mechanism is not presented as a practical mechanism”. In that case why mention it at all? - the discussion about Type-2 suggests active monitors may have malicious intent - there is no discussion of how the undetectability probability is decreased in the Type-2 case §7.2 - s/one query is comes from/one query is from/ §7.3 - “Privacy_measure (unlinkability) = 1” doesn’t that depend on randomized encryption (see §6) - Does the calculation also depend on things like connection re-use? §7.4 - While I agree that IPSec gives Privacy_guarantee = unlinkability, undetectability, it does reveal a relationship between the end points? Combining this with tor, for example, would give even better privacy. regards John John Dickinson http://sinodun.com Sinodun Internet Technologies Ltd. Magdalen Centre Oxford Science Park Robert Robinson Avenue Oxford OX4 4GA U.K.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
