> -----Original Message----- > From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Jacob Appelbaum > Sent: Monday, November 30, 2015 5:36 PM > To: tls@ietf.org > Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? > > 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.
I would strongly prefer that the analysis for TLS and DTLS no be too different. This approach will not work for DTLS given that packets can arrive out of order and multiple times. Jim > > 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
