Re: [TLS] draft-petithuguenin-avtcore-rfc5764-mux-fixes-00

[Yoav Nir <[e-mail]>]

On Jul 23, 2014, at 4:41 PM, Martin Thomson <[e-mail]> wrote:

> On 23 July 2014 12:44, Martin Rex <[e-mail]> wrote:
>> There has been a proposal to hide the ContentType for TLSv1.3
>> and break lots of existing software that relies on being able
>> to parse TLS records:
> 
> We discussed fixing that at the interim meeting where that proposal
> was discussed.  The fix is trivial; we could, for instance, always
> send 23.  Or, we could use Fluffy's proposed new registry to obtain a
> different demux byte value.  I suspect that the former is fine.

We also talked about padding to hinder traffic analysis. I think we can solve both at the same time by doing something like this (sorry for not using TLS curly bracket notation):

Record header remains the same, except the contentType 23 gets renamed to “encrypted”.

When decrypted, the encrypted record has a three-byte header:
  1 byte - ContentType. Either 23 means “application data” here, or we use a new number for it. something else for alert, etc. Zero can be used for a special, all-padding record that can be discarded.
  2 bytes - length. The difference between the decrypted length and this field is the padding.

If we limit ourselves to only 4 types of encrypted record (app data, alert, padding and some yet unspecified fourth type - handshake?) we can use a 2-byte header and use the two free bits from the TLS record length.

Yoav