Hi, Please find an new update: 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 <[email protected] > 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 <[email protected]> > 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 >>> >>> 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 <[email protected] >>> <mailto:[email protected]>> 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). >>> -- >>> [email protected] <mailto:[email protected]> >>> >>> _______________________________________________ >>> IPsec mailing list >>> [email protected] <mailto:[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
