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

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

Hi,

On 23/10/2014 15:36, Nikos Mavrogiannopoulos wrote:
>  Is there some public server implementing rfc7366? At some point the
> server at eid.vx4.net was sent as one, but it doesn't seem to implement
> the protocol in the published rfc (the NSS people seem to have noticed
> that [0], and my tests agree).
> 
I'm not aware of any other public server implementing RFC 7366, but I'd like to
mention I just implemented it and ran tests against your etm branch, and our
implementations interoperate fine with all the CBC suites we have in common, in
all versions of TLS (I didn't test DTLS yet, though).

My implementation does not interoperate with the one at eid.wx4.net either, when
I enable EtM (fails with a bad_record_mac alert).

I think the use of TLSCipherText.length in RFC 7366 is a bit confusing, since
TLSCipherText is defined in terms of GenericBlockCipher, the very structure that
this RFC is changing. It makes it unclear if the following sentence from RFC
5246 still applies:

   The encrypted data length (TLSCiphertext.length) is one more than the
   sum of SecurityParameters.block_length, TLSCompressed.length,
   SecurityParameters.mac_length, and padding_length.

IMO it should, since moving the MAC outside the encryption does not change the
definition of the final length (though it may change the actual length in case
mac_length is not a multiple of block_length).

I guess the author of the implementation at eid.vx4.net thought otherwise.

Manuel.