> On 21 Jul 2016, at 17:06, Stephane Bortzmeyer <[email protected]> wrote: > > On Fri, Jul 08, 2016 at 05:37:55PM +0100, > Sara Dickinson <[email protected]> wrote > a message of 55 lines which said: > >> This is a minor update which adds some additional text to section >> 9.2 on the use of DANE.
Hi Stephane, > > Summary: IMHO, ready for WGLC Thanks for the review. > > A few questions: > > Technical : > > 4.2 : in the Figure 2, I have a doubt about the last line > (opportunistic profile, clear text). It shows that it offers no > protection against a passive or active attacker (OK), but has a D > (detection possible). How do you detect a sniffer? (This table > appeared in -02. The previous table, in -01, did not mention this > possibility of detection.) I vaguely remember discussions about that > in Buenos Aires but I cannot be sure: it may indicate there is a need > for more explanations, for instance in section 5. I meant to add text for this (because, yes, it has come up before) and forgot - thanks for reminding me. One example of ‘detecting’ an attack is where a name server that has previously provided DNS-over-TLS suddenly stops (e.g TLS handshakes fail). The Opportunistic client can choose to switch to TCP to continue to get DNS service but it should assume it has detected an attack (even if the reality is just a bad config change). > > 9.2.1 "The DNS queries for such DANE records MAY use opportunistic > encryption or be in the clear[I would add a comma here] to avoid trust > recursion" Why mentioning "in the clear"? When is it useful? If you > cannot authenticate, opportunistic encryption is still better (or, at > the minimum, not worse) than in the clear. Well, latency might be one reason because the client might have to wait a timeout to determine if the server supports TLS…. (but see below) > [It cannot be because the resolver does not support TLS-over-DNS > because, in that case, retrieving certificates with DANE would be > pointless.] However (on first use) the client may not know the services the nameserver offers, it must ‘discover' them. How about "SHOULD use opportunistic encryption but MAY use clear text (for example, if latency is a concern).”? > > Editorial : > > 9.2 "DANE [RFC6698] provides mechanisms to root certificate and raw > public key trust with DNSSEC" My english is too limited, I did not > know this use of "to root". Is it common? It makes sense to me but I can see the potential confusion - will re-word. Sara. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
