Re: [TLS] Encryption of TLS 1.3 content type

[Andy Lutomirski <[e-mail]>]

On 07/28/2014 03:52 AM, Yoav Nir wrote:
> 
> On Jul 28, 2014, at 11:55 AM, Nikos Mavrogiannopoulos <[e-mail]> wrote:
> 
>> On Sat, 2014-07-26 at 10:59 -0700, Colm MacCárthaigh wrote:
>>> On Sat, Jul 26, 2014 at 10:43 AM, Watson Ladd <[e-mail]>
>> wrote:
>>>> This is a change with no rationale: the content type leaks extremely
>>>> limited information. It complicates implementations that wish to
>> keep
>>>> a high degree of codepath similarity between TLS 1.2 and TLS 1.3.
>>> Leaking alert messages has been a recurring theme common to several
>>> attacks; hindering a MITM's ability to discern alert messages seems
>>> like a rational rationale.
>>
>> Are there any pointers to these attacks? Will these attacks be countered
>> with such a change? I believe not as alert messages consist of only two
>> bytes and will be distinct from any other higher protocol messages
>> transferred by the TLS record protocol. Unless TLS 1.3 intended to
>> include a length hiding mechanism I see this change as unnecessary and I
>> agree with Watson on that.
> 
> While no definite decisions were made, there was a positive response to the idea of allowing arbitrary length padding to the plaintext in all encrypted records, which can be used to hide alert messages. 
> 
> Of course, non-fatal alerts are (1) rare, and (2) not always treated as such, so it’s easy to spot the alert record, because it’s the one before the FIN or RST. In DTLS alerts are mostly non-fatal, so it makes more sense.
> 
> So on balance, +1.

To clarify the relationship between encrypted content types and padding:

In order to pad messages, we need to encode the amount of padding
somehow so that the receiver can strip the padding.  That means that an
unpadded message has to be distinguishable (by the peer) from a padded
message.  If we can steal a bit from the content type to indicate the
presence of a nonzero amount of padding, then we can do this with no
size overhead for unpadded messages.

For this to work, the content type must be encrypted.

--Andy