At Tue, 12 Jan 2016 16:56:39 -0500, Tim Wicinski <[email protected]> wrote:
> The chairs realized earlier today that we encouraged this draft to be > created, but once it was, we forgot to start a formal Call for Adoption. > With the feedback already, this document looks ready for adoption and > being worked on. > > This starts a Call for Adoption for draft-dgr-dprive-dtls-and-tls-profiles > > The draft is available here: > https://datatracker.ietf.org/doc/draft-dgr-dprive-dtls-and-tls-profiles/ > > Please review this draft to see if you think it is suitable for adoption > by DPRIVE, and comments to the list, clearly stating your view. I support the adoption. Some initial comments on the 00 version follow: - Section 4.2 +-----------------------+------------------+-----------------+ | Usage Profile | Passive Attacker | Active Attacker | +-----------------------+------------------+-----------------+ | No Privacy | N | N | | Opportunistic Privacy | P | N (D) | | Strict Privacy | P | P | +-----------------------+------------------+-----------------+ How can we detect an active attack in Opportunistic Privacy? For example, if an active attacker pretends to be the recursive server that just doesn't support privacy, can't we distinguish it from a genuine server that actually doesn't support it? Perhaps it's described in the following part of Section 5: [...] This is useful for detecting (but not preventing) active attack, and for debugging or diagnostic purposes if there are means to report the result of the authentication attempt. but it's still not very clear to me. Editorial matters: - Section 4.2: s/section Section/Section/ is discussed in section Section 5 - Section 6: '[dnssec-trigger]' isn't included in the references sections. [...] Techniques such as those used by DNSSEC-trigger [dnssec- trigger] MAY be used during network configuration, with the intent to - Section 8.3: s/purse/pursue/ ? (If it's really 'purse' I don't understand what it means...) [QUESTION: The authors would like to solicit feedback on the use of DHCP to determine whether to purse a new DHCP option in a later version of this draft, or defer it.] -- JINMEI, Tatuya _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
