Greetings, all, > On 31 Mar 2015, at 17:44, Daniel Kahn Gillmor <d...@fifthhorseman.net> wrote: > > On Tue 2015-03-31 10:02:38 -0400, Eric Rescorla wrote: >> On Tue, Mar 31, 2015 at 7:01 AM, Eric Rescorla <e...@rtfm.com> wrote: >>> Either that or (my preference) specify an AEAD (combined encryption >>> and integrity) algorithm such as AES-GCM or ChaCha/Poly1305. >>> It's always hard to read community consensus, but my sense is that >>> AEAD represents the current best practice. > > I think this fairly states the TLS WG's consensus. > >> I should have mentioned, TLS 1.2 already supports AEAD algorithms and >> they're the only constructions which will be allowed in TLS 1.3. > > This is true, but the framing mechanism (after the first handshake) is > potentially up for a transition in 1.3 as well. > > I think it would be a mistake for tcpcrypt to duplicate the TLS framing > mechanism byte-for-byte. TLS carries with it a complicated and > difficult legacy, and its framing is a part of that. tcpcrypt has an > opportunity to not deal with that legacy, and can be cleaner. let's be > cleaner where we can be :)
+1 to learning from the past, yes. Learning from my own past, corner cases in framing are an excellent place to make design mistakes that you won't find for a while because, hey, it's only framing and framing's easy, right? Not saying we shouldn't do it, but while "let's invent a new framing" doesn't raise as many flags as "hey look at my shiny new cipher!", it still makes me nervous. Cheers, Brian > --dkg > > _______________________________________________ > Tcpinc mailing list > Tcpinc@ietf.org > https://www.ietf.org/mailman/listinfo/tcpinc
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
