At Mon, 18 Jan 2016 11:28:56 +0000, Sara Dickinson <[email protected]> wrote:
> > 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…). Maybe it's just a matter of wording, but this doesn't really sound like "Detection" to me, in that the client can't (100%) know if it's an attack or not (that's the same for Strict Privacy, but we can surely say it provides "Protection" in that case due to its hard-fail nature). But... > We plan to update the discussion of Opportunistic Privacy in the next version > - thanks for this comment. ...since this may be a wording issue, I'll see how the revised version reads. -- JINMEI, Tatuya _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
