Re: [TLS] Record header size?

On Wed, Nov 18, 2015 at 11:07:59AM +0200, Yoav Nir wrote: > Stateful firewalls tend to pass only what they understand. They use some > measures to avoid tunneling and passing things that are not HTTPS over TCP > port 443. > If the record layer header for application-data (not the initial

Re: [TLS] Record header size?

Yoav Nir wrote: >> Peter Gutmann wrote: >> >> Eric Rescorla writes: >>> >>> The concern here is backward compatibility with inspection middleboxes which >>> expect the length field to be in a particular place. >> >> Given that the rest of TLS 1.3 is

Re: [TLS] Record header size?

DPI, admittedly, is an expensive process that slows down traffic. DPI is even more expensive on a protocol such as TLS where the record headers aren't always in the same place in every packet. DPI is usually off by default on most firewalls. The problem you are more likely to encounter are

[TLS] TRON submission in 2 weeks...

Just a reminder that the TRON workshop [1] initial submission date is December 1st. Please get your good submissions in! (Or hassle folks you know who should be submitting:-) Thanks, S. [1] https://www.internetsociety.org/events/ndss-symposium-2016/tron-workshop-call-papers

Re: [TLS] Record header size?

> On 18 Nov 2015, at 3:32 AM, Peter Gutmann wrote: > > Eric Rescorla writes: > >> The concern here is backward compatibility with inspection middleboxes which >> expect the length field to be in a particular place. > > Given that the rest of TLS 1.3

Re: [TLS] Record header size?

On Thu, Nov 19, 2015 at 12:05:55PM +1000, Michael Gray wrote: > > With several TLS implementations it is possible to completely seperate > > network communication (of the application) from the processing of > > TLS records (performed by the TLS protocol stack). For some TLS > > implementations

Re: [TLS] Record header size?

Short, Todd writes: >I think the philosophy some people are going with, if we're going to break >backwards compatibility, let's do it big time, so that we only have to do >it once, and not make everyone play continuous catchup. Exactly. I'm also not convinced by the