Subject: [saag] draft-iab-crypto-alg-agility-03

From: Russ Housley <[email-masked]>
Date: Fri, 1 May 2015 16:59:45 -0400

A new version (-03) has been submitted for draft-iab-crypto-alg-agility:
https://www.ietf.org/internet-drafts/draft-iab-crypto-alg-agility-03.txt

I tried to capture the discussion from last month.  Please review and comment.

Russ

---

From: Eliot Lear <[email-masked]>
Date: Sat, 02 May 2015 16:40:16 +0200

Hi Russ,

Some comments:

Bottom of the introduction:

>    Experience shows that many people are
>    unwilling to disable older weaker algorithms; it seems that these
>    people prefer to live with weaker algorithms, sometimes seriously
>    flawed ones, to maintain interoperability with older software well
>    after experts recommend migration.

There are a myriad of reasons, and this is just one important one.  It
may be that they are *unable* to make the changes because there is
hardware involved that cannot support the new algorithm (footprint
issues, accelerator problems, or what-have-you).  I will hazard a guess
that a more common scenario is that they have no idea *how* to make the
changes or even that the changes are needed.  My suggestion is either
don't get into the "it seems..." business or to cover all the ground.

Section 2/Section 3:

There is a minor organizational issue here, and perhaps Housley's Law
applies (the one about the document not being finished until all excess
verbiage has been removed).  It looks like part of Section 3 could be
merged with Section 2 (I got initially confused by some ambiguous advice
in 2.1 that was cleared up in 3.1).  Some of Section 3 belongs with the
text in Section 4.  Specifically, 3.3 is really tied quite closely to
4.2, 4.3, and 4.4.

Section 2.2:
>    For this reason, the
>    protocol MUST specify one or more mandatory-to-implement algorithm or
>    suite.

It may be worth reminding people that "mandatory to implement !=
mandatory to deploy" and holding some discussion on this point.  For
instance, some environments may find the MTI insufficient for their
purposes.

Section 2.4:

>
>    When selecting a suite of cryptographic algorithms, the strength of
>    each algorithm SHOULD be considered.  It needs to be considered at
>    the time a protocol is designed.  It also needs to be considered at
>    the time a protocol implementation is deployed and configured.
>    Advice from from experts is useful, but in reality, it is not often
>    available to system administrators that are deploying and configuring
>    a protocol implementation.  For this reason, protocol designers
>    SHOULD provide clear guidance to implementors, leading to  balanced
>    options being available at the time of deployment and configuration.

I'll note that most of us applications people need current advice (like
some that's in this draft) just like using what's out there and
available in tools like OpenSSL, but these libraries generally do *not*
provide that advice.  Perhaps it would be useful to even have an
appendix that includes translation of the advice in the draft to choices
in the various libraries.  No, I'm not offering to write it, and I'd
understand if it gets missed because nobody else does either.

Section 4.3:

I was surprised to find that you did not follow up your earlier
philosophical statement in Section 4.2 ("The idea is to have an
implemented and deployed algorithm as a fallback") with some sort of
SHOULD or MUST around that, either in 4.2 or 4.3.  Maybe it belongs in
2.2 next to the MUST at the top.  Maybe I missed it?

Section 4.4:

This advice is largely around what happens when there is some user
interface to configure systems.  That is unlikely to be the case with
the Internet of Many Tiny Little Things (IoMTLT).  Do you want to give
some more specific advice to top off what is being said wrt smart
objects (following up from the tech plenary)?

Nittiest nit:

>    Algorithm agility is achieved when a protocol can easily migrate from
>    one algorithm suite to another, more desirable one, over time.

I think the "," after "another" is unneeded.

Eliot

---

From: ianG <[email-masked]>
Date: Sun, 03 May 2015 20:53:54 +0100

> don't get into the "it seems..." business or to cover all the ground.

One way to look at the disable process is to ask "so what?"  If we've 
decided in our wisdom that alg X is bad and people should upgrade to Y, 
so what?  If the software is working for some company C, and there isn't 
much a of likelihood of any harm to it, why not carry on?

The problem arises when Company C is talking to Company D, and the 
damage lands on the latter not the former.  (If it lands on neither, for 
all combinations C & D, then we've got it wrong apparently.)

So damage lands on D due to inaction by C.  Sucks to be D.  At this 
point, we might have to make a judgement call that involves the body 
public, because it isn't an individual equation any more, and we can't 
appeal to individual goodness.

Hence question 1.  Who is the organisation / where is the manual / who 
signs off on that call?  How is it that we (hypothetically) issue a 
death notice for RC4?

But, we also need some form of stick to push the laggards.  That stick 
could be soft, or hard.  For what it's worth, I see the only sensible 
stick being an informed opinion (of the above person) that the thing is 
insecure, where before it was secure.  Such an informed opinion then 
becomes distributed, promulgated, respected, and eventually becomes 
evidence in court.  This is often expressed as "security updates 
withdrawn" as per software.  If hypothetically, the IETF were to issue a 
"RFW" or request for withdrawal, that would have the effect of creating 
a cost for all those laggards who didn't upgrade, leaving them to 
analyse their costs.  Question 2, then, is what is the stick?

> understand if it gets missed because nobody else does either.

The problem with bit strengths is particularly clear -- we don't 
actually agree with a lot of the advice out there.  NIST for example 
runs around and tells everyone that they have to use RSA2048 but hints 
from Snowden at that meeting the other day indicate that RSA1024 is 
still cool, and others swear that 4096 must be used.  Without getting 
into the wherefores and whys of that debate, the point is that it leads 
to endless wheel spinning and never seems to actually improve the security.

For this reason, I suggest things like 1TCS -- because it's one go, and 
done.  No more discussions about the numbers, as the public (which in 
this case is anyone after the original author) is more than likely going 
to get it wrong.  Make the author get it right, save the effort.  If I 
can take the author's advice on protocol design then I can take her 
advice on the numbers too.

(The same goes for choice of different algorithms, mixing and matching, 
etc.)

iang

---

From: Eliot Lear <[email-masked]>
Date: Sun, 03 May 2015 22:27:41 +0200

Hi Ian,

On 5/3/15 9:53 PM, ianG wrote:

>
>
> One way to look at the disable process is to ask "so what?"  

I wasn't going to get into the discussion of externalities, but it would
be wrong to state that there is a single reason for why devices continue
to support insecure algorithms.  There are many reasons.

> into the wherefores and whys of that debate, the point is that it
> leads to endless wheel spinning and never seems to actually improve
> the security.
>
> For this reason, I suggest things like 1TCS -- because it's one go,
> and done.  No more discussions about the numbers, as the public (which
> in this case is anyone after the original author) is more than likely
> going to get it wrong.  Make the author get it right, save the
> effort.  If I can take the author's advice on protocol design then I
> can take her advice on the numbers too.
>

If there is such a suggestion, that would be helpful.  Otherwise, laying
out the decision path in as much detail as is practical would be good. 
I don't know if it needs to be in this draft, but I know this sort of
information is useful.

Eliot

---

From: ianG <[email-masked]>
Date: Tue, 05 May 2015 13:34:02 +0100

Hi Eliot,

> to support insecure algorithms.  There are many reasons.

And, to add salt to the wound, we're in the business of predicting the 
future.  When a WG sets down a cipher suite, it decides on today info, 
but has to predict out to 5, 10, 20 year timeframes.  The fact that we 
don't do well at predicting the future all the time doesn't obviate the 
need for some form of process/plan/etc...

> If there is such a suggestion, that would be helpful.

I don't know who else has made this suggestion, but I first wrote about 
it here:

"Hypothesis #1 -- The One True Cipher Suite"
http://iang.org/ssl/h1_the_one_true_cipher_suite.html
8th November 2007

iang

> Otherwise, laying

---

From: Russ Housley <[email-masked]>
Date: Tue, 26 May 2015 10:20:15 -0400

Eliot:

I missed these comments when I produced -04.  Sorry.  I'm tackling them now.

See below.

Russ

On May 2, 2015, at 10:40 AM, Eliot Lear wrote:

> There are a myriad of reasons, and this is just one important one.  It may be that they are unable to make the changes because there is hardware involved that cannot support the new algorithm (footprint issues, accelerator problems, or what-have-you).  I will hazard a guess that a more common scenario is that they have no idea how to make the changes or even that the changes are needed.  My suggestion is either don't get into the "it seems..." business or to cover all the ground.

I suggest:

In a perfect world, this takes place before the older algorithm or suite of algorithms is catastrophically weakened.  However, experience has shown that many people are unwilling to disable older weaker algorithms;  people live with weaker algorithms, sometimes seriously flawed ones, well after experts recommend migration.  There may be many reasons for this situation, but maintaining interoperability with older implementations is clearly an important one.  Difficulty supporting the new algorithm on deployed hardware is clearly another.

> 
> Section 2/Section 3:
> 
> There is a minor organizational issue here, and perhaps Housley's Law applies (the one about the document not being finished until all excess verbiage has been removed).  It looks like part of Section 3 could be merged with Section 2 (I got initially confused by some ambiguous advice in 2.1 that was cleared up in 3.1).  Some of Section 3 belongs with the text in Section 4.  Specifically, 3.3 is really tied quite closely to 4.2, 4.3, and 4.4.

I will take a look at this after this round of comments.  Stephen just asked for review on SAAG and CRFG.  I do not want to do too much restructuring while so many people are looking.  It will make comment resolution too hard.

> It may be worth reminding people that "mandatory to implement != mandatory to deploy" and holding some discussion on this point.  For instance, some environments may find the MTI insufficient for their purposes.

I suggest:

For this reason, the protocol MUST specify one or more mandatory-to-implement algorithm or suite.  This does not require all implementations to use this algorithm or suite, but it does require that users are able to configure them.  Note that mandatory-to-implement algorithms or suites are not specified for protocols that are embedded in other protocols; in these cases the system-level protocol specification identifies the mandatory-to-implement algorithm or suite.

> I'll note that most of us applications people need current advice (like some that's in this draft) just like using what's out there and available in tools like OpenSSL, but these libraries generally do not provide that advice.  Perhaps it would be useful to even have an appendix that includes translation of the advice in the draft to choices in the various libraries.  No, I'm not offering to write it, and I'd understand if it gets missed because nobody else does either.

The recent BCP out of the UTA WG provides some of this advice, but it does so using TLS-specific terms.  I'd rather not try to do that kind of thing using library-specific terms.  For one thing, how would we decide which libraries to include.  It could be a very large task.

> Section 4.3:
> 
> I was surprised to find that you did not follow up your earlier philosophical statement in Section 4.2 ("The idea is to have an implemented and deployed algorithm as a fallback") with some sort of SHOULD or MUST around that, either in 4.2 or 4.3.  Maybe it belongs in 2.2 next to the MUST at the top.  Maybe I missed it?

I could add a sentence that says protocol designers SHOULD NOT pick just one, but I really think we need to leave room for judgement.

> Section 4.4:
> 
> This advice is largely around what happens when there is some user interface to configure systems.  That is unlikely to be the case with the Internet of Many Tiny Little Things (IoMTLT).  Do you want to give some more specific advice to top off what is being said wrt smart objects (following up from the tech plenary)?

Note that the plenary did not offer BCP-level advice on this topic.  I suggest:

Some nations specify cryptographic algorithms, and then require their use through legislation or regulations.  These algorithms may not have wide public review, and they can have limited reach of deployments.  Yet, the legislative or regulatory mandate creates a captive market.  As a result, the use of such algorithms get specified, implemented, and deployed.  The default server-side configuration SHOULD disable such algorithms; in this way, explicit action by the system administrator is needed to enable them where they are actually required.  For tiny devices, such administrator action may only be possible at the time the device is deployed.

> I think the "," after "another" is unneeded.

Fixed.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 26 May 2015 19:48:43 +0200

Hi Russ,

Thanks for the response.  Please see below.

On 5/26/15 4:20 PM, Russ Housley wrote:
>> There are a myriad of reasons, and this is just one important one. 
>> It may be that they are *unable* to make the changes because there is
>> issues, accelerator problems, or what-have-you).  I will hazard a
>> guess that a more common scenario is that they have no idea *how* to
>> make the changes or even that the changes are needed.  My suggestion
>> is either don't get into the "it seems..." business or to cover all
>> the ground.
>
> I suggest:
>
> In a perfect world, this takes place before the older algorithm or
> suite of algorithms is catastrophically weakened.  However, experience
> has shown that many people are unwilling to disable older weaker
> algorithms;  people live with weaker algorithms, sometimes seriously
> flawed ones, well after experts recommend migration.  There may be
> many reasons for this situation, but maintaining interoperability with
> older implementations is clearly an important one.  Difficulty
> supporting the new algorithm on deployed hardware is clearly another.

I think we are arriving at the meat of the matter: if what we are
talking about is *removing* or *turning off* some suite or algorithm,
from a constrained device perspective, that is a strong and defensible
argument because the footprint impact is either zero or negative.  And
so I like your phrasing above.  However, I suggest that it could be a
bit more succinct.  E.g.,

For various reasons, most notably interoperability concerns, experience
has shown that it has proven difficult for administrators and
implementors to turn off weak algorithms.  In addition, inability of
legacy systems and resource-constrained devices to support new
algorithms has added to those concerns.
>> applies (the one about the document not being finished until all
>> excess verbiage has been removed).  It looks like part of Section 3
>> could be merged with Section 2 (I got initially confused by some
>> ambiguous advice in 2.1 that was cleared up in 3.1).  Some of Section
>> 3 belongs with the text in Section 4.  Specifically, 3.3 is really
>> tied quite closely to 4.2, 4.3, and 4.4.
>
> I will take a look at this after this round of comments.  Stephen just
> asked for review on SAAG and CRFG.  I do not want to do too much
> restructuring while so many people are looking.  It will make comment
> resolution too hard.

Sure.

> For this reason, the protocol MUST specify one or more
> mandatory-to-implement algorithm or suite.  This does not require all
> implementations to use this algorithm or suite, but it does require
> that users are able to configure them.  Note that mandatory-
Perhaps the following:

s/implementations/deployments/
and
s/,but.*\./but rather that they be available for all deployments./

> to-implement algorithms or suites are not specified for protocols that
> are embedded in other protocols; in these cases the system-level
> protocol specification identifies the mandatory-to-implement algorithm
> or suite.

I have no objection to this text, but it is not necessary for what I
mentioned above.
>> I'll note that most of us applications people need current advice
>> (like some that's in this draft) just like using what's out there and
>> available in tools like OpenSSL, but these libraries generally do
>> *not* provide that advice.  Perhaps it would be useful to even have
>> an appendix that includes translation of the advice in the draft to
>> choices in the various libraries.  No, I'm not offering to write it,
>> and I'd understand if it gets missed because nobody else does either.
>
> The recent BCP out of the UTA WG provides some of this advice, but it
> does so using TLS-specific terms.  I'd rather not try to do that kind
> of thing using library-specific terms.  For one thing, how would we
> decide which libraries to include.  It could be a very large task.

Sounds like a reference could do for now.

>> SHOULD or MUST around that, either in 4.2 or 4.3.  Maybe it belongs
>> in 2.2 next to the MUST at the top.  Maybe I missed it?
>
> I could add a sentence that says protocol designers SHOULD NOT pick
> just one, but I really think we need to leave room for judgement.
>

I may have misunderstood the sentence or the document, but if it is
intended as a best current practice, a normative SHOULD seems like a
good thing.  But I see that I am sounding like the normative word
police, up with which one SHOULD NOT put, and so I'll leave it at that ;-)

>> the Internet of Many Tiny Little Things (IoMTLT).  Do you want to
>> give some more specific advice to top off what is being said wrt
>> smart objects (following up from the tech plenary)?
>
> Some nations specify cryptographic algorithms, and then require their
> use through legislation or regulations.  These algorithms may not have
> wide public review, and they can have limited reach of deployments.
>  Yet, the legislative or regulatory mandate creates a captive market.
>  As a result, the use of such algorithms get specified, implemented,
> and deployed.  The default server-side configuration SHOULD disable
> such algorithms; in this way, explicit action by the system
> administrator is needed to enable them where they are actually
> required.  For tiny devices, such administrator action may only be
> possible at the time the device is deployed.
>

The main point I was making above is that constrained devices may not
have administrative capabilities to enable or disable specific suites
through their UIs.  I shutter to think of my dad trying to sort this on
his refrigerator.  Or me, for that matter.  And so what I was thinking
of was something like the following:

National standards pose great challenges to implementers of constrained
devices.  Some do not have user interfaces.  In addition, an implementer
may have to choose between market-specific product releases that may be
incompatible elsewhere or an increased development and production costs
to support multiple algorithms that likely will undergo less testing
than a small number of well proven global algorithms or suites.

Eliot

---

From: Russ Housley <[email-masked]>
Date: Tue, 26 May 2015 15:19:00 -0400

Eliot:

I dropped the parts where we have reached agreement.

> I think we are arriving at the meat of the matter: if what we are talking about is removing or turning off some suite or algorithm, from a constrained device perspective, that is a strong and defensible argument because the footprint impact is either zero or negative.  And so I like your phrasing above.  However, I suggest that it could be a bit more succinct.  E.g.,
> 
> For various reasons, most notably interoperability concerns, experience has shown that it has proven difficult for administrators and implementors to turn off weak algorithms.  In addition, inability of legacy systems and resource-constrained devices to support new algorithms has added to those concerns.

I think that the part that talks about living with weak algorithms should be retained:

...  For various reasons, most notably interoperability concerns, experience has shown that it has proven difficult for implementors and administrators to remove or disable weak algorithms.  Further, the inability of legacy systems and resource-constrained devices to support new algorithms adds to those concerns.  As a result, people live with weaker algorithms, sometimes seriously flawed ones, well after experts recommend migration.

>> For this reason, the protocol MUST specify one or more mandatory-to-implement algorithm or suite.  This does not require all implementations to use this algorithm or suite, but it does require that users are able to configure them.  Note that mandatory-
> Perhaps the following:
> 

That work for me.

>> to-implement algorithms or suites are not specified for protocols that are embedded in other protocols; in these cases the system-level protocol specification identifies the mandatory-to-implement algorithm or suite.
> 
> I have no objection to this text, but it is not necessary for what I mentioned above.

Right.  I had to make a change to that part to make it flow.

> Sounds like a reference could do for now.

Section 2.2 points to it already.  I'm not sure another reference in Section 2.4 is really helpful.

> I may have misunderstood the sentence or the document, but if it is intended as a best current practice, a normative SHOULD seems like a good thing.  But I see that I am sounding like the normative word police, up with which one SHOULD NOT put, and so I'll leave it at that ;-)

I understand and agree with your comment about some document restructuring.  Let's see if we can get all of the guidance agreed, and then work on that.  Section 4 already makes this clear, I think.  It does not use SHOULD or SHOULD NOT in light of the discussion in Section 4.3.   It already says:

Ideally, two independent sets of mandatory-to-implement algorithms will be specified, allowing for a primary suite and a secondary suite.  This approach ensures that the secondary suite is widely deployed if a flaw is found in the primary one.

> The main point I was making above is that constrained devices may not have administrative capabilities to enable or disable specific suites through their UIs.  I shutter to think of my dad trying to sort this on his refrigerator.  Or me, for that matter.  And so what I was thinking of was something like the following:
> 
> National standards pose great challenges to implementers of constrained devices.  Some do not have user interfaces.  In addition, an implementer may have to choose between market-specific product releases that may be incompatible elsewhere or an increased development and production costs to support multiple algorithms that likely will undergo less testing than a small number of well proven global algorithms or suites.

I'd prefer to separate these to things.  I suggest two paragraphs:

Some nations specify cryptographic algorithms, and then require their use through legislation or regulations.  These algorithms may not have wide public review, and they can have limited reach of deployments.  Yet, the legislative or regulatory mandate creates a captive market.  As a result, the use of such algorithms get specified, implemented, and deployed.  The default server or responder configuration SHOULD disable such algorithms; in this way, explicit action by the system administrator is needed to enable them where they are actually required.  For tiny devices with no user interface, an administrator action may only be possible at the time the device is purchased.

National algorithms can force an implementer to produce several incompatible product releases for a different countries or regions, which has significantly greater cost over development of a product using a globally-acceptable algorithm.

Russ

---

From: Eliot Lear <[email-masked]>
Date: Tue, 26 May 2015 22:03:08 +0200

Hi Russ,

On 5/26/15 9:19 PM, Russ Housley wrote:
> ...  For various reasons, most notably interoperability concerns,
> experience has shown that it has proven difficult for implementors and
> administrators to remove or disable weak algorithms.  Further, the
> inability of legacy systems and resource-constrained devices to
> support new algorithms adds to those concerns.  As a result, people
> live with weaker algorithms, sometimes seriously flawed ones, well

That works for me.

> I understand and agree with your comment about some document
> restructuring.  Let's see if we can get all of the guidance agreed,
> and then work on that.  Section 4 already makes this clear, I think.
>  It does not use SHOULD or SHOULD NOT in light of the discussion in
> Section 4.3.   It already says:
>
> Ideally, two independent sets of mandatory-to-implement algorithms
> will be specified, allowing for a primary suite and a secondary suite.
>  This approach ensures that the secondary suite is widely deployed if
> a flaw is found in the primary one.
>
>

Sounds good.

> and deployed.  The default server or responder configuration SHOULD
> disable such algorithms; in this way, explicit action by the system
> required.  For tiny devices with no user interface, an administrator
> action may only be possible at the time the device is purchased.

> National algorithms can force an implementer to produce several
> incompatible product releases for a different countries or regions,
> which has significantly greater cost over development of a product
> using a globally-acceptable algorithm.
>

We discussed this offline.  I think Russ will be posting something about
this...

Eliot

---

From: Russ Housley <[email-masked]>
Date: Tue, 26 May 2015 16:05:52 -0400

>> 'd prefer to separate these to things.  I suggest two paragraphs:
>> 
> We discussed this offline.  I think Russ will be posting something about this...

National Cipher Suites

National algorithms can force an implementer to produce several incompatible product releases for a different countries or regions, which has significantly greater cost over development of a product using a globally-acceptable algorithm.  This situation could be even worse if the various national algorithms impose different requirements on the protocol, its key management, or its use of random values.

Russ