Subject: [secdir] secdir review draft-iab-crypto-alg-agility-06 (almost done)

From: Leif Johansson <[email-masked]>
Date: Mon, 03 Aug 2015 21:19:49 +0200

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written with the intent of improving
security requirements and considerations in IETF drafts.  Comments
not addressed in last call may be included in AD reviews during the
IESG review.  Document editors and WG chairs should treat these
comments just like any other last call comments.

This document is almost ready to go. I have a couple of issues:

1. Section 3.1 has a certain poetic quality to it but the use of
the word "ought" ought perhaps be replaced with normative language
unless this is a novel attempt to avoid RFC2119 terms :-)

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)

I also have some stylistic comments below, feel free to use or
ignore as you see fit:

-- minor nits --

1. Introduction, second paragraph, second sentence

current text:

As new cryptanalysis techniques are developed and computing capabilities
improve, the work factor to break a particular cryptographic
algorithm will reduce, becoming more feasible for more attackers.

suggested:

As new cryptanalysis techniques are developed and computing capabilities
improve, the work required to break a particular cryptographic
algorithm (aka the work factor) will reduce, making an attack on
the algorithm feasible for more attackers.

2.1 Algorithm Identifiers, first paragraph, first sentence

current text:

IETF protocols that make use of cryptographic algorithms MUST support
one or more algorithm or suite identifier.

suggested:

IETF protocols that make use of cryptographic algorithms MUST support
one or more identifier denoting an algorithm or suite of algorithms.

2.2 Mandatory-to-Implement Algorithm, second paragraph, second sentence

current text:

To achieve this goal, the base protocol specification includes a
reference to a companion algorithms document, allowing the update of
one document without necessarily requiring an update to the other.

suggested:

To achieve this goal, it is suggested that the base protocol
specification include a reference to a companion algorithms
document, allowing the update of one document without necessarily
requiring an update to the other.

2.6 Preserving Interoperability, first paragraph

s/is very hard/is very difficult/
s/an long support/on long support/

second paragraph

s/but preserving/but preserve/

2.7 Balance Security Strength, first paragraph

s/considered in making the selection/considered when making the selection/

s/that are deploying and configuring/who are deploying and configuring/

This section uses "deployment and configuration" (etc) a lot. It may be
equally clear to just write "deployment"

final paragraph: s/which is in turn/which in turn is/

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 4 Aug 2015 08:11:13 +0100

Hi Leif,

I was surprised to hear from you that you believe the document is almost done. I get a different impression when I read through it and I thought it might be useful to share my thoughts with Russ, you and the SecDir.

Early in the document the goal is stated as "These **guidelines are for use by IETF working groups and protocol Authors** for IETF protocols that make use of cryptographic algorithms."

My problem with this statement is that the document actually addresses three audiences (although never explicitly stated anywhere), namely
 * Protocol designers (in the IETF and elsewhere),
 * Implementers (of hardware and software), and
 * those who deploy products using these protocols

The guidance for protocol designers aims to make the standardization process more efficient by already addressing extensibility as part of the initial design rather than waiting till an algorithm fails. It turns out that this is largely done already today (since about 10 years) and actually not the real problem the Internet community is facing when it comes to the use of cryptographic algorithms. Many protocol designers luckily do not design their own protocols but re-use TLS/DTLS and hence they don't have to worry about these issues.

Instead, the problems are mostly with the last group, those who deploy. It is easy to publish a document that says "Don't use MD5, RC4, etc." but a completely separate story to change deployment -- particularly when considering the long tail. We have repeatedly seen that the big guys have to decide whether they want to cause problems to a certain (hopefully small) percentage of their customers. Smaller companies are not aware of the problems, not convinced that the issue is real, or in the worst case they are aware but have discontinued their work on the product. In many cases, problems with cryptographic algorithms are the last things on the list companies care about given that there are many other far more severe security issues lurking around the corner.

I believe that this document focuses on the wrong audience.

I have also have questions regarding the approach of documenting recommended algorithms. I have experienced the problem myself with the constantly changing landscape of algorithms. Is the approach of putting SHOULD+/SHOULD-/etc. labels into RFCs the best possible approach? I am wondering whether something better can be done instead that avoid having implementers and deployers to do a lot of research before they find out what the currently most relevant recommendation is.

In Section 3 it is not clear what the recommendations are:

  * Choosing Mandatory-to-Implement Algorithms

While we like to have mandatory-to-implement algorithms in the IETF this is rarely the problem in terms of interoperability (particularly when considering algorithm negotiation). We have also seen that different deployment environments favour different algorithms (or algorithm parameters). So, what is the recommendation? MTI per deployment environment?

Are there really so many interoperability problems caused by the lack of MTI algorithms in specifications? Often, having the same algorithm isn't sufficient since you will need to be interoperable at the level of parameters used by the algorithm, and at a higher layer with the authentication and key exchange algorithm, etc.

 * The subsequent sections about "Too Many Choices Can Be Harmful", "Picking One True Cipher Suite Can Be Harmful are", and "National Cipher Suites" essentially describe problems with deciding the right number of algorithms to be standardized. Clearly there is no right number. Since there are more and more  algorithms developed over time (since algorithms age and you also want to have backups) the number of algorithms increases always. So, what should a protocol author do? Often, authors shift the problem around by splitting the main protocol specification from an algorithm specification. Then, others can then add algorithms as needed. Should this be the recommendation instead?

The security consideration section points out the need for a software update mechanism (as a remark to the deployment/implementers community) by saying that "Mechanisms for timely update of devices are needed to deploy a replacement algorithm or suite.". While this is true that software update mechanisms are needed we are now much better off with software update mechanisms than ever before. While many of them are not standardized (such as package managers or firmware update mechanisms) the problem is again not with specifications but rather with policies used in deployments. To pick a random example take a look at Section 1.6 of this Android security publication: http://nemesys-project.eu/nemesys/files/document/resources/Android_security_pitfalls_lessons_learned_and_BYOD.pdf

In a nutshell I fear that protocol authors are not getting a lot of practical guidance from this document and the difficult problems are left as an exercise for the deployment community.

Ciao
Hannes

-----Original Message-----
From: secdir [mailto:[email-masked]] On Behalf Of Leif Johansson
Sent: 03 August 2015 21:20
To: [email-masked]; [email-masked]; IESG
Subject: [secdir] secdir review draft-iab-crypto-alg-agility-06 (almost done)

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving security requirements and considerations in IETF drafts.  Comments not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

1. Section 3.1 has a certain poetic quality to it but the use of the word "ought" ought perhaps be replaced with normative language unless this is a novel attempt to avoid RFC2119 terms :-)

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)

I also have some stylistic comments below, feel free to use or ignore as you see fit:

-- minor nits --

current text:

As new cryptanalysis techniques are developed and computing capabilities improve, the work factor to break a particular cryptographic algorithm will reduce, becoming more feasible for more attackers.

suggested:

As new cryptanalysis techniques are developed and computing capabilities improve, the work required to break a particular cryptographic algorithm (aka the work factor) will reduce, making an attack on the algorithm feasible for more attackers.

current text:

IETF protocols that make use of cryptographic algorithms MUST support one or more algorithm or suite identifier.

suggested:

IETF protocols that make use of cryptographic algorithms MUST support one or more identifier denoting an algorithm or suite of algorithms.

current text:

To achieve this goal, the base protocol specification includes a reference to a companion algorithms document, allowing the update of one document without necessarily requiring an update to the other.

suggested:

To achieve this goal, it is suggested that the base protocol specification include a reference to a companion algorithms document, allowing the update of one document without necessarily requiring an update to the other.

second paragraph

This section uses "deployment and configuration" (etc) a lot. It may be equally clear to just write "deployment"

_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2548782

---

From: Leif Johansson <[email-masked]>
Date: Tue, 04 Aug 2015 14:29:25 +0200

> In a nutshell I fear that protocol authors are not getting a lot of practical guidance from this document and the difficult problems are left as an exercise for the deployment community.

To some extent I think you are right but I'm not sure it is possible to
do much better in a general document. I think you are looking for a
"UTA-style BCP" with general applicability to algorithm selection and
agility and I'm not sure that is possible.

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 04 Aug 2015 08:40:16 -0700

> agility and I'm not sure that is possible.

It may not be possible, but that's what this draft is trying to do (but, 
as Hannes points out, without saying so). That is, without a tight 
scoping of who the document is meant for, it naturally has been pulled 
in different directions for different audiences without being explicit. 
UTA had the same problem with it's initial documents, and that is why it 
took so long to finish.

It would be reasonable to publish this document as-is, but it would be 
more reasonable to do a major rewrite with a much narrower focus now 
that we know how deep the disagreements in different parts of the 
community are about where to apply algorithm agility.

--Paul Hoffman

---

From: Leif Johansson <[email-masked]>
Date: Wed, 05 Aug 2015 13:25:05 +0200

> It may not be possible, but that's what this draft is trying to do (but,

I guess I didn't read it that way. My understanding is that the draft
was trying to describe the motivations and challenges involved in
algoritm agility and provide some basic guidance along the way.

I think it does a decent job at this.

Is it possible to say more in a document scoped to specific audiences?

Possibly.

Why not write those documents too?

> UTA had the same problem with it's initial documents, and that is why it

By IETF standards the UTA documents got done pretty quickly.

	Cheers Leif