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

[[e-mail] (Martin Rex)]

Nikos Mavrogiannopoulos wrote:
> On Wed, 2014-10-29 at 15:30 +0000, Peter Gutmann wrote:
>> Manuel Pégourié-Gonnard <[e-mail]> writes:
>> 
>>>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.
>> 
>> No it isn't.  RFC 7366 moves the MAC outside the GenericXXXCipher fragment,
>> so it's no longer included.
> 
> I don't think it matter that the MAC is outside the GenericXXXCipher
> fragment.

On the contrary, this matters a whole lot.



> TLSCiphertext is defined in RFC7366 as follows:
> 
>    struct {
>           ContentType type;
>           ProtocolVersion version;
>           uint16 length;
>           GenericBlockCipher fragment;
>           opaque MAC;
>           } TLSCiphertext;
> 
> (for block ciphers at least). That TLSCiphertext.length send on the wire
> contains both fragment and MAC length, doesn't it?


This is the rfc5246 definition of TLSCiphertext and the explanation
of the "length" element within that structure:

http://tools.ietf.org/html/rfc5246#section-6.2.3

      struct {
          ContentType type;
          ProtocolVersion version;
          uint16 length;
          select (SecurityParameters.cipher_type) {
              case stream: GenericStreamCipher;
              case block:  GenericBlockCipher;
              case aead:   GenericAEADCipher;
          } fragment;
      } TLSCiphertext;

   type
      The type field is identical to TLSCompressed.type.

   version
      The version field is identical to TLSCompressed.version.

   length
      The length (in bytes) of the following TLSCiphertext.fragment.
      The length MUST NOT exceed 2^14 + 2048.

   fragment
      The encrypted form of TLSCompressed.fragment, with the MAC.


In rfc5246, the "length" element of the TLSCiphertext structure
contains the length of the "fragment" element directly following it,
and rfc7366.   But rfc7366 moves the MAC outside of the fragment,
so its length will no longer be included in the TLSCiphertext.length
count.


Curiously, rfc7366 doesn't indicate the real length of the MAC element
in the same fashion that rfc5246 does:

  rfc5246:   opaque MAC[SecurityParameters.mac_length];

  rfc7366:   opaque MAC;

...but then, rfc2246 and rfc4346 used slightly different names/terminology
for the SecurityParameters, and would use:
             opaque MAC[SecurityParameters.hash_size];



-Martin