> On 14 Jan 2016, at 19:07, 神明達哉 <[email protected]> wrote: > I support the adoption.
Thanks for the review. > > 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. Yes you are correct this section touches on the issue. The scenario where detection is possible is if a client is configured with either a domain name or SPKI pinset for a given server then the expectation is that the server _is_ a DNS privacy enabling server. So if the authentication fails in Strict Privacy the connection is aborted. However in Opportunistic Privacy the client can choose to connect anyway, but it is aware that the server does not authenticate and so it should consider an active attack in progress (worst case - of course it could be a config error…). We plan to update the discussion of Opportunistic Privacy in the next version - thanks for this comment. > > 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 Thanks - will fix. > > - 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.] Ah! Yes this should be pursue! Sara. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
