Re: [Gen-art] Gen-art LC review of draft-ietf-tls-encrypt-then-mac-02

[Peter Gutmann <[e-mail]>]

Apologies for the slow reply, currently travelling with limited Internet
access...

>Header/Abstract/Intro: Doesn't this update RFC 6347 and either or both of RFC
>6066 and RFC 5246 since it defines a new extension?

It doesn't really update any other RFC, it does add a new extension but then
the purpose of having generic extensions is that they don't require
changing/updating anything else.

>s3.1: [I am not a TLS expert so I may not have got this right...] If the
>rehandshake proposes to use a cipher that doesn't need encrypt-then-mac as
>per GenericStreamCiphers, or GenericAEADCiphers as mentioned in s3, then
>presumably this is allowed whether encrypt-then-mac had or had not been
>negotiated previously on the session.  It should be clarified whether this is
>allowed and, if it isn't, what the response should be.

It shouldn't be allowed since it's falling back to a non-EtM form.  It doesn't
matter what the cipher form is (stream cipher or whatever), once you've agreed
on EtM then you can't fall back to a non-EtM cipher (see the third line of the
table in section 3.1).

>s3: (very nitty nit)  I think the MAC calculation piece would be clearer with
>what it updates noted before the update. Thus:

OK, fixed.

>s3, next to last para:
>> For DTLS, the record MUST be discarded and a fatal bad_record_mac MAY
>>    be generated [2].
>Shouldn't the reference here be [4] for DTLS?

Oops, yep.  Also fixed.

>s3.1 (last para)/s7.1: Shouldn't the TLS_ext reference [3] be to the updated
>RFC 6066?

Ah, yes.  Also fixed.

Peter.