Subject: Re: [TLS] Alexey Melnikov's Yes on draft-ietf-tls-chacha20-poly1305-04: (with COMMENT)

From: Stephen Farrell <[email-masked]>
Date: Thu, 5 May 2016 15:14:19 +0100

On 24/04/16 17:23, Alexey Melnikov wrote:
> Alexey Melnikov has entered the following ballot position for
> draft-ietf-tls-chacha20-poly1305-04: Yes
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tls-chacha20-poly1305/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Nit: SHA-256 probably needs a normative reference.

I added an RFC editor note. If someone has the right reference
to add handy I can add that too. Or I'll get to it in a bit,

Cheers,
S.

> 
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Thu, 5 May 2016 14:33:59 +0000

Hi Stephen,

The one below can be used.

[FIPS 180-4]  Federal Information Processing Standards Publication
                (FIPS PUB) 180-4, Secure Hash Standard (SHS), August 2015.

Regards,
Quynh.
________________________________________
From: TLS <[email-masked]> on behalf of Stephen Farrell <[email-masked]>
Sent: Thursday, May 5, 2016 10:14:19 AM
To: Alexey Melnikov; The IESG
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [TLS] Alexey Melnikov's Yes on draft-ietf-tls-chacha20-poly1305-04: (with COMMENT)

Cheers,
S.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 5 May 2016 17:39:09 +0300

> On 5 May 2016, at 5:14 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> 

RFC 6234 works.

Or:
“Secure Hash Standard (SHS)”, FIPS PUB 180-4, August 2015, http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 5 May 2016 15:49:05 +0100

Thanks all. I updated the RFC editor note to add the FIPS
reference.

Cheers,
S.

On 05/05/16 15:45, Alexey Melnikov wrote:
> On Thu, May 5, 2016, at 03:33 PM, Dang, Quynh (Fed) wrote:
>>
>> Hi Stephen,
>>
> There is also RFC 4634, but I am not sure which reference is better.
> 
>> Regards,
>> Quynh.
>> Subject: Re: [TLS] Alexey Melnikov's Yes on
>> draft-ietf-tls-chacha20-poly1305-04: (with COMMENT)
>>

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 05 May 2016 15:45:09 +0100

---

From: Jeffrey Walton <[email-masked]>
Date: Thu, 5 May 2016 12:39:39 -0400

> Thanks all. I updated the RFC editor note to add the FIPS

You might also consider mentioning the interop problems that are going
to occur when diverging from Bernstein's reference implementation. Its
already creating open questions on other mailing lists. For example,
linux-crypto and
https://www.mail-archive.com/[email-masked]/msg1137554.html:

    > +     chacha20_block(&crng->state[0], out);
    > +     if (crng->state[12] == 0)
    > +             crng->state[13]++;

    state[12]++? Or why do you increment the nonce?

Jeff

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 06 May 2016 09:08:31 +0200

On Thu, 2016-05-05 at 12:39 -0400, Jeffrey Walton wrote:
>     > +     chacha20_block(&crng->state[0], out);
>     > +     if (crng->state[12] == 0)
>     > +             crng->state[13]++;
> 

I wondered the same when I saw the comment. However, I'm not sure that
is an issue. Chacha20 as a stream cipher is not defined anywhere by
IETF (as far as I know). RFC7539 defines Chacha20-poly1305 AEAD
(authenticated encryption) mechanism which uses a modified chacha20
than the reference algorithm. However, that doesn't really affect any
other uses for the stream cipher. That's maybe the reason for the
confusion.

Bottom line, the comment relates more to RFC7539 rather than this
draft.

regards,
Nikos