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 <ynir.i...@gmail.com> wrote: > 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. > > 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
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
