Re: [IPsec] Comments on draft-ietf-ipsecme-implicit-iv-05

[John Mattsson <[e-mail]>]

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