Paul Hoffman <[email protected]> wrote: > > If I have a path with authentication and a path without, and I prefer > (not demand) the path with authentication, I am taking advantage of it.
Right, but is the authenticated path securely authenticated? i.e. can the client tell that an attacker is monkeying around with the authenticated path? This is important because it allows clients to make a meaningful choice between security and availabilty, while still being opportunistic (i.e. zero per-server config on the client). If the client can't tell the difference between no authenticated channel and an attacked authenticated channel, it has no meaningful choice other than to fall back to unauthenticated encryption, and the upshot is that the authenticated channel doesn't actually provide any security improvement, and the only option clients have is unauthenticated encryption. > > For protocols like SMTP or DNS there isn't an easy identifier that can > > be reliably authenticated, > > Why not? IP addresses work just fine in both of those cases. No, for SMTP the relevant identifier is the domain in the recipient email address. When we started working on DANE the problems were that (1) the MX target name often doesn't match the server's idea of its own name (2) the server's certificate often doesn't match either name Auth DNS has problem (1) (but not 2 because there's no encryption yet), and also has the problem that it's more latency sensitive and doesn't have a fast way to signal that encryption is available. For authentication to actually be secure, there has to be a signal (e.g. DANE) that this server has been configured without name mismatches, so the client can properly authenticate it. Tony. -- f.anthony.n.finch <[email protected]> http://dotat.at/ Sole, Lundy, Fastnet, Irish Sea: Variable 4, becoming south or southwest 4 or 5, occasionally 6 in Irish Sea. Slight or moderate. Occasional drizzle, fog patches at first. Moderate or good, occasionally very poor at first. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
