On Fri, 9 Oct 2015, Yoav Nir wrote:
On Sep 28, 2015, at 6:10 PM, Paul Hoffman 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-ipse
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 MUS
On Fri, 9 Oct 2015, Daniel Migault wrote:
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 prefer that constrained devices put their specs in
draft-ietf-l
Hi.
I’ll reply to Daniel’s and Paul’s comments. Note that this draft is a starting
point to feed into discussion. Just like this kind of discussion.
Re: ENCR_AES_CBC. If someone wanted to build an IKEv2 implementation with only
one algorithm, the choice for maximum interoperability would be AES
RFC 4307 just barely mentions key lengths, by implying that ENCR_AES_CBC
really means AES-128-CBC. I think the new document should be clear about
recommended key lengths for the relevant algorithms. This may be opening
a can of worms, but you don't have interoperability without it.
Thanks,
On Fri, 9 Oct 2015, Yoav Nir wrote:
Re: ENCR_AES_CBC. If someone wanted to build an IKEv2 implementation with only
one algorithm, the choice for maximum
interoperability would be AES-CBC. This is the same as 3DES-CBC when RFC 4307
was published. I didn’t make it a MUST- because
I don’t know wh
On Fri, 9 Oct 2015, Yaron Sheffer wrote:
RFC 4307 just barely mentions key lengths, by implying that ENCR_AES_CBC
really means AES-128-CBC. I think the new document should be clear about
recommended key lengths for the relevant algorithms. This may be opening a
can of worms, but you don't have
Hi,
OpenBSD includes IKEv2 support since the 4.8 release in 2010. The
software aka. OpenIKED is an independent, ISC-licensed, and open
source implementation that focusses on simplicity and proactive
security. I'm the main author but it has turned into a group effort
with a number of contributors.