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

From: Peter Gutmann <[email-masked]>
Date: Tue, 17 Jun 2014 20:23:45 +0000

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.

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 18 Jun 2014 14:47:15 +0100

Hi, Peter.
> Apologies for the slow reply, currently travelling with limited Internet
NP. 

Mainly about the rehandshake point (below)...

I think the other points are sorted.
> changing/updating anything else.

Fair enough. Sean T made the same point in a mail you may have seen 
> on EtM then you can't fall back to a non-EtM cipher (see the third line of the

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?  

> >Shouldn't the reference here be [4] for DTLS?

Filleted from my correspondence with Sean:

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

Regards,
Elwyn