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. Summary: IMHO, ready for WGLC 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. 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. [It cannot be because the resolver does not support TLS-over-DNS because, in that case, retrieving certificates with DANE would be pointless.] 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? _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
