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

[Ballot comment]
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".

[Ballot comment]
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.

[Ballot comment]
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."

[Ballot comment]
> 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.

[Ballot discuss]
Thank you for your work on this draft, Russ!  I think it's a very good and helpful draft or the community.

I'll switch to a Yes once we have a clearer answer as to where we are on consensus for the paragraph in Section 2.9.  I know there is similar text in the OS RFC and the discussion was had with mail operators around another RFC, but I don't think there was an adequate discussion on this topic with the fuller audience.  The discussion never happened with the OS RFC and Viktor had some assumptions that are clear on mailing lists in recent threads, but not necessarily in that document or discussions for that document. 

The mail/applications discussion was specific to a use case of software that had no plans for upgrades, which results in legacy systems using older selections for transport encryption (fine, we can deal with that and just say it's legacy).  This discussion didn't involve the SAAG or per pass list and was spurred on by the RC4 deprecation (RFC7435).  I think whatever statements we make on this going forward should be derived from some level of consensus or we risk demonstrating consensus in a series of published documents that I don't think we really have.

I'm happy to be in the rough on this, but do want to wait on the outcome of the discussion and see if text for this section requires updating.

Here is the question I sent to the list and I also prodded on the perpass list to chime in on this thread.
https://mailarchive.ietf.org/arch/msg/saag/PXrRghfHM-OBj2Y2TniuKptpKCs

I'm happy to wait to see what happens with this thread and what statements are deemed appropriate.

[Ballot comment]
I have some comments I'd like to have considered as well.

1. Section 2.6

I'm finding it helpful to make product teams aware of support in browsers for newer algorithms and protocols as well as making them aware that browsers will show deprecated selections as broken in some way.  This is motivational for products to transition on the server side for web traffic.  I suggest adding some text in 2.6 after the following paragraph as I have found this to be the case (and needed) for product teams.

  Without clear mechanisms for algorithm and suite rollover, preserving
  interoperability becomes a difficult social problem.  For example,
  consider web browsers.  Dropping support for an algorithm suite can
  break connectivity to some web sites, and the browser vendor will
  lose users by doing so.  This situation creates incentives to support
  algorithm suites that would otherwise be deprecated in order to
  preserve interoperability.

Something similar to the following could be helpful:

  Resistance to deprecate algorithm suites on the server side by product
  teams or web server administrators is often driven by a concern for their
  customers ability to reach their site.  Product teams and server
  administrators are typically motivated either by customer requirements
  for improved security specific to algorithm and suite rollover as well as
  understanding the level of support for these options in deployed browsers.
  Additional motivation has come from the knowledge that certain browser
  vendors have visual warnings present in their user interface, shown to
  customers, when a deprecated algorithm or cipher suite is in use.

2. The SecDir review had some comments and nits that I don't think have been addressed yet.  SOme of the nits were addressed in other ways, which is fine.  I'm okay with the 'ought' language in 3.1, but a response or update resulting to the suggestion for 3.2 and 3.3 would be helpful.
https://mailarchive.ietf.org/arch/msg/secdir/bykvhh43HOiznC5nv7V-paas_lo

    2. Sections 3.2 and 3.3 should in some way relate back to the
    recommendation to specify algorithm choices separately from base
    protocol specifications (esp. since 3.2 suggests that this practice
    can drive added complexity in the form of algorithm/suite overload)

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?

  BCP is requested.  This is the proper RFC type because it provides guidance to protocol designers
  regarding cryptographic algorithm agility.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  Many IETF protocols use cryptographic algorithms to provide
  confidentiality, integrity, authentication or digital signature.
  Communicating peers must support a common set of cryptographic
  algorithms for these mechanisms to work properly.  This memo
  provides guidelines to ensure that protocols can easily migrate
  from one algorithm suite to another one over time.

Working Group Summary

  This document was not produced by any IETF WG.  It was started
  by the IAB, and it has been extensively discussed on the SAAG mail
  list.

Document Quality

  This document has been extensively discussed on the SAAG mail list
  as well as in the IAB program on privacy and security. It represents the
  rough consensus from those discussions.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

  This document was started by the IAB and was reviewed within the IAB's
  privacy and security program.  Versions 4-6 were then discussed  extensively on
  the SAAG mail list.  A secdir review was conducted by Leif Johansson.
    As shepherd, I reviewed the changes from 4 to 5, 5 to 6, and 6-7; in each case,
  I believe the changes both responded to community concerns and made the document
  better.  While this is not a working group document,  I believe it has gotten sufficient
  review from within one IETF community to make it ready for a wider last call. 

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns on the review from the security community.  There was
  a request for review to the applications/ART area directorate from
  Eliot Lear.  That has not yet completed, but it is common for these to
  occur in parallel with the IETF Last Call.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that took
place.

  As noted above, this document will require review from the applications/ART
  area directorate; this has been requested but is not complete.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the interested community has
discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

  No concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  No IPR disclosures are needed.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any discussion and conclusion regarding the IPR
disclosures.

  No IPR disclosures are needed for the normative references.

(9) How solid is the consensus of the interested community behind this
document? Does it represent the strong concurrence of a few individuals,
with others being silent, or does the interested community as a whole
understand and agree with it?

  This document is the result of  extensive discussion, and the advice
    it gives seems to have garnered rough consensus in the venues where
  it has been reviewed.  This consensus is not unanimous, but the general
  support appears broad.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No one has threatened an appeal.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  The document is more than 15 pages and lacks a Table of Contents.
  One can be added if desired.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  This document does not specify a MIB, media type,  or URI, and there
  has been no other identified requirement for a formal review.

(13) Have all references within this document been identified as
either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  There are just two normative references, and they are both BCPs.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  There are no downward normative references.

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs
is discussed. If this information is not in the document, explain why
the interested community considers it unnecessary.

  This document does not seek to change the status of any RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  No IANA actions are needed, and the IANA Considerations section
  says that.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

  No IANA registries are created at all.

(19) Describe reviews and automated checks performed by to validate
sections of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, etc.

  No formal language is used.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-iab-crypto-alg-agility-06, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

If this assessment isn't accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms) to Best Current Practice


The IESG has received a request from an individual submitter to consider
the following document:
- 'Guidelines for Cryptographic Algorithm Agility and Selecting
  Mandatory-to-Implement Algorithms'
  as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-08-17. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Many IETF protocols use cryptographic algorithms to provide
  confidentiality, integrity, authentication or digital signature.
  Communicating peers must support a common set of cryptographic
  algorithms for these mechanisms to work properly.  This memo provides
  guidelines to ensure that protocols have the ability to migrate from
  one mandatory-to-implement algorithm suite to another over time.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-iab-crypto-alg-agility/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-iab-crypto-alg-agility/ballot/


No IPR declarations have been submitted directly on this I-D.

There have been some recent comments on the saag list that
will be treated as last call comments. (See the thread at [1])

[1] https://www.ietf.org/mail-archive/web/saag/current/msg06373.html

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?

  As indicated on the title page, BCP is requested.  This is the
  proper RFC type because it provides guidance to protocol designers
  regarding cryptographic algorithm agility.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  Many IETF protocols use cryptographic algorithms to provide
  confidentiality, integrity, authentication or digital signature.
  Communicating peers must support a common set of cryptographic
  algorithms for these mechanisms to work properly.  This memo
  provides guidelines to ensure that protocols can easily migrate
  from one algorithm suite to another one over time.

Working Group Summary

  This document was not produced by any IETF WG.  It was started
  by the IAB, and it has been extensively discussed on the SAAG mail
  list.

Document Quality

  This document has been extensively discussed on the SAAG mail list.
  It represents the rough consensus from that discussion.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

  This document was started by the IAB, and it has been extensively
  discussed on the SAAG mail list.  It represents the rough consensus
  from that discussion.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that took
place.

  This document has already has extensive security review.  This
  document has been extensively discussed on the SAAG mail list.
  It represents the rough consensus from that discussion.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the interested community has
discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

  No concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  No IPR disclosures are needed.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any discussion and conclusion regarding the IPR
disclosures.

  No IPR disclosures are needed for the normative references.

(9) How solid is the consensus of the interested community behind this
document? Does it represent the strong concurrence of a few individuals,
with others being silent, or does the interested community as a whole
understand and agree with it?

  This document was started by the IAB, and it has been extensively
  discussed on the SAAG mail list.  It represents the rough consensus
  from that discussion, but it does not represent unanimous consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No one has threatened an appeal.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  The document is more than 15 pages and lacks a Table of Contents.
  One can be added if desired.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  No formal review is needed for this document.

(13) Have all references within this document been identified as
either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  There are just two normative references, and they are both BCPs.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  There are no downward normative references.

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs
is discussed. If this information is not in the document, explain why
the interested community considers it unnecessary.

  This document does not seek to change the status of any RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  No IANA actions are needed, and the IANA Considerations section
  says that.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

  No IANA registries are created at all.

(19) Describe reviews and automated checks performed by to validate
sections of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, etc.

  No formal language is used.