Thanks for the feed back Valery. I am just waiting a bit in order to see if there is a consensus in
a) not using suites that badly interfere with some extensions vs b) mentioning the suites must not be used wit these extensions. a) is definitively safer, but we may need b) later as well. Yours, Daniel On Sun, Nov 12, 2017 at 9:51 AM, Valery Smyslov <[email protected]> wrote: > Hi Daniel, > > > > thank you for addressing that. I have no problems with your text. > > There are two nits, however. First: in phrase ”allow the Message ID to be > re-initialized” > > I would use some other word instead of “re-initialized”, e.g. “reused”, > > or “repeated”. And second: I would change “IANA is expected” > > to “IANA is requested” or smth similar. > > > > Regards, > > Valery. > > > > > > Hi, > > This is the text I propose to address Valery comment regarding the IANA > consideration section. Let me know if you have any comment on that. > > Yours, > > Daniel > > > 8. IANA Considerations > > AES-CTR, AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to > implement the implicit IV described in this document. This section > limits assignment of new code points to the recommended suites > provided in [RFC8221], thus the new Transform Type 1 - Encryption > Algorithm Transform IDs are as defined below: > > - ENCR_AES_CCM_8_IIV > > - ENCR_AES_GCM_16_IIV > > - ENCR_CHACHA20_POLY1305_IIV > > [RFC8247] recommends the same suites for IKEv2. However some IKEv2 > extensions such as [RFC6311] or [RFC7383] allow the Message ID to be > re-initialized, which is incompatible with the uniqueness property of > the nonce, and makes these suites highly insecure. Given that the > traffic associated to IKEv2 is expected to remain low compared to the > ESP traffic, the suites defined in this document MUST NOT be used for > IKEv2. The IANA is expected to put "Not allowed" in the column > "IKEv2 Reference" for these transforms. > > > > On Mon, Oct 30, 2017 at 8:28 AM, Valery Smyslov <[email protected]> wrote: > > Sorry, I made a typo (see below): > > > 2. IANA Considerations > > > > AES-CTR, AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to > > implement the implicit IV described in this document. This section > > limits assignment of new code points to the recommended suites > > provided in [I-D.ietf-ipsecme-rfc4307bis] and > > [I-D.ietf-ipsecme-rfc7321bis], thus the new Transform Type 1 - > > Encryption Algorithm Transform IDs are as defined below: > > > > The newly defined IIV transforms are not applicable for IKEv2 > (because there is no unique per message field; > > Message ID do can repeat, e.g. in case RFC6311 or RFC7383 is used). > So, [I-D.ietf-ipsecme-rfc7321bis] > > [I-D.ietf-ipsecme-rfc4307bis] of course. > > > (now RFC8247) must not be referenced here. Moreover, I'd like to > express this prohibition > > more explicitly in IANA registry, instructing IANA to put "Not > allowed" in the column "IKEv2 Reference" > > for these transforms: > > So, the correct text is: > > AES-CTR, AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to > implement the implicit IV described in this document. This section > limits assignment of new code points to the recommended suites > provided in [I-D.ietf-ipsecme-rfc7321bis]. Note, that using > implicit IV for these > algorithms is defined for ESP only and is not allowed for > protecting > IKEv2 messages. > > IANA is requested to add the following transforms to the Transform > Type 1 - > Encryption Algorithm Transform IDs registry for IKEv2, setting > "ESP Reference" > to this document and marking "IKEv2 Reference" as "Not allowed": > > Regards, > Valery. > > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec > >
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
