Hi, I think the idea of introducing "implicit IV" also in IPsec is great and something that absolutely should be done. Some comments:
- The abstract/introduction/security consideration gives the idea that it defines implicit IV for ENCR_AES_CTR which is does not. I think AES-CTR could be removed from the document. - I think the the terminology of IV, nonce etc. in this document is very confusing. At least RFC 4106 defines IV to be the 8 octet ESP IV, while nonce is used for the 12 octet AEAD nonce, aligning with RFC 5116. I think this document should also follow this convention. e.g. I think the sentences should talk about IV instead of nonce. "but all of the algorithms mentioned above take an 8-octet nonce." "Currently this nonce is sent in each ESP packet" - "Nonce generation for these algorithms has not been explicitly defined. It has been left to the implementation" I do not understand how implementation specific nonce (or IV) generation could be interoperable between implementation? If I understand correctly, the only thing sent in the ESP packet is the sequence number. - If we go to the trouble of designing new encryption algorithms for ESP, I think this document does too little and misses opportunities to with very little work also make the algorithms stronger cryptographically as was done with TLS 1.2 -> TLS 1.3. I stongly suggest to change the nonce generation to follow current best practices established by e.g. TLS 1.3. Suggestion (here examplified for AES-128 in GCM mode) 1. The KEYMAT requested for each AES-GCM key is 28 octets. The first 16 octets are the 128-bit AES key, and the remaining 12 octets are used as the salt value in the nonce. 2. The nonce format is changed to a format following Section 4.4 of draft-mcgrew-iv-gen [XX] where IV = implicit IV 0 1 2 3 4 5 6 7 8 9 10 11 +--+--+--+--+--+--+--+--+--+--+--+--+ |00|00|00|00| IV |---+ +--+--+--+--+--+--+--+--+--+--+--+--+ | | +--+--+--+--+--+--+--+--+--+--+--+--+ | | salt |->(+) +--+--+--+--+--+--+--+--+--+--+--+--+ | | +--+--+--+--+--+--+--+--+--+--+--+--+ | | nonce |<--+ +--+--+--+--+--+--+--+--+--+--+--+--+ Figure: Nonce Format 3. The salt is kept secret In [YY] it is shown that this can be understood as a key-length extension that essentially extends the 128-bit key of AES-GCM to a 224-bit key giving significatntly better multi-user security (and single-user security) - A large secret salt is useful for IKEv2 as well, I think the algorithms should be defined for IKEv2 as but with IV = explicit IV. Cheers, John _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec