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