On Thu, Sep 12, 2013 at 08:28:56PM -0400, Paul Wouters wrote: > Stop making crypto harder!
I think you're arguing that active attacks are not a concern. That's probably right today w.r.t. PRISMs. And definitely wrong as to cafe shop wifi. The threat model is the key. If you don't care about active attacks, then you can get BTNS with minimal effort. This is quite true. At least some times we need to care about active attacks. > On Thu, 12 Sep 2013, Nico Williams wrote: > >Note: you don't just want BTNS, you also want RFC5660 -- "IPsec > >channels". You also want to define a channel binding for such channels > >(this is trivial). > > This is exactly why BTNS went nowhere. People are trying to combine > anonymous IPsec with authenticated IPsec. Years dead-locked in channel > binding and channel upgrades. That's why I gave up on BTNS. See also > the last bit of my earlier post regarding Opportunistic Encryption. It's hard to know exactly why BTNS failed, but I can think of: - It was decades too late; it (and IPsec channels) should have been there from the word (RFC1825, 1995), and even then it would have been too late to compete with TLS given that the latter required zero kernel code additions while the former required lots. - I only needed it as an optimization for NFS security at a time when few customers really cared about deploying secure NFS because Linux lacked mature support for it. It's hard to justify a bunch of work on multiple OSes for an optimization to something few customers used even if they should have been using it. - Just do it all in user-land has pretty much won. Any user-land protocol you can think of, from TLS, to DJB's MinimaLT, to -heck- even IKE and ESP over UDP, will be easier to implement and deploy than anything that requires matching kernel implementations in multiple OSes. You see this come up *all* the time in Apps WG. People want SCTP, but for various reasons (NAAAAAATTTS) they can't, so they resort to putting an entire SCTP or SCTP-like stack in user-land and run it over UDP. Heck, there's entire TCP/IP user-land stacks designed to go faster than any general-purpose OS kernel's TCP/IP stack does. Yeah, this is a variant of the first reason. There's probably other reasons; listing them all might be useful. These three were probably enough to doom the project. The IPsec channel part is not really much more complex than, say, "connected" UDP sockets. But utter simplicity four years ago was insufficient -- it needed to have been there two decades ago. Nico -- _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
