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

[Kathleen Moriarty <[e-mail]>]

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 <[e-mail]> wrote:

> Hi, Kathleen.
>
> Please see below
>
> On Jun 6, 2015, at 1:19 AM, Kathleen Moriarty <
> [e-mail]> 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.
>
>
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.

>
>
>   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.
>
>
> 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
> 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).
>
>
That's better.  It should appear somewhere to explain what it is before the
IANA section, thanks!

>
>
> 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.
>

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

>
> 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.
>

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

>
> Yoav
>
>


-- 

Best regards,
Kathleen