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

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

(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.

> I'm just putting it on the table as a (worst case) possibility; an  
> intermediate solution might be a new RFC obsoleting 7366, just updating  
> the text, if the errata text would be too extensive.
> 
Ok, it never hurts to consider possibilities. I'm not experienced enough with
the standards process to have an opinion on this one. I think it's clear that we
want an erratum soon regardless of what is or isn't deemed necessary later.

>> I'd expect any half-serious implementer to test interop with at least one
>> other implementation before releasing. Unfortunately, experience proves
>> people are not always serious about it. I honestly don't know.
>
> The possible issue is that a version might get widely deployed before a  
> specific issue is properly documented; just as examples of such issues are  
> version and extension intolerance, and personally, the SNI implementation  
> I originally wrote for Opera caused it to crash when actually encountering  
> a server responding to the SNI extension. Might not happen in this case,  
> since I am not aware of any actually deployed servers or clients.
> 
Yes, that sort of thing is unfortunately can't be ruled out. As above, I
honestly don't know what the best approach is, but it probably starts with an
erratum, and hopefully also ends with the erratum!

Manuel.