Hannes Tschofenig <hannes.tschofe...@gmx.net> wrote:
> 
> On 10/10/2017 10:52 AM, Martin Rex wrote:
>> Nope, none at all.  I'm _not_ asking for protocol changes, just that
>> the TLS handshake continues to end with CCS + HS, and ContentTypes
>> remain visible.  Contents of all handshake messages, and whether
>> and how that content is protected, remains subject to negotiated
>> protocol version which may vary significantly.
> 
> FWIW: Making the ContentType visible is a protocol change since the
> current version of the TLS / DTLS 1.3 protocol encrypts them.

I haven't looked at DTLS 1.3, but from what I remember TLS 1.3
has _two_ ContentTypes, one in the clear in the original TLS record
structure, and one encrypted, and the cleartext ContentTypes is
IIRC specified to contain bogus/misleading information.

Since hiding of the ContentType provides ZERO[*] security value,
fixing the cleartext ContentType to carry the true value is not
really a protocol change.

Conceptually, for the TLS *ENDPOINTS*, I prefer a code layering approach
with a transport-free TLS implementation by a huge margin.
Falling up and down huge callstacks with arbitrarily incomplete TLS records
results in huge amounts of complex, poor and inefficent code.

And the IO middleware layer should not have to bother with TLS protocol
versions.


-Martin

 [*] the security value of the hidden ContentType is zero, because
when capturing an entire TLS session, one will be able to
identify the real content types context-free heuristically in 99.5% of
the time looking at all records, and when knowing the server, one
can determine all the content types in 99,9999% of the time.

The hiding of the content type is only sufficiently awkward
to break streaming IO of communication layers above TLS, as well
as efficient connection state management.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Reply via email to