Re: how bad is IPETEE?
At Tue, 15 Jul 2008 18:33:10 -0400 (EDT), Leichter, Jerry wrote: For an interesting discussion of IPETEE, see: www.educatedguesswork.org/moveabletype/archives/2008/07/ipetee.html Brief summary: This is an initial discussion - the results of a drinking session - that got leaked as an actual proposal. The guys behind it are involved with The Pirate Bay. The goal is to use some form of opportunistic encryption to make as much Internet traffic as possible encrypted as quickly as possible - which puts all kinds of constraints on a solution, which in turn also necessarily weakens the solution (e.g., without some required configuration, there's no way you can avoid MITM attacks) and forces odd compromises. I also have a followup post at: http://www.educatedguesswork.org/movabletype/archives/2008/07/more_on_ipetee.html -Ekr - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: how bad is IPETEE?
On Jul 15, 2008, at 16:33 PM, Leichter, Jerry wrote: The goal is to use some form of opportunistic encryption to make as much Internet traffic as possible encrypted as quickly as possible - which puts all kinds of constraints on a solution, Oh, then they should learn about Adam Langley's Obfuscated TCP: http://code.google.com/p/obstcp/ One of the design constraints for Obfuscated TCP was that an Obfuscated TCP connection is required to take zero more round trips to set up and use than a normal TCP connection. Way to go, Adam! Regards, Zooko - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: how bad is IPETEE?
For an interesting discussion of IPETEE, see: www.educatedguesswork.org/moveabletype/archives/2008/07/ipetee.html Brief summary: This is an initial discussion - the results of a drinking session - that got leaked as an actual proposal. The guys behind it are involved with The Pirate Bay. The goal is to use some form of opportunistic encryption to make as much Internet traffic as possible encrypted as quickly as possible - which puts all kinds of constraints on a solution, which in turn also necessarily weakens the solution (e.g., without some required configuration, there's no way you can avoid MITM attacks) and forces odd compromises. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: how bad is IPETEE?
John Ioannidis wrote on 10 July 2008 18:03: Eugen Leitl wrote: In case somebody missed it, http://www.tfr.org/wiki/index.php?title=Technical_Proposal_(IPETEE) If this is a joke, I'm not getting it. /ji I thought the bit about Set $wgLogo to the URL path to your own logo image was quite funny. But they did misspell 'teh' in Transparent end-to-end encryption for teh internets. It does sound a lot like SSL/TLS without certs, ie. SSL/TLSweakened to make it vulnerable to MitM. Then again, if no Joe Punter ever knows the difference between a real and spoofed cert, we're pretty much in the same situation anyway. And of course those supposedly transparent fails-and-reconnects will turn out to be anything but, in practice... cheers, DaveK -- Can't think of a witty .sigline today - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: how bad is IPETEE?
On Fri, Jul 11, 2008 at 05:08:39PM +0100, Dave Korn wrote: It does sound a lot like SSL/TLS without certs, ie. SSL/TLSweakened to make it vulnerable to MitM. Then again, if no Joe Punter ever knows the difference between a real and spoofed cert, we're pretty much in the same situation anyway. Note that this is not all that bad because many apps can do authentication at the application layer, and if you add channel binding then you can leave session crypto to IPsec while avoiding MITMs (they get flushed by channel binding). This is the premise of BTNS + connection latching. W/o channel binding it's better than nothing, though not much. W/ channel binding it should be much easier to deploy (beyond software updates) than plain IPsec with similar security guarantees. Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: how bad is IPETEE?
At Thu, 10 Jul 2008 18:10:27 +0200, Eugen Leitl wrote: In case somebody missed it, http://www.tfr.org/wiki/index.php?title=Technical_Proposal_(IPETEE) I'm not sure what the status of http://postel.org/anonsec/ is, the mailing list traffic dried up a while back. This is the first I have heard of this. That said, some initial observations: - It's worth asking why, if you're doing per-connection keying, it makes sense to do this at the IP layer rather than the TCP/UDP layer. - Why not simply use TLS or DTLS? - The uh, novel nature of the cryptographic mechanisms is pretty scary. Salsa-20? AES-CBC with implicit IV? A completely new cryptographic handshake? Why not use IPsec? - A related idea was proposed a while back (by Lars Eggert, I believe). See S 6.2.3.1 of: https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tcp-auth-arch.txt -Ekr - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: how bad is IPETEE?
On Thu, Jul 10, 2008 at 06:10:27PM +0200, Eugen Leitl wrote: In case somebody missed it, http://www.tfr.org/wiki/index.php?title=Technical_Proposal_(IPETEE) I did miss it. Thanks for the link. I don't think in-band key exchange is desirable here, but, you never know what will triumph in the marketplace. I'm not sure what the status of http://postel.org/anonsec/ is, the mailing list traffic dried up a while back. Connection latching, which is the BTNS WG equivalent of 'IPETEE', but much simpler, is in the IESG's hands now. Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: how bad is IPETEE?
Eugen == Eugen Leitl [EMAIL PROTECTED] writes: Eugen I'm not sure what the status of http://postel.org/anonsec/ The IETF just created a new list and subscribed all anonsec subscribers: https://www.ietf.org/mailman/listinfo/btns -JimC -- James Cloos [EMAIL PROTECTED] OpenPGP: 1024D/ED7DAEA6 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
