[cryptography] very little is missing for working BTNS in Openswan
nico at cryptonector.com
Fri Sep 13 17:14:56 EDT 2013
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
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
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.
More information about the cryptography