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

[Elwyn Davies <[e-mail]>]

Hi, Peter.
On Tue, 2014-06-17 at 20:23 +0000, Peter Gutmann wrote:
> Apologies for the slow reply, currently travelling with limited Internet
> access...
NP. 

Mainly about the rehandshake point (below)...

I think the other points are sorted.
> 
> >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.

Fair enough. Sean T made the same point in a mail you may have seen 
> 
> >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).

This seems a bit odd.  I thought s3 said it was OK to use one of the
ciphers mentioned without EtM, apparently because it is deemed secure
enough without changing to EtM.  Apologies if I am being stupid here,
but could you explain why it is no longer secure enough after using an
EtM cipher?  

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

Filleted from my correspondence with Sean:

======================
> > > Shouldn't the reference here be [4] for DTLS? 
> > 
> > Nope - the bad_record_mac is defined in [2].  DTLS and TLS share some 
> > things: e.g., alert protocol values.
> > 
> True; However s4.1.2.1 of [4] has quite a lot to say about exactly this
> situation.  I'd be inclined to s/[2]/as discussed in Section 4.1.2. of [4]/.
======================

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

Regards,
Elwyn