Re: [Cryptography] [cryptography] very little is missing for working BTNS in Openswan
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 (NAATTTS) 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 -- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] [cryptography] very little is missing for working BTNS in Openswan
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). To summarize: IPsec protects discrete *packets*, not discrete packet *flows*. This means that -depending on configuration- you might be using IPsec to talk to some peer at some address at one moment, and the next you might be talking to a different peer at the same address, and you'd never know the difference. IPsec channels consist of ensuring that the peer's ID never changes during the life of a given packet flow (e.g., TCP connection). BTNS pretty much requires IPsec configurations of that make you vulnerable in this way. I think it should be obvious now that "IPsec channels" is a necessary part of any BTNS implementation. 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. We can use IDs to identify "anonymous" and sandbox these connections. If you want authenticated IPsec, use a different loaded policy that has nothing to do with OE IPsec. In libreswan terms: conn anonymous right=yourip rightid=@serverid rightrsasigkey=0xAQ[] left=%any leftid=@anonymous leftrsasigkey=%fromike conn admin [all your normal X.509 authentication stuff] Merging these into one, is exactly why we got transport mode, authenticated header,IKEv2 narrowing and a bunch of BTNS drafts no one uses. Stop making crypto harder! Paul ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] [cryptography] very little is missing for working BTNS in Openswan
On Mon, Sep 09, 2013 at 10:25:03AM +0200, Eugen Leitl wrote: > Just got word from an Openswan developer: > > " > To my knowledge, we never finished implementing the BTNS mode. > > It wouldn't be hard to do --- it's mostly just conditionally commenting out > code. > " > There's obviously a large potential deployment base for > BTNS for home users, just think of Openswan/OpenWRT. 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). To summarize: IPsec protects discrete *packets*, not discrete packet *flows*. This means that -depending on configuration- you might be using IPsec to talk to some peer at some address at one moment, and the next you might be talking to a different peer at the same address, and you'd never know the difference. IPsec channels consist of ensuring that the peer's ID never changes during the life of a given packet flow (e.g., TCP connection). BTNS pretty much requires IPsec configurations of that make you vulnerable in this way. I think it should be obvious now that "IPsec channels" is a necessary part of any BTNS implementation. Nico -- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] [cryptography] very little is missing for working BTNS in Openswan
On Thu, Sep 12, 2013 at 12:04 PM, 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). I am not convinced. It's supposed to be *better than nothing*. Packets that are encrypted between me and whatever gateway the endpoint elects to use are strictly better than unencrypted packets, from a security and privacy standpoint. Insisting that "BTNS should not be used without X, Y, and Z" had better come with a detailed explanation of why BTNS without X, Y, Z makes me *less* secure than no BTNS at all. -- Taral "Please let me know if there's any further trouble I can give you." -- Unknown ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
