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

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

On 30/10/2014 14:45, Henrick Hellström wrote:
> On 2014-10-30 14:40, Peter Gutmann wrote:
>> The correct notation to use is quite confusing, intuitively you can say "the
>> length used in the MAC calculation is the length of the data that gets MAC'd",
>> but specifying it in notation isn't so easy, it's the length of the padded
>> encrypted TLSCompressed value as well as the length of the IV if TLS 1.1 or
>> newer is used.  If there's some clear way of saying that that, say, at least
>> three different people can agree on I'll use it.
> 
> Would it be overkill to define a new TLSIntermediaryCiphertext record type?
> 
Another (related) idea: explicitly change the definition of
GenericBlockCipher when EtM is in use (which is already implicitly done
at some point). Eg (unchanged text is indicated by a | in the margin,
left there for context at the beginning):

 | Once the use of encrypt-then-MAC has been negotiated, processing of
 | TLS/DTLS packets switches from the standard:
 |
 | encrypt( data || MAC || pad )
 |
 | to the new:
 |
 | encrypt( data || pad ) || MAC
 |
   with the MAC covering the encrypted data as well as metadata, as
   described below.  In TLS [2] notation, the definition of
   GenericBlockCipher is changed, for TLS 1.0 without the explicit
   Initialization Vector (IV), to:

      struct {
          block-ciphered struct {
              opaque content[TLSCompressed.length];
              uint8 padding[GenericBlockCipher.padding_length];
              uint8 padding_length;
          } ciphertext;
          opaque MAC[CipherSpec.hash_size];
      } GenericBlockCipher;

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

      struct {
          struct {
              opaque IV[SecurityParameters.record_iv_length];
              block-ciphered struct {
                  opaque content[TLSCompressed.length];
                  uint8 padding[GenericBlockCipher.padding_length];
                  uint8 padding_length;
              };
          } ciphertext;
          opaque MAC[SecurityParameters.mac_length];
      } GenericBlockCipher;

   All fields have the same definition as in RFC 2246 and RFC 5246
   respectively, except the MAC which is:

 | MAC(MAC_write_key, seq_num +
 |     TLSCipherText.type +
 |     TLSCipherText.version +
       length of GenericBlockCipher.ciphertext +
       GenericBlockCipher.ciphertext);

   where the length is encoded as two bytes in the usual way.
 | (For DTLS, the sequence number is replaced by the combined epoch and
 | sequence number as per DTLS [4].)
   The input to the MAC function differs from the data sent on the wire
   in two few ways: the first is the prepended sequence number (which,
   with TLS is not on the wire, and with DTLS is on the wire in a
   different position); the second is that the length on the wire
   includes the length of the MAC while the lenght in the input of the
   MAC function does not.

 | Note from the GenericBlockCipher annotation that this only applies to
 | standard block ciphers that have distinct encrypt and MAC operations.
   [rest of the section unchanged]
   [note: no need to recall/redefine TLSCiphertext any more]

Please criticize! (An obvious drawback is it looks quite heavy for an erratum,
compared to the other idea that changes only a few lines.)

Manuel.