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

[Nikos Mavrogiannopoulos <[e-mail]>]

On Thu, 2014-10-30 at 01:13 +0100, Martin Rex wrote:

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

Correct. Thus the length sent on the wire must also not include the MAC
size. So is my understanding correct that no deployed implementation is
compliant to rfc7366 so far?

regards,
Nikos