[IPsec] Two questions about draft-ietf-ipsecme-chacha20-poly1305-00

[Tero Kivinen <[e-mail]>]

Yoav Nir writes:
> First is the nonce/IV question: In the current draft, there is a
> 64-bit IV with guidance not to repeat them (so use a counter or
> LFSR). The function itself accepts a 96-bit input nonce, so the
> nonce is constructed from the 64-bit IV and 32 zero bits. The reason
> for doing this is so the algorithm could be used in a multi-sender
> case such as GDOI, where the 32-bit zero can be replaced by a sender
> ID. Alternatively, we could generate a 32-bit salt value from the
> key material, but I don’t see a reason why we’d want that.

Reserving that 32-bits as sender-ID is fine...

> Another thing we could do is what some people are advocating for
> TLS: Since a counter is a fine IV (no need for secrecy), we don’t
> need a 64-bit IV that has the exact same value as the replay
> counter. We might as well save 8 bytes per packet and just feed the
> replay counter to the function. The argument against this is that
> some crypto modules may have the API set up in such a way that the
> IVs are generated within the module and could be something other
> than a counter (like an LFSR). The proposal will break such APIs.

As Kent explained in the meeting, if you move the IV generation out
from the crypto operation, then that also moves the FIPS boundary,
i.e. if the uniqueness of the IV generation (counter) is inside the
IPsec module, not in the ChaCha20 module, then you need to FIPS
certify whole thing.

On the other hand with IPsec I think you mostly need to FIPS certify
quite a lot of stuff anyways...

On the other hand, I think it would be possible to do things other way
around, i.e. make cipher to internally generate IV, but define that IV
MUST be running counter starting from 0, and use that counter as
sequence number in the ESP and compress sequence number out from the
packet. I.e. we would still have IV (coming form inside the crypto
boundary), but we compress the sequence number away, as it would
always be the same as IV...

Currently we cannot do that, as we do not define how the IVs are
generated, thus the IPsec part cannot know for sure that IVs are
generated in such way.

On the other hand if we define this cipher in such way that IV MUST be
generated such way, then we could make sequence number compression
option in the future, which would compress sequence number away from
the actual packet... I.e. gain the same effect, but not compressing
the IV, but compressing the sequence number...

This would save 32-bits from the packet, as only 32-bits of the
sequence number is transmitted, not the full 64-bits, but that would
still be something, and if even more IV compression is needed, there
would be ways to only transmit smaller part of the IV and then
reconstruct it before decryption and verification.

These compression extensions could happen after ESP encryption and
before ESP decryption, so the actual ESP packets seen by the engine
would be exactly same, only difference would be that they would need
to maintain strict requirement that SEQ matches IV...

> Second issue is about UI advice. Some implementations (yes, mine is
> included) allow the user to configure encryption algorithm, MAC
> algorithm, and D-H group. There is no setting for PRF since such UIs
> date back to IKEv1. The PRF is usually just taken from the setting
> for MAC algorithm. This works fine as long as all supported MAC
> algorithms are HMAC, XCBC, and CMAC. AES-GCM would have the same
> issue, but RFC 5282 makes no mention of this issue. I’m wondering if
> we should recommend to pair this algorithm in IKE with
> PRF_HMAC_SHA2_256. 

There is no need in IKEv2 to tie the PRF to other algorithms, so I see
no reason to do so in this draft.

On the other hand the other draft making the UI suite for this will of
course need to select suitable PRF, but that draft might want to wait
for new EC curves, so we could have complete DJB suite...

Btw, in the draft introduction you have text which says:

   weakness in AES, VPN users will be in an unenviable position.  With
   the only other widely supported cipher being the much slower 3DES, it
   is not feasible to re-configure IPsec installations to use 3DES.
   [standby-cipher] describes this issue and the need for a standby
   cipher in greater detail.

I do not think the problem with 3DES is the speed, I think the bigger
problem is the way too short block length of it. As RFC7321 says:

   The Triple Data Encryption Standard (TDES) is obsolete because of its
   small block size; as with all 64-bit block ciphers, it SHOULD NOT be
   used to encrypt more than one gigabyte of data with a single key
   [M13].  Its key size is smaller than that of the Advanced Encryption
   Standard (AES), while at the same time its performance and efficiency
   are worse.  Thus, its use in new implementations is discouraged.

With gigabit links that would mean rekeying every ten seconds or so... 
-- 
[e-mail]