[Cryptography] [cryptography] very little is missing for working BTNS in Openswan

Nico Williams 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
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.


More information about the cryptography mailing list