Re: [IPsec] Please review draft-ietf-ipsecme-chacha20-poly1305

["Valery Smyslov" <[e-mail]>]

Hi,

this is my review of draft-ietf-ipsecme-chacha20-poly1305-02.

I think that the draft is in a good shape. A few issues need to be resolved.



Technical issues.

1. For the question raised in the draft:

    TBD: do we want an extra 32 bits as salt for the nonce like
    in GCM, or keep the salt (=SenderID) at zero?

I prefer to follow GCM-like approach, i.e. to take these 32 bits
from the KEYMAT. It is cryptographically sound and is good
from evaluation point of view - you know where these bits come from.

I understand that it would require some adaptation
for multi-sender case, like in RFC6054, but AFAIK currently
Many-to-Many IPsec SAs are rare and look exotic.
And as RFC6054 states, the nonce is not transferred in packet,
so it is not the best place for SenderID (unlike explicit IV).


2. Section 4.

   When negotiating the ChaCha20-Poly1305 algorithm for use in IKE or
   IPsec, the value xxx (TBA by IANA) should be used in the transform
   substructure of the SA payload as the ENCR (type 1) transform ID.  As
   with other AEAD algorithms, INTEG (type 3) transform substructures
   SHOULD NOT be specified unless at least one of the ENCR transforms is
   non-AEAD.

The last sentence is wrong. Section 3.3 of RFC7296 states:

   Combined-mode ciphers include
   both integrity and encryption in a single encryption algorithm, and
   MUST either offer no integrity algorithm or a single integrity
   algorithm of "NONE", with no integrity algorithm being the
   RECOMMENDED method.

So INTEG either MUST NOT be present in the proposal substructure
containing ChaCha20-Poly1305 or MUST be NONE. And RFC7296
requires not to mix AEAD and non-AEAD algorithms in the same proposal:

   If an initiator wants to propose both combined-
   mode ciphers and normal ciphers, it must include two proposals: one
   will have all the combined-mode ciphers, and the other will have all
   the normal ciphers with the integrity algorithms.




Editorial issues.

1. Section 2, first bullet.

   o  The Initialization Vector (IV) is 64-bit, and is used as part of
      the nonce.  The IV MUST be unique for each SA but does not need to
      be unpredictable.  The use of a counter or an LFSR is RECOMMENDED.

The IV MUST be unique for each invocation (ESP packet or IKEv2 message),
not for each SA.


2. Section 2, last but one bullet:

      *  The length of the additional data in octets (as a 64-bit
         little-endian integer).

"additional data" is a bit vague, please use "Authenticated Additional Data"
(or "AAD") for clarity.


3. Informative References

   [FIPS-46]  National Institute of Standards and Technology, "Data
              Encryption Standard", FIPS PUB 46-2, December 1993,
              <http://www.itl.nist.gov/fipspubs/fip46-2.htm>.

The url is incorrect, it leads to the NIST home page.
I believe the correct url is
http://csrc.nist.gov/publications/fips/archive/fips46-3/fips46-3.pdf
(and it is FIPS 46-3, that superceeded FIPS 46-2).




Minor nits (subjective).

1. Section 1.

I think the main problem with 3DES is not that it is significantly slower
than AES, but that it has blocksize of 64 bits, that is considered
loo small for high-speed networks, when the possibility of birthday attack
leads to necessity to frequently rekey.


2. Section 2.

>From the description of how ESP packet is constructed it is not
absolutely clear what parts of the nonce are explicitely included in
the packet, and what aren't. I guess it is 64 bit IV that is included
and the higher 32 bits (SenderID) - that aren't, but it is not explicitely
stated. I'd prefer to it to be spelled out.


3. Section 3.

The last sentence is too long and refers to different sections in different
documents (this draft and RFC5282). That makes it a bit difficult to follow.
Could you, please, split it into several shorter sentences.


4. Section 5.

The terms "64-bit cipher", "128-bit cipher" and "256-bit cipher"
look like a jargon (and could be mixed up with key length by naive reader).
I'd prefer to use "block cipher with 64-bit block" etc.


5. Section 6.

I think it is worth to instruct IANA that tis document must be referenced
in both ESP and IKEv2 columns of IANA registry.
However it is not strictly necessary since IANA will ask this question 
anyway.


Regards,
Valery Smyslov.