> On 10 Nov 2015, at 6:38 PM, Yaron Sheffer <yaronf.i...@gmail.com> wrote: > > A few comments, sorry for not using GitHub. > > I think the following text is kinda funny: "IKEv1 is out of scope of this > document. IKEv1 is deprecated and the recommendations of this document MUST > NOT be considered for IKEv1." We cannot tell people normatively what they can > consider and what they cannot. Let's skip the capitalized MUST NOT.
Sounds reasonable, or even just saying that IKEv1 is out of scope (and therefore we don’t need to say another word about it) > > The rationale for GCM describes why it's in the table, but seems to argue for > a MUST (rather than the SHOULD that's in the table). I guess there's a reason > why we don't have MUST, let's spell it out. Yeah. GCM is faster than CBC+HMAC and can be used for more data. That’s important for IPSec, much less for IKE. More importantly, GCM for IPSec was defined in RFC 4106 in 2005 and is widely implemented. GCM for IKE was defined three years later in RFC 5282, and because the need for encryption performance and key longevity was much less got implemented a lot less. (My company’s product does not have it, for example). The focus of this document is interoperability without security mistakes, so GCM for IKE could be no more than a SHOULD. > "As the overhead of AUTH_HMAC_SHA2_512 is negligible": suggest to change to > "as the *additional* overhead". > > I believe we should cite RFC 6194 when recommending against SHA-1. Recommending against? It’s at MUST- for both MAC and PRF (as HMAC), and we’re currently saying nothing about hashes in signatures. > "As it is not being deployed" - I suggest the softer "as it is not widely > deployed" - we don't really know that nobody had ever deployed it. Agree. I, for one, implemented it, although I have no statistics telling me how many CP customers are actually configuring it. Probably none, because it’s (a) not the default, and (b) slower than GHash on all platforms, and (c) slower than HMAC-SHA1 on older platforms. > "and now it is known to be weak at least for a nation state" - suggest to > change to "and now it is known to be weak against a nation-state attacker". > > Thanks, > Yaron > > On 11/10/2015 12:33 AM, Yoav Nir wrote: >> Or for a diff-style view, see the pull request: >> https://github.com/ietf-ipsecme/drafts/pull/8/files >> >> Yoav >> >>> On 10 Nov 2015, at 12:30 AM, Daniel Migault >>> <daniel.miga...@ericsson.com <mailto:daniel.miga...@ericsson.com>> wrote: >>> >>> Hi, >>> >>> You can view the latest changes here: >>> >>> https://github.com/mglt/drafts/blob/d2d31f6f9f0b4d57c8343826ad23fc546b99a467/draft-ietf-ipsecme-rfc4307bis >>> >>> We added some text to recommend the status of each recommended algorithms. >>> >>> On Mon, Nov 9, 2015 at 11:27 AM, Paul Hoffman <paul.hoff...@vpnc.org >>> <mailto:paul.hoff...@vpnc.org>> wrote: >>> >>> On 9 Nov 2015, at 5:48, Yoav Nir wrote: >>> >>> So I’ve merged the changes and submitted version -01 of the draft. >>> >>> The stub paragraphs explaining the choices of algorithms are >>> waiting to be filled. Please submit pull requests. >>> >>> >>> https://github.com/ietf-ipsecme/drafts/blob/master/draft-ietf-ipsecme-rfc4307bis >>> >>> >>> This is an invitation to the WG to contribute to to this draft. If >>> you are already familiar with GitHub, submit pull requests as Yoav >>> said. If you are not yet familiar with GitHub, feel free to send >>> text to the mailing list, and one of the authors will quickly >>> enter those for you in GitHub. That is, being able to use GitHub >>> is *not* required for you to contribute text. >>> >>> --Paul Hoffman >>> >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org <mailto:IPsec@ietf.org> >>> https://www.ietf.org/mailman/listinfo/ipsec >>> >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org <mailto:IPsec@ietf.org> >>> https://www.ietf.org/mailman/listinfo/ipsec >> >> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
