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

[Kathleen Moriarty]

Hi Yoav,

On Fri, Jun 12, 2015 at 3:33 PM, Yoav Nir  wrote:

>
> On Jun 12, 2015, at 10:08 PM, Kathleen Moriarty <
> kathleen.moriarty.i...@gmail.com> 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  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.
>
>
> 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.
>
> I’ll make the rest of the changes soon.
>

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

>
> Yoav
>
>


-- 

Best regards,
Kathleen
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] IPsecME: agenda items for Prague

[Yaron Sheffer]

  
  
Hi,

Paul and I are working on our agenda for the upcoming meeting. We
have a 1 hr slot planned. If you'd like to claim part of it, do let
us know.

Thanks,
    Yaron
  


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

> On Jun 12, 2015, at 10:08 PM, Kathleen Moriarty 
>  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  > wrote:
> Hi, Kathleen.
> 
> Please see below
> 
>> On Jun 6, 2015, at 1:19 AM, Kathleen Moriarty 
>> mailto: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. 

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

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Kathleen Moriarty]

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