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

["Yngve N. Pettersen" <[e-mail]>]

On Sun, 02 Nov 2014 00:30:58 +0100, Manuel Pégourié-Gonnard  
<[e-mail]> wrote:

> (Cutting a lot of details where we agree about the important points, to  
> get to
> the "what should be done now" part.)
>
> On 01/11/2014 23:23, Yngve N. Pettersen wrote:
>> On Sat, 01 Nov 2014 22:32:17 +0100, Manuel Pégourié-Gonnard
>> <[e-mail]> wrote:
>>> I'm under the impression that Peter's paragraph in [1] suits this goal.
>>>
>>> [1]  
>>> http://mailarchive.ietf.org/arch/msg/tls/3NOHlIUShLo9AAzXx4t2u7QV8Sw
>>>
>>> Do you agree? I reproduce the specific paragraph here for convenience's
>>> sake:
>>>
>>>   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'.
>>
>> It seems to describe the conclusions above, indeed, but personally I  
>> would
>> prefer that the formula should not reference TLSCiphertext.length at  
>> all,
>> but instead refer to the length of the field with the encrypted data, or
>> specifically defined as avariable in a separate formula as 'length -
>> SecurityParameters.mac_length'. Less chance of confusion, that way, and
>> having multiple values of a variable is never a good idea, unless it is
>> inside an algorithm that explicitly update the values as part of a step,
>> after it was used for something.
>>
> 100% agreed, I think for me the use of the same name for two different  
> values
> was the root cause of the confusion. How about combining Peter's above  
> paragraph
> with my proposed rewriting of the MAC calculation as:
>
>            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));
>
>     where the length is encoded as two bytes in the usual way.
>
> It's admittedly not he most elegant, but at least it's clear and  
> unambiguous,
> which is probably more important than elegance for an erratum.

That looks fairly OK to me.

A possible tweak one could add, is to define

     encrypted_content = ENC(content + padding + padding_length)

and use that in the formula instead.



-- 
Sincerely,
Yngve N. Pettersen

Using Opera's mail client: http://www.opera.com/mail/