[Swan-dev] what key-lengths to propose for IKEv2 ike=aes-... and esp=aes-...

[Paul Wouters]

On Mon, 28 Nov 2016, Andrew Cagney wrote:

> Given IKEv2 config lines like:
>
>    ike=aes-...
>    esp=aes-...
>
> i.e., when no key length was explicitly specified, then pluto will propose:
>
>   ike: aes_256 then aes_128
>   esp: aes_128 then aes_256
>
> i.e., ike and esp have key-lengths in the opposite order
>
> The behaviour is long standing - tests require this - but I'm left
> wondering how much of this still makes sense.

It does not make sense, and it should not be like that. The odd thing
with key length was that RFC 4307 and RFC 7321 only have 128 bit as
mandatory to implement.

7321bis and 4307bis we fixed this and 128 and 256 are at MUST, and
192 remains at MAY.

But this does not take into account IKEv1 versus IKEv2. IKEv1 stacks
of proprietary vendors are basically frozen, so they will not get
the updates of the bis documents. Additionally, the IKEv1 defaults
are DH5 and DH2, so it might not make as much sense to use 256 bit
per default there.

So my suggestion would be:

default to send both 128/256 and prefer 256 for both IKE and ESP

I thought about for IKEv2 initiator sending 256 only, and for
responder to accept either, but that would be confusing as
the same keyword could then lead to different things depending
on initiating/responding.

Some people believe 128 is fine and the overhead of 256 is too expensive
(like IoT stuff) but I'm fine with those people needing to specify
aes128 specifically.

Paul