Hi Steve, First of all many thanks for the comments. They will be usefull to design it right.
I have copied the 6lo ML since we presented Diet-ESP in 6lo this morning. There has been some discussion on the IV compression too and here is the link to the presentation Steve made at TLS in the IETF 89 in London [1 <http://www.ietf.org/proceedings/89/slides/slides-89-tls-2.pdf>] The design we had in mind is as follows: a) On the sender side: - Step 1: Each peer negotiate a key: in the next version we will specify that this key is derived by IKEv2 and leave to future work how IKEv2 generates this key. - Step 2: Use a PRF to generate IV_1, IV_2, ...., IV_n where IV_i is the IV the sender use to encrypt packet i - Step 3: Send your ESP compressed packet (let say here not sending all the bytes of the IV) b) On the receiver side: - Step 1 figuring out which packet is received -- in our case that is packet i - Step 2 find / generate the corresponding IV_i - Step 3 decrypt packet i The goal is to avoid sending IV in each packet that is what we call compression. If you IV is 8 bytes, the compression can be send the least significant last byte, (respectively two last bytes, ... 7 last bytes, the whole IV, or no IV at all). More precisely, we do not consider zipping a random number. The draft does not specify how matching between IV_i and packet i is performed. - 1) you may use the SN as the packet counter. Of course it is easier if the SN increments for each packet. However SN are not part of the IV generation. - 2) you may use the least significant bytes to determine which IV may match. This way of doing so differs in the current way of sending the IV as we do not have the IV from the packet. In our case, the IV is not derived from the packet, we need to generate a few number of IV in advance, and find out which is the one matching a particular packet. Motivation for doing so is that sending a byte in 6lo cost more than doing a few thousand operations. In that sense, we are ready to implement some more complex IV-to-i function. Best Regards, Daniel [1] http://www.ietf.org/proceedings/89/slides/slides-89-tls-2.pdf On Wed, Jul 23, 2014 at 8:16 PM, Stephen Kent <[email protected]> wrote: > Daniel, > > I read the very brief IV-generation I-D and I didn't see an explanation of > how > to perform IV "compression." As someone else already noted on the list, an > IV > is carried with each packet to enable decryption of packets that may > arrive out > of order. Thus it's not enough to have each peer use the same PRF and seed > to > generate IVs which are not explicitly transported, because of this > requirement. > Also, if the IV is required to be pesudorandom, there is likely no > opportunity > for compression in the usual sense. Finally, note that the specs for > algorithm > modes like GCM treat the IV as a security critical piece of info, for good > reason. > Thus if one tries to re-use a value such as an ESP sequence number as an > IV, all of > the ESP sequence number generation/management code becomes security > critical wrt > algorithm mode evaluation. This topic was discussed in London in the TLS > WG meeting, > when considering use of Cha-Cha. I can forward the relevant messages and > my slides > if you wish. > > Steve > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
