On Tue, Jan 5, 2016 at 10:53 AM, Stephane Bortzmeyer <[email protected]> wrote:
> 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? Yes, I think this description is mostly correct. Except in the second step, I assume you meant that we lookup the DNS resolver name's IP address; we do not need "to find the DNS _host_ resolver name" since that was obtained already from static configuration in the prior step. > 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. > This depends on the definition of the phrase "Strict Privacy". If it can include some initial meta queries to (securely) obtain the address mapping of the DNS over (D)TLS server that to which we subsequently establish an authenticated & encrypted session, then this can still be considered strict. It could also be argued that 'strict' means no unprotected DNS queries anywhere, in which case a new category would be needed. I am okay with "Strict" having the meaning in my previous paragraph. We have to consider practical deployability and usage issues. A 'no unprotected DNS anywhere' policy may not be deployable in the general case, because of a range of system bootstrapping issues and other environmental issues (for example, a system may need to issue a few unprotected DNS queries in order to gain access to the network beyond a captive portal etc). 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.) > Yes, I agree. -- Shumon Huque
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
