Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt

[[e-mail] (Martin Rex)]

Martin Rex wrote:
> Alfredo Pironti wrote:
> > Peter Gutmann <[e-mail]> wrote:
> > > Eric Rescorla <[e-mail]> writes:
> > >
> > >> - Maybe I am misreading the draft, but I'm unclear on how you get
> > >>    the TLSCompressed.length for the MAC computation in Section 3.
> > >>    Does this have the same issue as was raised for McGrew's CBC AEAD
> > >>    draft?
> 
> Eric is correct, the definition of the MAC in Peter's draft is
> obviously incorrect (and likely does not match Peter's implementation):
> 
> TLSv1.0:  https://tools.ietf.org/html/rfc2246#section-6.2.3.1
> 
>    The MAC is generated as:
> 
>        HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type +
>                      TLSCompressed.version + TLSCompressed.length +
>                      TLSCompressed.fragment));
> 
> When changing from mac-pad-encrypt to encrypt-mac, as suggested
> by Peter's draft, the MAC no longer operates on the TLSComressed PDU,
> but on the TLSCiphertext PDU -- which results in:
> 
>        HMAC_hash(MAC_write_secret, seq_num + TLSCiphertext.type +
>                      TLSCiphertext.version + TLSCiphertext.length +
>                      TLSCiphertext.fragment));
> 
>     The computation of TLSCompressed.length on receive changes slightly,
>     because there no longer is a MAC trailing the data after decrypt.

I forgot:
Peter's proposal includes the CBC-IV in the MAC computation for TLSv1.0,
but this isn't technically necessary.  In TLSv1.1, the MAC _must_
include the IV, but the IV is already part of TLSCiphertext.

Curiously, for decrypt, the way the TLSv1.1 GenericBlockCipher PDU 
is specified, it uses a fixed zero IV and a block-sized "random confounder"
that is covered by the MAC, but ignored after decrypt (reminds me of Kerberos)

-Martin