Re: [TLS] rfc7366: is encrypt-then-mac implemented?

[Manuel Pégourié-Gonnard <[e-mail]>]

On 30/10/2014 14:40, Peter Gutmann wrote:
> Manuel Pégourié-Gonnard <[e-mail]> writes:
> 
>> Are you refering the "normal" (MtE) case or the EtM case here? 
> 
> The EtM case.  In the MtE case what gets MAC'd is the plaintext, i.e. only
> TLSCompressed.fragment.  In the EtM case what gets MAC'd is the ciphertext
> including padding and other stuff, so GenericBlockCipher.fragment.
> 
Ok. I'm not sure if it's a good idea to use GenericBlockCipher.fragment to
denote this. GenericBlockCipher is a struct defined with a different meaning in
RFC 5246.

>>   MAC(MAC_write_key, seq_num +
>>       TLSCipherText.type +
>>       TLSCipherText.version +
>>       length of ENC(content + padding + padding_length) +
>>       IV +
>>       ENC(content + padding + padding_length));
>>
>>    where the length is encoded as two bytes in the usual way.
> 
> That's still not quite right though because it excludes the length of the IV
> when it's present in TLS 1.1+ (see above).

You're right obviously. So I change my suggestion to:

           In TLS [2] notation, the MAC calculation for TLS 1.0 without
   the explicit Initialization Vector (IV) is:

   MAC(MAC_write_key, seq_num +
       TLSCipherText.type +
       TLSCipherText.version +
       length of (ENC(content + padding + padding_length)) +
       ENC(content + padding + padding_length));

   and for TLS 1.1 and greater with an explicit IV is:

   MAC(MAC_write_key, seq_num +
       TLSCipherText.type +
       TLSCipherText.version +
       length of (IV + ENC(content + padding + padding_length)) +
       IV +
       ENC(content + padding + padding_length));

   MAC(MAC_write_key, seq_num +
       TLSCipherText.type +
       TLSCipherText.version +
       length of (IV + ENC(content + padding + padding_length)) +
       IV +
       ENC(content + padding + padding_length));

    where the length is encoded as two bytes in the usual way.

since the text is already distinguishing between the two.

>  The intent of using
> TLSCipherText.length was to accommodate the different protocol-version-
> dependent options.
> 
Ok. I'm afraid here we have a conflict between being concise and being
unambiguous, and I'd err on the side of unambiguous.

> What about defining it the other way round, instead of saying "the length used
> is this and that and sometimes something else", say "the length value used for
> the MAC computation is the length as encoded on the wire minus
> SecurityParameters.mac_length, since the MAC value is not included in the MAC
> computation"?

Sounds like a good idea, but there is the minor problem that currently the
length on the wire is defined after the MAC computation is defined.

>  So perhaps:
> 
>   Note that the value of the 'uint16 length' field in the TLSCiphertext record
>   differs from the length value used in the MAC calculation, since the
>   TLSCiphertext record contains both the ciphtertext and the MAC, while the
>   MAC calculation is performed only over the ciphertext.  So the length value
>   encoded in the TLSCiphertext record is 'length' while the length value used
>   in the MAC calculation is 'length - SecurityParameters.mac_length'.
> 
That sounds pretty clear to me. A belt-and-braces approach could even combine
this paragraph with my above suggestion...

Manuel.