Subject: [IPsec] AD review of draft-ietf-ipsecme-chacha20-poly1305-08

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 5 Jun 2015 18:19:41 -0400

Hi,

Sorry this took me a bit of time to get to, I wanted to read through some
of the background materials first and have been a bit swamped lately
(should clear up soon).  Anyway, I have a few comments from my review and
also some from a developer.  Please don't feel the need to respond over the
weekend as I am sending this late on a Friday.

First, thank you very much for your work on this draft.  Having a standby
cipher n hand is a good thing for algorithm agility.  Hopefully we don't
need it for some time.

Section 2 talks about AEAD_CHACHA20_POLY1305 and makes the statement that
the initialization vector (part of the nonce) does not have to be
unpredictable.  That might be okay for chacha20 as long as you have
uniqueness, but I thought POLY1305 required an unpredictable nonce (section
2.5 of rfc7539).  It is not entirely clear to me where that value comes
from in this description.  Please let me know if I am missing something in
section 2.

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

The IANA considerations list ENCR_CHACHA20_POLY1305 as the name of the
algorithm without explanation in the draft.  It appears that this was a WG
decision:
https://www.ietf.org/mail-archive/web/ipsec/current/msg09772.html
An explanation might be helpful.  Elsewhere in the draft, you just have
AEAD_CHACHA20_POLY1305.

I had another implementer of AEAD_CHACHA20_POLY1305 (but not for IPsec)
read the draft and he commented that he didn't understand the term 'Standby
cipher'.  This was clear to me, but I read a lot of drafts.  It might be
helpful to expand on that a bit more since this came from a developer.

He also requested that it would be helpful if the packet could be laid out
to explain where the IV, ciphertext and tag go.  This seems like a
reasonable request and is from a developer.

Thank you & have a nice weekend!

-- 

Best regards,
Kathleen

---

From: Yoav Nir <[email-masked]>
Date: Sun, 7 Jun 2015 01:03:32 +0300

Hi, Kathleen.

Please see below

> On Jun 6, 2015, at 1:19 AM, Kathleen Moriarty <[email-masked]> wrote:
> 
> Hi,
> 
> Sorry this took me a bit of time to get to, I wanted to read through some of the background materials first and have been a bit swamped lately (should clear up soon).  Anyway, I have a few comments from my review and also some from a developer.  Please don't feel the need to respond over the weekend as I am sending this late on a Friday.
> 
> First, thank you very much for your work on this draft.  Having a standby cipher n hand is a good thing for algorithm agility.  Hopefully we don't need it for some time.
> 
> 
> Section 2 talks about AEAD_CHACHA20_POLY1305 and makes the statement that the initialization vector (part of the nonce) does not have to be unpredictable.  That might be okay for chacha20 as long as you have uniqueness, but I thought POLY1305 required an unpredictable nonce (section 2.5 of rfc7539).  It is not entirely clear to me where that value comes from in this description.  Please let me know if I am missing something in section 2. 

The Poly1305 function does require a unique key. The way that we generate this unique and unpredictable key is by running the ChaCha20 block function with the same key and nonce, but with the block counter set to zero and using the top 256 bits of the result as the one time key. If ChaCha20 is a valid encryption function that has output indistinguishable from random data, this makes the one-time Poly1305 key unpredictable, even though the nonce is not unpredictable.  The text for that is at the bottom of page 3:

   The same key and nonce, along with a block counter of zero are passed
   to the ChaCha20 block function, and the top 256 bits of the result
   are used as the Poly1305 key.

> The IANA considerations list ENCR_CHACHA20_POLY1305 as the name of the algorithm without explanation in the draft.  It appears that this was a WG decision:
> https://www.ietf.org/mail-archive/web/ipsec/current/msg09772.html <https://www.ietf.org/mail-archive/web/ipsec/current/msg09772.html>
> An explanation might be helpful.  Elsewhere in the draft, you just have AEAD_CHACHA20_POLY1305.

Well AEAD_CHACHA20_POLY1305 is the code point already assigned to RFC 7539 for the algorithm.
http://www.iana.org/assignments/aead-parameters/aead-parameters.xhtml#aead-parameters-2 <http://www.iana.org/assignments/aead-parameters/aead-parameters.xhtml#aead-parameters-2>
As a side note, I have no idea what that registry is for. It assigns numeric IDs to algorithms but those numeric IDs are never stored or transmitted in any protocol.

ENCR_CHACHA20_POLY1305 is the identifier we are requesting for use within IKE. Perhaps I should change the last paragraph of section 2 as follows:
OLD:
   The encryption algorithm transform ID for negotiating this algorithm
   in IKE is TBA by IANA.

NEW:
   The encryption algorithm transform ID for negotiating this algorithm
   in IKE is ENCR_CHACHA20_POLY1305 (number is TBA by IANA).

> 
> I had another implementer of AEAD_CHACHA20_POLY1305 (but not for IPsec) read the draft and he commented that he didn't understand the term 'Standby cipher'.  This was clear to me, but I read a lot of drafts.  It might be helpful to expand on that a bit more since this came from a developer.

This is strange to me, because the second paragraph of the introduction both discusses the need for a standby cipher and links to draft-mcgrew-standby- <https://tools.ietf.org/html/draft-mcgrew-standby-cipher>cipher.  I don’t know how to clarify this further.

> He also requested that it would be helpful if the packet could be laid out to explain where the IV, ciphertext and tag go.  This seems like a reasonable request and is from a developer.

I guess this can be done. I wanted to keep the draft short by minimizing copying and pasting diagrams from 4303 and 7296, but it’s no great effort.

Yoav

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 12 Jun 2015 15:08:19 -0400

Hi Yoav,

Once again, sorry for the delay!  My schedule should start to get better in
a couple of weeks.

On Sat, Jun 6, 2015 at 6:03 PM, Yoav Nir <[email-masked]> wrote:

> The Poly1305 function does require a unique key. The way that we generate
> this unique and unpredictable key is by running the ChaCha20 block function
> with the same key and nonce, but with the block counter set to zero and
> using the top 256 bits of the result as the one time key. If ChaCha20 is a
> valid encryption function that has output indistinguishable from random
> data, this makes the one-time Poly1305 key unpredictable, even though the
> nonce is not unpredictable.  The text for that is at the bottom of page 3:
>
Right, but the RFC7539 for POLY1305, the nonce must be unpredictable.  If
you are feeding in the same nonce used for chacha, then it should also be
unpredictable.

> http://www.iana.org/assignments/aead-parameters/aead-parameters.xhtml#aead-parameters-2
> As a side note, I have no idea what that registry is for. It assigns
> numeric IDs to algorithms but those numeric IDs are never stored or
> transmitted in any protocol.
>
> ENCR_CHACHA20_POLY1305 is the identifier we are requesting for use within
> IKE. Perhaps I should change the last paragraph of section 2 as follows:
> OLD:
>
That's better.  It should appear somewhere to explain what it is before the
IANA section, thanks!

> This is strange to me, because the second paragraph of the introduction
> both discusses the need for a standby cipher and links to
> draft-mcgrew-standby-
> <https://tools.ietf.org/html/draft-mcgrew-standby-cipher>cipher.  I don’t
> know how to clarify this further.
>

OK, I was fine with the text.  We can leave it and see if it comes up by
any other reviewer.

> I guess this can be done. I wanted to keep the draft short by minimizing
> copying and pasting diagrams from 4303 and 7296, but it’s no great effort.
>

Thank you!  It just makes the draft have more pages and could be helpful to
developers.

-- 

Best regards,
Kathleen

---

From: Yoav Nir <[email-masked]>
Date: Fri, 12 Jun 2015 22:33:38 +0300

> On Jun 12, 2015, at 10:08 PM, Kathleen Moriarty <[email-masked]> wrote:
> 
> Hi Yoav,
> 
> Once again, sorry for the delay!  My schedule should start to get better in a couple of weeks.
> 
> On Sat, Jun 6, 2015 at 6:03 PM, Yoav Nir <[email-masked] <mailto:[email-masked]>> wrote:
> Hi, Kathleen.
> 
> Please see below
> 
>> On Jun 6, 2015, at 1:19 AM, Kathleen Moriarty <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi,
>> 
> Right, but the RFC7539 for POLY1305, the nonce must be unpredictable.  If you are feeding in the same nonce used for chacha, then it should also be unpredictable. 

Ah, I see the source of the confusion. Poly1305 does not get a nonce at all. It gets a one-time key. You could generate this one-time (unpredictable) key in many ways, but the way we do it here is by encrypting the (predictable) nonce using ChaCha20. This is similar to the practice of generating a random 128-bit value, and using that as an AES key, and encrypting a counter to generate unpredictable values (such as initialization vectors).

So it’s fine for the nonce to be predictable as long as the encrypted nonce is not.

I’ll make the rest of the changes soon.

Yoav

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 12 Jun 2015 19:02:09 -0400

Hi Yoav,

On Fri, Jun 12, 2015 at 3:33 PM, Yoav Nir <[email-masked]> wrote:

> Ah, I see the source of the confusion. Poly1305 does not get a nonce at
> all. It gets a one-time key. You could generate this one-time
> (unpredictable) key in many ways, but the way we do it here is by
> encrypting the (predictable) nonce using ChaCha20. This is similar to the
> practice of generating a random 128-bit value, and using that as an AES
> key, and encrypting a counter to generate unpredictable values (such as
> initialization vectors).
>
OK, so the difference here is that the method you are using is in section
2.6 and I was looking at the requirements for POLY1305 from section 2.5,
which uses a different method.

So it’s fine for the nonce to be predictable as long as the encrypted nonce
> is not.

Thank you!  I'll look for the update to kick-start last call.
Kathleen

-- 

Best regards,
Kathleen