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

[Eric Rescorla <[e-mail]>]

On Tue, Jul 1, 2014 at 3:09 PM, Daniel Kahn Gillmor <[e-mail]>
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.
>

This seems like an idea with a fair bit of merit, but if I understand
correctly, it's going to result in a stream of data which cannot be
parsed into TLS records by existing network elements.
I'm concerned about how this is going to interact with various
elements which process the ciphertext. For instance:

- Protocol enforcement devices which expect to see a stream of records.
- RFC 5764 elements which multiplex STUN, SRTP, and DTLS and
  use the first byte for this purpose.

I think we can fix the second category by requiring explicit opt-in for
this feature, either by an extension or by it being TLS 1.3 (though
we would still need to define how to demux), but the first category
seems potentially more problematic. It seems like it might be worth
doing some experiments to see what the impact on success rates
is. [0]

-Ekr

[0] If this turns out to be a problem, there is an ugly but workable
solution, which is to have all TLSCiphertext records start with
an application_data type byte, regardless of their content. This
would of course expand packets by one byte.



> All the best,
>
>         --dkg
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>