Skip to main content

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

Yes

(Stephen Farrell)

No Objection

(Alvaro Retana)
(Brian Haberman)
(Deborah Brungard)

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

Alissa Cooper Former IESG member
Yes
Yes (2015-09-02 for -07) Unknown
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 IESG member
Yes
Yes (2015-08-31 for -07) Unknown
This is exceptionally well written and clear; thanks.
Ben Campbell Former IESG member
Yes
Yes (2015-09-02 for -07) Unknown
All of my comments have either been made by someone else, or otherwise covered in email discussion. So, yes!
Kathleen Moriarty Former IESG member
(was Discuss) Yes
Yes (2015-09-08) Unknown
Thank you for addressing my prior discuss and comments.  Nice work on this draft!
Spencer Dawkins Former IESG member
Yes
Yes (2015-09-02 for -07) Unknown
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 IESG member
Yes
Yes (for -07) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Brian Haberman Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Deborah Brungard Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (2015-09-02 for -07) Unknown
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 IESG member
No Objection
No Objection (2015-08-31 for -07) Unknown
> 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.