Re: [Lwip] [IPsec] draft-ietf-lwig-minimal-esp shepherd writeup

[Tero Kivinen <[e-mail]>]

Paul Wouters writes:
> Reading back now, I think with some clarifications added, I am okay
> with the document. I think the list of clarifications we now have is:

I think your list of things to add is mostly ok.

Note, that on some enviroments creating random numbers is possible,
but it takes time, and power to do so. For example it might be that
hardware random number generator is normally powered off, and is only
powered on during the IKE SA creation phase, and can only create
random numbers at very limited speed. It also might require some time
do self tests, calibration etc before it can be used, so using it per
packet might not be usable, while using it for generating randomness
during the initial phase is no problem.

Perhaps all this should be collected to one new section of the draft,
explaining that you do need proper randomness for Diffie-Hellman etc,
but for ESP you might not need proper random number generators.

> - A clear section on why AES-CBC/3DES-CBC cannot be used due to IV
>    randomness limitations

That is not true. CBC mode requires IVs to be random and
unpredictable, but they do not really be true random, it is enough to
use pseudo random number generators for that. One way to get that is
to use fixed secret key (only known to the device, and no, do not use
key derived from the serial number or mac of the device or similar)
and encrypt the incrementing time with such key.

That should provide proper random IVs than can be used in CBC mode,
and which are unpredictable to everybody who does not know the key
used to generate them.

> - change "cryptographic suites" and "crypto-suites" to "cryptographic
>    algorithms" to avoid TLS confusion

IKEv2 RFC7296 uses cryptograhic suites. RFC4303 or RFC4301 does not
use term suite at all. I would prefer keeping that same term than what
IKEv2 uses.

> - Remove reference to I-D.nikander-esp-beet-mode, with the text "not
>    standarized yet". This draft has been abandoned in 13 years ago.

There has been some discussion every now and then to revive that
draft. There is some good properties in that especially for IoT
environments, as it does not send the extra inner IP header, when that
IP header can be constructed from the SAD.

Anyways that draft is clearly something that is not in scope for lwig,
but falls in the IPsecME scope, so removing that text now is probably
correct. 
-- 
[e-mail]