Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms
RFC 7696
Yes
No Objection
Note: This ballot was opened for revision 07 and is now closed.
Alvaro Retana No Objection
(Alissa Cooper; former steering group member) Yes
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
This is exceptionally well written and clear; thanks.
(Ben Campbell; former steering group member) Yes
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
Thank you for addressing my prior discuss and comments. Nice work on this draft!
(Spencer Dawkins; former steering group member) Yes
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
(Brian Haberman; former steering group member) No Objection
(Deborah Brungard; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
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
> 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.