On Mon, Jan 04, 2016 at 09:34:08AM +0000, sara <[email protected]> wrote a message of 172 lines which said:
> As discussed by the working group (in Yokohama and on the list) a new draft > has been produced > > https://tools.ietf.org/html/draft-dgr-dprive-dtls-and-tls-profiles-00 > <https://tools.ietf.org/html/draft-dgr-dprive-dtls-and-tls-profiles-00> I'm confused by section 8.2. It lacks details on how name resolution is done. I guess the workflow is the following: * DNS _service_ resolver name is fetched from the configuration * DNS lookup is done against the default DNS resolver (probably acquired from DHCP or RA), with no privacy, to find the DNS _host_ resolver name and then its IP address * Private DNS resolution can now be done against the configured privacy-aware resolver. Am I correct? If so, the claim of the draft that you can have "a DNSSEC validating DNS client configured in this way to do strict DNS privacy" is doubtful: it is not strict because of the second step, which has no privacy. May be not a big problem in practice but still sufficient to avoid labelling it "strict". (Same thing for 9.2, DANE.) It seems to me that the only way to have really Strict privacy is 8.1. Also, Table 1 is a bit optimistic: against a passive attacker, opportunistic privacy provides protection only if the server supports TLS. Otherwise, unlike Strict, Opportunistic will fall back. (The text in 4.2 is correct, when it speaks of "undetermined privacy guarantee", it's just the table which exaggerates.) Editorial : in section 4.2, there is a reference to "section Section 5". _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
