Re: [TLS] proposal to encrypt ContentType for TLS 1.3

If I'm reading this properly, there would be two types of records on
the wire: TLSCiphertext and TLSPlaintext.
However, I don't see a very reliable, documented way to distinguish
between the two on the wire.

I assume that the intention is to distinguish based on the state of
the TLS handshake. i.e.: the record until the first CCS (included) are
TLSPlaintext records, the ones after that are TLSCiphertext records.

I can see a couple scenario where this could be a problem:
- In some case, the piece of code that does the parsing has no
knowledge of the state of the TLS handshake (this is similar to Martin
Rex objection, I think)
- In DTLS, records maybe dropped, received out of order, received
multiple times, etc, so TLSPlaintext and TLSCiphertext records aybe
intermixed, without a clear switchover point. This would make
efficient DTLS difficult.

In practice, I note that, if the ProtocolVersion field stays, it would
be fairly easy to disambiguate TLSCiphertext from TLSPlaintext based
on the first byte, as long as the first byte of the version stays 0x3,
and 0x3 is never a valid ContentType. Except in situations where the
first byte is already overloaded (i.e.:  RFC 5764).

If the ProtocolVersion field is also removed, then there will be
ambiguity between a TLSPlaintext record and a TLSCiphertext of a
specific size.

If the record format needs to change, I suggest allocating a new
reserved ContentType to indicate TLS 1.3 records of all type, and have
the actual content type in the encrypted portion.

I guess that the resulting implementations would not be that different
from what implementations have to do today to support SSL2 ClientHello
records on the server side. (In that case you can tell SSL2 records
because the first byte is 0x80 for SSL2)

In any case, whatever the final TLS 1.3 record format(s) look like, I
hope someone spend some time explaining how an implementer is supposed
to reliably distinguish between the various types of records (SSL2,
TLS 1.2, TLS 1.3) in both the TLS and DTLS scenarios.

On Tue, Jul 1, 2014 at 3:09 PM, Daniel Kahn Gillmor
<dkg@fifthhorseman.net> wrote:
> hey folks--
>
> i just opened a pull request to propose that the TLS ContentType (when
> actually using a proper cipher) should itself be encrypted, rather than
> in the clear:
>
>  https://github.com/tlswg/tls13-spec/pull/51
>
> As the main commit in this request says:
>
>>     Move Content Type inside encryption
>>
>>     Previous versions of TLS have left the Content Type in the clear
>>     without justifying the exposure of this piece of information.
>>
>>     This change moves the Content Type inside the encryption to protect
>>     its confidentiality.
>>
>>     For backward compatibility during the initial handshake negotiation,
>>     we need to keep the type field at its original location on the wire
>>     for cleartext packets.  This means redefining the NULL_NULL case to
>>     not simply be an pseudo-cipher that implements the identity
>>     transformation, but to explicitly state it as sending the TLSPlaintext
>>     struct directly over the wire.
>
> I'd be interested in feedback on this suggestion.
>
> Having the content-type encrypted would mean that TLS alerts,
> handshakes, and application data would be indistinguishable from one
> another to an observer, once a ChangeCipherSpec had taken place.
>
> This also opens the way to consider the creation of other content types
> (e.g. "padded application data") without having to decide whether the
> exposure of a novel ContentType to an observer is itself a risk.
>
> If this change is made, it's also relatively easy to just drop the TLS
> version field for each encrypted TLS record layer fragment.
>
> All the best,
>
>         --dkg
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>