Skip to main content

Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms
RFC 7696

Yes

(Stephen Farrell)

No Objection

Alvaro Retana
(Brian Haberman)
(Deborah Brungard)

Note: This ballot was opened for revision 07 and is now closed.

Alvaro Retana No Objection

(Alissa Cooper; former steering group member) Yes

Yes (2015-09-02 for -07)
Nice document.

= Section 2:

OLD
For this reason, the
   protocol MUST specify one or more strong mandatory-to-implement
   algorithm or suite.

NEW
For this reason, IETF protocols MUST specify one or more strong mandatory-to-implement
   algorithm or suite.
   
(I think this is what you meant here, but if not then I don't know which protocol you mean by "the protocol.")

s/the base protocol specification includes a reference/the base protocol specification should include a reference/

= Section 2.2.3:

"Fortunately, catastrophic algorithm failures without warning are
   rare."

I would guess that if you really mean "catastrophic" then it's not that they are rare but that they never happen. I think this sentence works without the word "catastrophic."

= Section 2.4:

The 2119 language here seems out of place:

"Transition mechanisms SHOULD consider the algorithm that is used to
   provide integrity protection for algorithm negotiation itself."

= Section 2.8:

The 2119 language here seems out of place:

"Protocol designers MUST be prepared for the supported cryptographic
   algorithm set to change over time."

(Barry Leiba; former steering group member) Yes

Yes (2015-08-31 for -07)
This is exceptionally well written and clear; thanks.

(Ben Campbell; former steering group member) Yes

Yes (2015-09-02 for -07)
All of my comments have either been made by someone else, or otherwise covered in email discussion. So, yes!

(Kathleen Moriarty; former steering group member) (was Discuss) Yes

Yes (2015-09-08)
Thank you for addressing my prior discuss and comments.  Nice work on this draft!

(Spencer Dawkins; former steering group member) Yes

Yes (2015-09-02 for -07)
This is one heck of a document. Thank you for producing it. I know there are still conversations that haven't converged, but I'm a "yes" on what's there now (in pre-08).

I also read -07, but my comments are all nits, and are actually against pre-08 ... just so the RFC Editor doesn't have to find them again.

I'm seeing this text "advances cryptoanalytic techniques" that's probably missing a word.

This text "has lead to interoperability problems" should be "has led to".

This text "algorithms SHOULD to have a public stable specification" probably has an extraneous "to".

(Stephen Farrell; former steering group member) Yes

Yes (for -07)

                            

(Brian Haberman; former steering group member) No Objection

No Objection (for -07)

                            

(Deborah Brungard; former steering group member) No Objection

No Objection (for -07)

                            

(Jari Arkko; former steering group member) No Objection

No Objection (2015-09-02 for -07)
Discussion between Russ and Suresh (the Gen-ART reviewer) should complete before the draft is approved. There was potentially one more clarification needed in the thread, while other things have been resolved.

(Joel Jaeggli; former steering group member) No Objection

No Objection (2015-08-31 for -07)
> Advances in computing power available to the attacker will eventually make any algorithm obsolete. 

While I don't necessarily disagree (and counterfactuals are hard) I worry moreso about advances in technique that render additional computational power unnecessary, deliberate subversion buried in algorithms,  sidechannels that make attacking it vastly simpler then I do exponentially increasing computational assets. the later is relatively transparent whereas the former prospects are all things we are living with.