On 12/1/15, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > 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. >
That doesn't change with Bryan's suggestion, I think. > * Interoperable in the field with various capital-intensive > middle boxen. Which would those be? And what is the definition of capital-intensive for those watching on the sidelines? > > 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. This seems borderline absurd. The TLS protocol is doing a major version revision. > 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. I don't think it will hinder interoperability and not one person has even named a single device that would have issues with it. I think the only thing that comes close is when I've named a classified US government surveillance program (XKeyscore) that would probably have trouble with it. We should add Bryan's feature and not pander to non-specific concerns about middleboxes that should be considered as adversaries. > > 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. That is part of what is happening in Bryan's suggestion. He found a reasonably practical way to encrypt record headers. His suggestion will make TLS more secure. His suggestion includes a review of a part of the previous state of TLS 1.3 with a proposed improvement. No one is debating it on the cryptographic merits which is surprising. All the best, Jacob _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
