Hello Daniel, One minor typo: "PRF_AES128_CBC has been downgraded from SHOULD in RFC4307” should be "PRF_AES128_CBC has been downgraded from SHOULD+ in RFC4307"
On a broader note, many of the SHOULD algorithms (ENCR_AES_CCM_8, PRF_AES128_CBC, AUTH_AES-XCBC) are justified as being present for the purposes of Internet of Things devices. I tend to think that it would be more straightforward to have a separate document that explains the preferred algorithms for IoT devices (an IKEv2 profile for IoT, for example). However, if we do want to keep them in this document, I think it would help to have a section in the introduction to the document explaining the use case for the IoT devices and why they are now included in the bis document, whereas they were not relevant yet in RFC 4307. It may also be helpful to qualify the SHOULDs as pertaining more, perhaps, to servers; traditional VPN clients would generally not be interacting with IoT devices directly, and thus would have little reason to implement these algorithms. Thanks, Tommy > On Nov 20, 2015, at 8:28 AM, Daniel Migault <daniel.miga...@ericsson.com> > wrote: > > Hi, > > Please find an new update: > https://github.com/mglt/drafts/commit/1854f98fdc1ee340565d6758e8d4642500af1c2f > > <https://github.com/mglt/drafts/commit/1854f98fdc1ee340565d6758e8d4642500af1c2f> > > Change 1: AUTH_AES_XCBC_96 and PRF_AES128_CBC are set to SHOULD instead of a > MAY. I was suprised PRF was already SHOULD. In each case, explanation text > has been added. > > Change 2: Titles of the subsections have also been updated to better fit IANA > designation. > Change 3: Sections have been re-ordered so from Typpe 1 / Type 3 / Type 2 / > Type 4 to Type 1/ Type 2/ Type 3 / Type 4. > > Feel free to comment. > > BR, > Daniel > > > > > On Wed, Nov 18, 2015 at 4:04 PM, Daniel Migault <daniel.miga...@ericsson.com > <mailto:daniel.miga...@ericsson.com>> wrote: > Hi Yaron, > > I just committed your correction. You are right this is much better. > > BR, > Daniel > > On Mon, Nov 16, 2015 at 12:41 PM, Yaron Sheffer <yaronf.i...@gmail.com > <mailto:yaronf.i...@gmail.com>> wrote: > Looks good. One small correction: > > many IKEv2 have not implemented => many IKEv2 implementations do not include > > Thanks, > Yaron > > > On 11/16/2015 06:05 PM, Daniel Migault wrote: > Hi, > > Thank you Yaron for your comments. Please find the new update ot the draft: > > https://github.com/mglt/drafts/commit/0b2696ada172163930f3733a7c3155d49bca0002 > > <https://github.com/mglt/drafts/commit/0b2696ada172163930f3733a7c3155d49bca0002> > > Comment 1: > IKEv1 is out of scope of this document. IKEv1 is deprecated and the > recommendations of this documentmust not be considered for IKEv1. > > I change MUST NOT in must not. I left the whole sentence as I beleive, > it provides the reason why IKEv1 is not in scope and state clearly that > applying considerations in this document to IKEv1 is a bad idea. > > Comment 2: > I added some clarifying text on why not MUST. To me the obvious reason > is that an algorithm not mentioned in RFC4307 should not have a status > greater than SHOULD -- unless otherwise of course ;-). I though we had > this explanation somewhere, but maybe it is missing and should be added > in the intro for example. > > I also provided dome explanation why ESP and IKEv2 are in a different > race which resulted in having AES-GCM not widely deployed for IKEv2 > > Comment 3: > "As it is not being deployed" as been replaced by "as it is not widely > deployed" > > "and now it is known to be weak at least for a nation state" has been > changed to "and now it is known to be weak against a nation-state attacker". > > Acknowledgement section has also been updated. > > BR, > Daniel > > > On Tue, Nov 10, 2015 at 4:01 PM, Tero Kivinen <kivi...@iki.fi > <mailto:kivi...@iki.fi> > <mailto:kivi...@iki.fi <mailto:kivi...@iki.fi>>> wrote: > > Yaron Sheffer writes: > > 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. > > The reason for that is that it is not needed as IKEv2 SA is never used > to transmit huge amounts of data, thus the speed benefits you might > get from there is not needed. Also support for the combined modes do > require support for RFC5282, and there are implementations which have > not done that (as there is no benefits or need for them to implement > it). > -- > kivi...@iki.fi <mailto:kivi...@iki.fi> <mailto:kivi...@iki.fi > <mailto:kivi...@iki.fi>> > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org <mailto:IPsec@ietf.org> <mailto:IPsec@ietf.org > <mailto:IPsec@ietf.org>> > https://www.ietf.org/mailman/listinfo/ipsec > <https://www.ietf.org/mailman/listinfo/ipsec> > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org <mailto:IPsec@ietf.org> > https://www.ietf.org/mailman/listinfo/ipsec > <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
