On Thu, Jul 16, 2015 at 01:36:17PM +0200, Brian Trammell wrote: > hi Martin, all, > > in the interests of providing some (also hatless) contrast... > > > On 16 Jul 2015, at 12:33, Martin Stiemerling <[email protected]> wrote: > > > > Here are the two propposed ways forward: > > > > 1) As neither the protocol proposal I) nor II) is achieving rough > consensus, I propose to accept both as WG items and to let the WG work > on both proposals until the IETF-94 meeting in November 2015. The WG > will evaluate both proposals after this period and the chairs will > last call to see which protocol proposal will achieve rough consensus. > > I would be in favor of this way forward.
Me too. > I think one of the fundamental issues here is that the WG has been > asked to form consensus around one of two proposals, both of which > are relatively mature but in completely different ways. Without a > bit more implementation and experimentation experience, it's very > difficult to make an informed decision between (1) a completely new > protocol and (2) a mechanism for using an established protocol which > has not yet been widely used in the way envisioned by the WG. Maybe a stupid question, but is there an implementation of the TLS option in the same style as tcpcrypt implementation? Some comparision: Tcpcrypt looks much simper than TLS, even after the downprofiling done to TLS. There are lots of implementations of TLS, but none look to be suited for running in supervisor mode[1]. I think the "passthrough" mode of TLS proposal looks unlikely to work, unless both ends do it, which would relegate it to STARTTLS- like mechanism. The reason is that "oppurtunistic" endpoints can't interoperate with "non-oppurtunistic" ones, even if the protocol is the "same". Regarding maturity, when it comes to protocol security, maturity does not matter, how solid the cryptographic engineering is does. And unlike crypto primitives, protocols don't need to "age", since secrity analysis does not change much with time. For TLS, such security analysis was completed only quite recently (revealing multiple security bugs in original design). Some notes about tcpcrypt crypto: - ECDH "groups" Curve25519 and Curve448 from CFRG could be added. - Chacha20-Poly1305 (AEAD #29) could be added. Endpoints without hardware AES-GCM are much better with that[2]. - How are AEAD nonces generated exactly[3]? 128-bit crypto is bit on the low side. At full strength it is reasonable, but it doesn't take much to weaken it. [1] Some of characteristics: - Stacks are very limited (few kB, instead of few MB available in user mode). - Consequences of implementation flaws are MUCH worse. Winshock was bad, but corresponding bug here would be truly catastrophic. - No, one can't run garbage collector. [2] Some perspective: When cloudflare set nonstandard TLS Chacha20-Poly1305 ciphers at equal priority as AES-GCM ciphers, ~25% of AES-GCM usage shifted in less than half hour. [3] E.g.: - Is the nonce just zero-extended from its wire form? - Can passive listener determine values of extension bits (none of TLS 1.2, IPSec AES-GCM nor SSH allow this)? -Ilari _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
