On Mon, Nov 30, 2015 at 10:34:27AM +0000, Peter Gutmann wrote:
> Bryan A Ford <brynosau...@gmail.com> writes:
>
> >It would work just as well and in exactly the same way if the AEAD is
> >replaced with the traditional Encrypt-then-MAC construction, for example.
>
> No it wouldn't, unless the encrypt part is a stream cipher. You're still
> locked into using an AEAD stream cipher or the equivalent of an AEAD stream
> cipher built with encrypt+MAC. It won't work with, for example, the OCB AEAD
> mode, or CBC + MAC.
I think we should focus on what would get TLS 1.3 to be adopted:
* Reasonably implementable in libraries that support older
versions alongside TLS 1.3.
* Interoperable in the field with various capital-intensive
middle boxen.
This suggests focusing on solidifying the core protocol, and a
healthy dose of skepticism around bells and whistles. If the
protocol is overloaded with too many (alright even more) incompatible
innovations, the net effect is likely less security due to
substantially delayed deployment of the key improvements.
Encrypting message lengths looks rather marginal from this perspective,
and quite likely to hinder interoperability and delay both
implementation and upgrades. However cool an idea this might be,
this does not look to me like the right time to add this feature
to TLS.
At this point, TLS 1.3 is rather feature rich, and it is I think
time to focus on reviewing the already agreed changes (maybe even
drop some if they look inessential). Make it solid, trim the fat,
get it out the door in a usable form.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
