Subject: [Cfrg] Fwd: Rev RFC 7539?

From: Yoav Nir <[email-masked]>
Date: Thu, 12 Jan 2017 08:24:44 +0200

Reminder.

Is there interest in pushing this forward?

Yoav

> Begin forwarded message:
> 
> From: Yoav Nir <[email-masked]>
> Subject: Re: [Cfrg] Rev RFC 7539?
> Date: 16 November 2016 at 9:09:11 GMT+2
> To: Sean Turner <[email-masked]>
> Cc: IRTF CFRG <[email-masked]>
> 
> Cycles found.
> 
> Attached please find two files:
>   1. rfc7539_long.txt is RFC 7539 with page breaks and page numbers removed. 
>  2. draft-nir-cfrg-rfc7539bis-00.raw.txt is the unpaginated form of the new draft.
> 
> Couldn’t do much about the boilerplate, but this makes it easy to compare.
> 
> Yoav
> 
> 
> 
>> On 16 Nov 2016, at 10:06, Sean Turner <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> +1 - if you got the cycles.
>> 
>> spt
>> 
>>> On Nov 14, 2016, at 15:55, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> This seems like a good plan.
>>> 
>>> -Ekr
>>> 
>>> 
>>> On Mon, Nov 14, 2016 at 3:32 PM, Yoav Nir <[email-masked] <mailto:[email-masked]>> wrote:
>>> Hi
>>> 
>>> RFC 7539 (“ChaCha20 and Poly1305 for IETF Protocols”)[1] is now implemented in many places and referenced by 3 RFCs and 8 Internet Drafts ([2])
>>> 
>>> However, the quality of the document is not where we’d like it to be. There have been 7 errata filed against it. Most of it is editorial or insignificant, but still no errata is better than some errata.
>>> 
>>> So what do the participants and chairs think about spinning up a quick[4] rfc7539bis that has the same text, except that the errata will be merged in?
>>> 
>>> I think such a document should be fairly easy and quick.
>>> 
>>> Yoav
>>> 
>>> P.S: and yes, of course I’m volunteering to write it.
>>> 
>>> [1] https://tools.ietf.org/html/rfc7539 <https://tools.ietf.org/html/rfc7539>
>>> [2] https://datatracker.ietf.org/doc/rfc7539/referencedby/ <https://datatracker.ietf.org/doc/rfc7539/referencedby/>
>>> [3] https://www.rfc-editor.org/errata_search.php?rfc=7539 <https://www.rfc-editor.org/errata_search.php?rfc=7539>
>>> [4] My spell check actually corrected “quick” to “quic”. The contents of my mails are veering far away from regular English.
>>> 
>>> 
>>> _______________________________________________
>>> Cfrg mailing list
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.irtf.org/mailman/listinfo/cfrg
>>> 
>>> 
>>> _______________________________________________
>>> Cfrg mailing list
>>> [email-masked]
>>> https://www.irtf.org/mailman/listinfo/cfrg
>> 
>

---

From: "Paterson, Kenny" <[email-masked]>
Date: Tue, 17 Jan 2017 11:21:47 +0000

Dear Yoav,

Thanks for your work on this. Alexey and I have are asking the CFRG review
panel to take a look at the revised document.

And if anyone else from the CFRG wants to take a look at the document and
provide comments, that would be great.

Cheers,

Kenny

On 12/01/2017 06:24, "Cfrg on behalf of Yoav Nir" <[email-masked]
on behalf of [email-masked]> wrote:

> 2. draft-nir-cfrg-rfc7539bis-00.raw.txt
> is the unpaginated form of the new draft.
>
>

---

From: John Mattsson <[email-masked]>
Date: Wed, 18 Jan 2017 15:39:10 +0000

Hi,

Looks good.

Some comments:

- "RFC 7539, The predecessor of this document, did not introduce any new
   crypto, but was meant to serve as a stable reference and an
   implementation guide.  It was a product of the Crypto Forum Research
   Group (CFRG).  This document merges the errata filed against RFC 7539
   and adds a little text to the Security Considerations section.”

   I think "did not introduce new crypto" is wrong (nonce length,
    counter length, key derivation, AEAD etc.), I think the paragraph
    can be shortened to something like:

   "This document merges the errata filed against RFC 7539
    and adds a little text to the Security Considerations section."

- ChaCha20-Poly1305 has several good properties that the draft does not
mention. I think the draft should mention that ChaCha20-Poly1305 is Online
and Parallelizable.

- I think the discussions on TLS, IPsec and PRF distracts and would be
better in a separate section or appendix.

More editorial comments:

- OLD: "RFC 7539, The"
  NEW: "RFC 7539, the"

- The following sentences I think should have references:

- OLD "They have been defined in scientific papers by D. J. Bernstein,
       which are referenced by this document"
  NEW "They have been defined in scientific papers by D. J.
       Bernstein [X][Y]"

- OLD "This follows the use of these terms in Professor Bernstein's
       paper."
  NEW "This follows the use of these terms in Professor Bernstein's
       paper [X]."

- "QUARTERROUND ( 3, 4, 9,14)"
  Spacing around functions are inconsistent (several places).

-       chacha20_block(key, counter, nonce):
         state = constants | key | counter | nonce
         working_state = state
         for i=1 upto 10
            inner_block(working_state)
            end
         state += working_state
         return serialize(state)
         end

  I suggest changing to:

        chacha20_block(key, counter, nonce):
         state = constants | key | counter | nonce
         inital_state = state
         for i=1 upto 10
            inner_block(state)
            end
         state += initial_state
         return serialize(state)
         end

  This align with text and make the state parameter to actually be state

- "ChaCha20 block operation" vs "ChaCha20 block operation was applied"
  The two bullets have different text.

- "the key"
  Which key?

- OLD "to generate the one-time Poly1305 pseudorandomly"
  NEW "to generate the one-time Poly1305 key pseudorandomly"

- "64-bit cipher" "128-bit cipher" "256-bit cipher"
Could mention that this is block size (not key size)

Cheers,

John

---

From: Russ Housley <[email-masked]>
Date: Wed, 18 Jan 2017 13:30:04 -0500

Document: draft-nir-cfrg-rfc7539bis-00
Reviewer: Russ Housley
Review Date: 2017-01-19

Summary: Almost Ready

Major Concerns:

The Abstract says that there are additions to the Security
Considerations; however, I do not see a difference between the
Security Considerations in this document and RFC 7539.

Minor Concerns:

In Section 2.3.1, please add a sentence to define the "|" operator
in a manner similar to the definition for "+" in Section 2.1.

Nits:

Abstract: s/any new crypto/any new cryptographic mechanisms/

Section 2.1 uses "rotation" and "roll" to describe the same operation.
Please pick one term.

In Sections 2.1 and 2.3, I do not think that the line numbers aid the
reader. I think that simple indention would be better.

In Sections 2.1 and 2.1.1, I do not think that the bullets aid the
reader.  I think that simple indention would be better.

Section 2.5.1 includes: r = (le_bytes_to_num(key[0..15]).
I think you want to drop the leading parenthesis.

In Author's address, please capitalize "st."

---

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Thu, 19 Jan 2017 13:50:17 +0300

Document: draft-nir-cfrg-rfc7539bis-00
Reviewer: Stanislav Smyshlyaev
Review Date: 2017-01-19

The purpose of the document is to address a set of of errata for RFC 7539.
It has been done systematically and correctly - all errata have been
addressed.

RFC 7539 is an extremely important document providing some
(optional/"standby") diversity, so, I totally support the work and the
adoption of the new rfc7539bis as a CFRG document.

My only concerns related to the changes are the following (these two have
already been spotted by Russ Housley and John Mattsson):
- there are no changes in the Security Considerations section, while the
abstract says they should be.
- Capital "T" in the beginning of the second sentence of the abstract.

Also in the updated version I'd prefer to see an updated list of the papers
on ChaCha:
the ideology of the RFC is to give the alternative (e.g. as a standby
cipher) to AES in the protocols, so an up-to-date relevant list of
publications on the alternative algorithms would be helpful. Maybe the
authors have
thought on this and have come to a conclusion that no update is needed
though.

Some editorial comments, related to the original RFC:
1) "Professor Bernstein's paper" -> "[ChaCha]".
2) Section 2.5: do we really need a c-code (together with #include...)
instead of pseudocode here?
3) To add to the Russ Housley's list of unnecessary bullets and line
numbers: are "@@@" needed in A.5?
4) For "+", "^" and "<<<" definitions are given and for "|" (again -
already spotted by Russ) and for "&" they are not - some revision here
would be helpful.

And one more minor comment: the statements in 2.7 about the PRFs may be
more accurate, if instead of (or in addition to) informal words (about HMAC
that are used as PRF and that Poly1305 should not) references to the formal
PRF property and papers with proofs of HMAC would be given.

Nevertheless, in my opinion, the document is very close to being ready and
should be adopted by CFRG (after these minor corrections).

Best regards,
Stanislav V. Smyshlyaev, Ph.D.,
Head of Information Security Department,
CryptoPro LLC