Re: [IPsec] RFC4307 update

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 <paul@nohats.ca> wrote:

> On Fri, 9 Oct 2015, Yoav Nir wrote:
>
> On Sep 28, 2015, at 6:10 PM, Paul Hoffman <paul.hoffman@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
>
>