On Tue, Aug 5, 2014 at 3:44 PM, Christian Huitema <[email protected]> wrote: >> More things worth beating this horse past death with: >> >> - authentication is difficult to do scalably, but unauthenticated key >> exchange is trivial, therefore >> >> - having an option to do unauthenticated key exchange, as a >> middle-of-the-road choice between no-security and authentication, is >> a very good thing >> >> - authentication can always be added later (the charter says this!) >> >> Is this horse dead yet? I think so. > > Absolutely. By the way, having hooks like the unique session-ID of TCP Crypt > is essential. It allows applications to implement a simple MITM detection as > part of an end-to-end authentication process. All applications may not > implement that, but some will. That creates lots of uncertainty for any MITM > attacker, because they now have a clear risk of being detected.
Yes. We call that "channel binding". See RFC5056. It's important to not get it wrong. A unique session ID is not sufficient (e.g., TLS session IDs are not a channel binding). _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
