Hi, Kathleen. Please see below
> On Jun 6, 2015, at 1:19 AM, Kathleen Moriarty > <kathleen.moriarty.i...@gmail.com> 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. > 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 > <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
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
