Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms
draft-iab-crypto-alg-agility-08

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

(Ben Campbell) Yes

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

Alissa Cooper Yes

Comment (2015-09-02 for -07)
No email
send info
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."

(Spencer Dawkins) Yes

Comment (2015-09-02 for -07)
No email
send info
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) Yes

Barry Leiba Yes

Comment (2015-08-31 for -07)
No email
send info
This is exceptionally well written and clear; thanks.

(Kathleen Moriarty) (was Discuss) Yes

Comment (2015-09-08)
No email
send info
Thank you for addressing my prior discuss and comments.  Nice work on this draft!

(Jari Arkko) No Objection

Comment (2015-09-02 for -07)
No email
send info
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.

Deborah Brungard No Objection

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

Comment (2015-08-31 for -07)
No email
send info
> 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.

Alvaro Retana No Objection