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. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
