Hi, Here are my comments on the draft:
I would thought: AES_CBC is no more than MUST- for interoperability but could be dowgraded also to SHOULD. In addition I would also have recommend max length IV for AES-GCM unless there is special constrains like IoT devices. AES-GCM with a 16 octet ICV MUST AES-CCM with a 16 octet ICV MUST Especially thinking of constrained devices. AES-GCM with 8 octet SHOULD : the reason for not having SHOULD+ is that most IoT devices seems to use CCM AES-CCM with 8 octet SHOULD+ I would have thought of 3DES with similar or slightly less weight as CHACHA20_POLY1025 so CHACHA20_POLY1025 SHOULD 3DES SHOULD or SHOULD- I also agree we should mentionned that recommendation only applies to IKEv2. BR, Daniel On Fri, Oct 9, 2015 at 8:19 AM, Paul Wouters <p...@nohats.ca> wrote: > On Fri, 9 Oct 2015, Yoav Nir wrote: > > On Sep 28, 2015, at 6:10 PM, Paul Hoffman <paul.hoff...@vpnc.org> wrote: >>> >>> Sure. Someone volunteer to write up the short draft, and that author >>> should put Jeff Schiller at the top of the acknowledgements, and send it to >>> the WG. >>> >>> --Paul Hoffman >>> >> >> >> A new version of I-D, draft-nir-ipsecme-rfc4307bis-00.txt >> has been successfully submitted by Yoav Nir and posted to the >> IETF repository. >> > > Oops. Guess our drafts crossed the beams. I had send one to Daniel > to look at. I've attached it in case some text is useful. It was > based more on the structure of RFC 7321. > > I actually like how 7321 has the tables filled with links to the > actual RFC's. (which I had not done yet myself) > > Some comments on your text: > > I think AES_CBC should be MUST- as it is on the way out. > > I have talked with one of the AES_GCM authors and got the advise to > only use the largest octet ICV's. Why are you promoting the 8 octet > version instead of the 16 octet version? I also think AES_GCM should > be a MUST, not a SHOULD. It is the preferred algorithm at this point. > > I also think 3DES probably should be a SHOULD- because it is the only > other non-AES algorithm in widespread use. While we all want it to go > away, we should do so only after chacha20-poly1305 sees more adoption. > > Why is sha2-512 not a SHOULD? > > > Can we add a recommendation to use integ == prf for non-AEAD algorithms? > > Windows uses 8192 modp, which I think should be a SHOULD. I think we > should mention modp 1536 as SHOULD- or MAY. > > Can we recommend that the initial exchanges and create child sa use > the same MODP group? and that we recommend PFS for create_child_sa. > > Can we recommend that a default proposal set should have at least one > MUST algorithm for each type? > > Can we recommend not to apply these recommendations for IKEv1 because > that will cause more interop problems (see my draft for text) > > > Paul > _______________________________________________ > 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
