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
> ago.
> 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 the
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_!
>>
>> Also, things li
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 problem to
> keep the contenttype in the
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
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 bein
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 problem to
>>
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
>> possib
> 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. With the
>>> removal of reneg
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 existing middlewar
10 matches
Mail list logo