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
