On Tue, Mar 31, 2015 at 8:44 AM, Daniel Kahn Gillmor <[email protected]> wrote:
> On Tue 2015-03-31 10:02:38 -0400, Eric Rescorla wrote: > > On Tue, Mar 31, 2015 at 7:01 AM, Eric Rescorla <[email protected]> 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 :) I'm not arguing that tcpcrypt (if adopted) should use the TLS framing (though of course if we were to adopt the TCP-use-TLS proposal then of course we should use the TLS framing). -Ekr
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
