Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

2016-11-03 Thread Ilari Liusvaara
On Thu, Nov 03, 2016 at 08:38:32PM +0200, Yoav Nir wrote: > > > On 3 Nov 2016, at 20:20, Martin Rex wrote: > > > > -- so why would we need a backwards-incompatible change in a > > protocol that protects something that no longer exists, > > but which severely breaks

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

2016-11-03 Thread Yoav Nir
> On 3 Nov 2016, at 20:20, Martin Rex wrote: > > Yoav Nir wrote: >> >> On 3 Nov 2016, at 16:31, Martin Rex wrote: >>> >>> Since then, I've seen exactly ZERO rationale why the cleartext contenttype, >>> which has existed through SSLv3->TLSv1.2 would be a problem.

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

2016-11-03 Thread Benjamin Kaduk
On 11/03/2016 01:15 PM, Martin Rex wrote: > Salz, Rich wrote: >>> Since then, I've seen exactly ZERO rationale why the cleartext contenttype, >>> which has existed through SSLv3->TLSv1.2 would be a problem. >> Because it's kind of implied in the charter, about making as much private as >>

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

2016-11-03 Thread Martin Rex
Yoav Nir wrote: > > On 3 Nov 2016, at 16:31, Martin Rex wrote: >> >> Since then, I've seen exactly ZERO rationale why the cleartext contenttype, >> which has existed through SSLv3->TLSv1.2 would be a problem. With the >> removal of renegotiation from TLSv1.3, it is even less of a

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

2016-11-03 Thread Martin Rex
Salz, Rich wrote: >> Since then, I've seen exactly ZERO rationale why the cleartext contenttype, >> which has existed through SSLv3->TLSv1.2 would be a problem. > > Because it's kind of implied in the charter, about making as much private as > possible. > >> years), because it is actively

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

2016-11-03 Thread Yoav Nir
I don’t think this makes any difference in applications written on commodity servers using regular socket APIs. It’s a kind of architecture that has a quick special purpose processor that terminates the TCP and splits the incoming stream into records. The application records are forwarded to a

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

2016-11-03 Thread Watson Ladd
On Thu, Nov 3, 2016 at 7:31 AM, Martin Rex wrote: > Ilari Liusvaara wrote: Hiding the types does have its benefits (and it is also used for zero-overhead padding scheme). >>> >>> Nope, ZERO benefits. But it totally breaks the middleware >>> _at_the_endpoints_! >> >>

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

2016-11-03 Thread Salz, Rich
> Since then, I've seen exactly ZERO rationale why the cleartext contenttype, > which has existed through SSLv3->TLSv1.2 would be a problem. Because it's kind of implied in the charter, about making as much private as possible. > years), because it is actively being used to signal state of

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

2016-11-03 Thread Martin Rex
Ilari Liusvaara wrote: >>> >>> Hiding the types does have its benefits (and it is also used for >>> zero-overhead padding scheme). >> >> Nope, ZERO benefits. But it totally breaks the middleware >> _at_the_endpoints_! > > Also, things like this should have been discussed like year or two >