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 _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
