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

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

On 29/10/2014 15:38, Peter Gutmann wrote:
> Manuel Pégourié-Gonnard <[e-mail]> writes:
> 
>> What I'm doing to get this is interpret TLSCipherText.length exactly as it is
>> defined in RFC 5246 (6.2.3.2, page 22):
>>
>>   The encrypted data length (TLSCiphertext.length) is one more than the
>>   sum of SecurityParameters.block_length, TLSCompressed.length,
>>   SecurityParameters.mac_length, and padding_length.
>>
>> Apparently to interoperate with the implementation at eid.vx4.net (and with
>> OpenSSL 1.1.0-dev) one needs to rather interpret it as excluding
>> SecurityParameters.mac_length. I couldn't find this explicitly stated
>> anywhere.
> 
> Section 3 of RFC 7366 says:
> 
>   In [2] notation the overall packet is then:
> 
>    struct {
>           ContentType type;
>           ProtocolVersion version;
>           uint16 length;
>           GenericStream/BlockCipher fragment;
>           opaque MAC;
>           } TLSCiphertext;
> 
>    This is identical to the existing TLS layout with the only difference
>    being that the MAC value is moved outside the encrypted data.
> 
Precisely. The *only* difference is (something that doesn't involve the
definition of length), so the definition of the length is unchanged, therefore
it's the one from RFC 5246.

Anyway, let's take it from another angle: TLSCipherText.length is what goes on
the wire, right? So:
1. It has to include the (length of the) MAC.
2. The eid server is contradiction with RFC 7366, since using the length that
goes on the wire to compute/check the MAC makes interop with it fail.

It doesn't get any simpler: is the length used in the MAC the same as the one
going on the wire?

Manuel.