Subject: Re: [saag] draft-iab-crypto-alg-agility-01.txt

From: Russ Housley <[email-masked]>
Date: Fri, 10 Apr 2015 17:24:04 -0400

I am working on -03 of the crypto-alg-agility document, and I went back to your message as part of that work.

I have tried to put together some words that show that both extremes can be problematic.  I hope that you and the others on this list will review and comment.

Russ

= = = = = = =

4.  Cryptographic Algorithm Specifications

4.1.  Too Many Choices Can Be Harmful

   When it is too easy to specify the use of arbitrary cryptographic
   algorithms, the algorithms get implemented and deployed.  Some people
   say that the freedom to specify algorithms independently from the
   rest of the protocol has lead to the specifications of vanity
   cryptographic algorithms.  Once deployed, it is quite difficult to
   remove algorithms because interoperability with some party will be
   impacted.  As a result, weak ciphers stick around far too long.
   Sometimes implementors are forced to maintain  cryptographic
   algorithm implementation well beyond their useful lifetime.

   All implementors are expected to support the mandatory-to-implement
   cryptographic algorithm, and they can include any others algorithms
   that they desire.  The mandatory-to-implement algorithms are chosen
   to be highly secure, following the guidance in RFC 1984 [RFC1984].
   Generally, the mandatory-to-implement algorithms ought to be
   preferred, and the other algorithms ought to be selected only in
   special situations.  However, it can be very difficult for a skilled
   system administer to determine the proper configuration to achieve
   these preferences.

   In some cases, more than one mandatory-to-implement cryptographic
   algorithm has been specified.  The is intended to ensure that a
   secure cryptographic algorithm will be available, even if one of the
   mandatory-to-implement algorithms is broken.  There is always a
   fallback.  However, this adds to the difficult decision for a skilled
   system administer to determine the proper configuration to achieve
   their preferences.

4.2.  Picking One True Cipher Suite Can Be Harmful

   After great study and evaluation, the protocol designer could select
   the one true cipher suite.  This has at least two desirable
   consequences.  First, the protocol is simpler since there is no need
   for algorithm negotiation.  Second, system administrators do not need
   to make any algorithm-related configuration decisions.  However, the
   only way to respond to news that the one true algorithm has been
   broken is to update the protocol specification to the next version,
   implement the new specification, and then get it deployed.
   Experience with the transition from SHA-1 to SHA-256 indicates that
   this cycle takes more than five years.

On Jul 4, 2014, at 3:21 PM, ianG wrote:

> I wonder if it is is possible to list the potential strategies for alg
> agility?  And perhaps add their pros&cons?  Here's a strawman list of
> possibilities, with full intent to be rewritten entirely, just in case
> this helps:
> 
> 
> 
> 1.  smorgasbord, as typified by SSL.  Anyone can add an algorithm, and
> once added this tends to be supported for a long time.  Crypto freedom
> taken to vanity extremes.
> 
> Downside is weakness of deprecation;  weak ciphers stick around forever.
> As algorithms are the component of choice, protocol errors tend to
> impact many algorithms.  Lots of 'downgrade' possibility, lots of user
> confusion or ignorance, waste in maintenance of too many components.
> 
> 
> 2.  primary + extras.  Everyone must implement the central chosen set,
> and any others they desire.  Most instances will prefer/negotiate the
> primary, only in specialised instances will the alternates be chosen.
> 
> Downside is that there is no clear alternate choice.
> 
> 
> 3.  Primary + secondary MUSTs.  As there are two MUST suites, there is
> always a fallback, by config.
> 
> 
> 4.  Odds and evens.  Each version has two suites, a primary and a
> secondary, initially numbered 1 and 2.  In each succeeding version, the
> last version's primary is dropped, and secondary moves up to primary.  A
> new secondary is added (numbered 3, etc).  Fallback / switchover can be
> done by configuration and by version upgrade.
> 
> 
> 5.  one true cipher suite.  No config fall back available, a failure in
> the suite triggers a requirement to upgrade the entire version.  Simpler
> to implement, no negotiation woes.
> 
> 
> 6.  parallel twinned suites, where the protocol duplicates every
> component.  Ciphers are CTR/XOR'd in parallel, HMACs are serialised, etc.
> 
> This involves a performance hit that many would be annoyed by, and is
> sometimes considered to be "inventing your own ciphers."  No particular
> upgrade path but not particularly vulnerable to any component weakness.
> 
> 
> 
> 
> 
> I'm sure there are more.  And the thoughts above are very scrappy, by no
> means suitable for a draft.  But maybe a useful approach?
> 
> iang
> 
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Steve Crocker <[email-masked]>
Date: Fri, 10 Apr 2015 19:57:12 -0400

Russ,

RFC 6975, “Signaling Cryptographic Algorithm Understanding in DNS Security Extensions (DNSSEC)“ speaks to the issue of when servers can stop supporting older algorithms.  It’s intended to facilitate withdrawing algorithms from the suite when there has been sufficient uptake of replacement algorithms.  Perhaps it would be appropriate to include a reference to this RFC and to include some discussion about how to withdraw algorithms when their time has come.

Also, I believe you want “led” instead of “lead”.

Steve

Steve

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 11 Apr 2015 10:41:09 +0000

Russ Housley ‎<[email-masked]> writes:

>   cryptographic algorithm,
>[...]
>   The mandatory-to-implement algorithms are chosen
>   special situations.

Hmm, is this meant to be a sort of abstract best-practice thing, or a record
of what actually happens?  I'm thinking of X9.42 DH and DSA in CMS, where the
MUST MTI's were really a SHOULD NOT (X9.42) and, at best, MAY (DSA) while the
MAY (RSA) was actually a MUST.

>  However, the

That implies that there's another option, that not going with 1TCS avoids
these problems, when in fact pretty much all existing implementations don't go
with 1TCS and yet still have the problems ascribed to 1TCS above.  So I'm not
sure if the above text is an accurate characterisation of the situation,
you're damned if you do and damned if you don't, but more damned if you don't
do 1TCS.

Peter.

---

From: Russ Housley <[email-masked]>
Date: Sun, 12 Apr 2015 15:46:11 -0400

> RFC 6975, “Signaling Cryptographic Algorithm Understanding in DNS Security Extensions (DNSSEC)“ speaks to the issue of when servers can stop supporting older algorithms.  It’s intended to facilitat…

I'll take a look.

> Also, I believe you want “led” instead of “lead”.

Thanks.  Fixed.

Russ

---

From: Russ Housley <[email-masked]>
Date: Sun, 12 Apr 2015 16:12:32 -0400

> MAY (RSA) was actually a MUST.

CMS does not have any MTI algorithms.  Rather, the applications that make use of CMS specify the MTI algorithms for that application, so I assume your comments are about the MTI algorithms for S/MIME before the RSA patent expired.  There was a lot of reluctance to make RSA the MUST implement algorithm before its patent expired.

> you're damned if you do and damned if you don't, but more damned if you don't

I think there are many things going on that lead to your observation, and I am trying to tease them apart and discuss them separately.

First, when there is more than one MTI algorithm, there needs to be adequate diversity, otherwise a cryptoanalytic advance that weakens one will also weaken the other.  I added some text on diversity:

   In some cases, more than one mandatory-to-implement cryptographic
   algorithm has been specified.  The is intended to ensure that a
   secure cryptographic algorithm will be available, even if one of the
   mandatory-to-implement algorithms is broken.  To achieve this goal,
   the selected algorithms must be diverse, so that a cryptoanalytic
   advance against one of the algorithms does not also impact the other
   selected algorithms.  The idea is to have an implemented and deployed
   algorithm as a fallback.  However, the additional algorithm choices
   adds to the difficult decision for a skilled system administer to
   determine the proper configuration to achieve their preferences.

Second, some attacks are against the manner in which the MTI algorithm is used, not the algorithm itself.  I have some text in the security considerations on that:

   In some cases, the cryptographic algorithm remains strong, but an
   attack is found against the way that the strong algorithm is used in
   a particular protocol.  In these cases, a protocol change will
   probably be needed.  For example, the order of cryptographic
   operations in the TLS protocol has evolved as various attacks have
   been discovered.  Originally, TLS performed encryption prior to
   computation of the message authentication code (MAC).  This order of
   operations is called encrypt-then-MAC, and it is no longer considered
   secure [BN][K].  As a result, a mechanism was specified to use MAC-
   then-encrypt instead [RFC7366].  Future versions of TLS are expected
   to use exclusively authenticated encryption algorithms [RFC5166],
   which should resolve the ordering discussion altogether.   After
   discovery of such attacks, updating the cryptographic algorithms is
   not likely to be sufficient to thwart the new attack.  It may
   necessary to make significant changes to the protocol.

Are there any other aspects?

Russ

---

From: Watson Ladd <[email-masked]>
Date: Mon, 13 Apr 2015 08:43:04 -0700

> First, when there is more than one MTI algorithm, there needs to be adequate diversity, otherwise a cryptoanalytic advance that weakens one will also weaken the other.  I added some text on diversi…

Let's consider actual cryptanalytic weaknesses in TLS. Would adding
more MTI algorithms have solved any of them? Because the fact is AES,
not RC4, was MTI in TLS.

>    determine the proper configuration to achieve their preferences.

Why are we kicking configuration decisions to administrators? Do they
know how to evaluate the impact of biases in the RC4 keystream vs.
clique attacks on AES? Obviously no: RC4 wouldn't still be an issue if
they did. Nor would they have kept TLS 1.0 alive for decades after
vulnerabilities were found and fixed.

> Are there any other aspects?

Can you point to any weakness in TLS that multiple MTI algorithms
would have prevented, or made the amelioration of easier? What about
other protocols? That's leaving aside that removing weak algorithms,
not adding strong ones, improves security. The argument for
negotiation is that we can switch to strong algorithms while weak ones
gradually get used less and less, and the argument for multiple MTI
algorithms is that we all switch in the same direction. But this runs
against having per-site policies on what to use.

Sincerely,
Watson Ladd

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 13 Apr 2015 16:31:07 +0000

On Mon, Apr 13, 2015 at 08:43:04AM -0700, Watson Ladd wrote:

> would have prevented, or made the amelioration of easier?

Much of this discussion misses the point about multiple algorithms
in TLS.  In practice their purpose is not insurance against compromise
of an algorithm.

Rather, as I see it, the main reason for the multitude of algorithms
in TLS is that TLS is a general-purpose building block for secure
data transport that is used in many diverse environments.

TLS is not just a browser security mechanism.  Different hardware
platforms and applications using TLS have different needs.

A single cipher-suite in TLS would not serve those different needs.

The cost of the spectacular success of TLS as a foundation for
communication security in many different environments is its
diversity of features.

If we were to redesign TLS anew for each application, specifying
the supported cipher suite (per version) for the application-specific
TLS variant in the appropriate application protocol standard, then
we might begin to tease apart cases in which cipher suites are for
cryptographic diversity rather than application diversity.

I don't think the above is likely to happen, so I see TLS continuing
to offer broad range of cryptographic primitives.  

Progress would be removing aging features as the protocol is revised,
so that newer versions of the protocol leave weaker options behind.
Each protocol version should still offer a variety of primitives
to serve the various constituencies that need them.

-- 
	Viktor.

---

From: Yoav Nir <[email-masked]>
Date: Mon, 13 Apr 2015 20:00:05 +0300

> On Apr 13, 2015, at 6:43 PM, Watson Ladd <[email-masked]> wrote:
> 

It would have solved things if the cryptanalytic advances were against AES. As it is, the fact that a non-RC4 algorithm was MTI made if far safer to disable RC4 on servers and clients. An attack now against AES leaves all of us scrambling to implement ChaCha while turning on 3DES.

> vulnerabilities were found and fixed.

They kept TLS 1.0 alive because until not too long ago most clients did not support anything better than TLS 1.0. They made a rational choice. Even now, there’s a lot of those clients around.

> against having per-site policies on what to use.

You can’t remove old, weak algorithms unless everyone has implemented acceptable ones. If we had some kind of counter mode MTI algorithm years ago, the impact of attacks against CBC like  BEAST would have been much less.

Yoav

---

From: ianG <[email-masked]>
Date: Mon, 13 Apr 2015 18:03:56 +0100

> in TLS.  In practice their purpose is not insurance against compromise

I don't believe that "reason" is met in practice, so I concur that there 
has to be another motive.

> A single cipher-suite in TLS would not serve those different needs.

Can you give a for-instance of these features that relate to the choice 
of algorithms?

Are there significant usages out there that would not be served by, say, 
hypothetically, tls1.4 using a single 25519 + chacha/poly combination?

> communication security in many different environments is its

It may be just me, but I can't think of a feature that both exists in 
algorithm diversity and should be trusted to users to choose.  Examples?

I agree that historically, there was the 'export' feature.  But I argue 
that this was not something we should be pandering too.  We should be 
working for a reasonable security level for all users, not just some 
users we're told we're allowed to work with.

iang

ps; TLS represents a really good slice of history.  If we can show it 
for TLS, that's something.  If we can't show it for TLS, that's ... the 
converse of something.

---

From: ianG <[email-masked]>
Date: Mon, 13 Apr 2015 18:20:10 +0100

Some comments!

> I have tried to put together some words that show that both extremes can be problematic.  I hope that you and the others on this list will review and comment.

What seems to be missing in this section is the subsection:

     4.x A few choices can be harmful

The anti-factors in considering a few choices are:

   * does not cover protocol bugs
   * opens up downgrade bugs and complexity bugs
   * allows hair splitting between 2 and 3 choices
   * permits individual communities to add new choices
   * still does not cover the process of switching
   * has not delivered any historical advantage

I'm sure there are more...

>     algorithm implementation well beyond their useful lifetime.

This is a bit of a jump.  Perhaps insert:

In order to manage the proliferation of choices, and the consequent 
explosion of negotiation possibilities leading to failure to agree and 
insecurity from downgrade attacks, many protocols have implemented 
mandatory-to-implement algorithms.  ...

>     system administer to determine the proper configuration to achieve

And, the manner or protocol in which system administrators are advised 
to switch is at best ad hoc, and at worst absent entirely.

> 4.2.  Picking One True Cipher Suite Can Be Harmful

I think, if you want to stick to that title, you might want to find some 
examples of actual harm ;)

For example, there were the various WIFI and mobile phone adventures, 
but I'd argue there that they chose them to be weak in the first place, 
so I argue that doesn't count.

>     implement the new specification, and then get it deployed.

So, in practice, when an algorithm had to be changed, how was that 
deployed?  My understanding of all the TLS breaks was that in practice, 
most people upgraded their software to the next release... thus 
amounting to the same thing.

>     this cycle takes more than five years.

That's pretty thin.  In practice, the reason was that the various 
parties basically didn't bother to start the work when they got the 
chance.  SHA-256 was issued a long time ago and basically everyone 
ignored the implied deprecation message.  They even pretty much dawdled 
after the 2004 Shandong results.

So, applied to the above, the deprecation process that is natural for 
this business applies to all of the above 3 choices, and a rather 
perverse advantage of the 1TCS approach is that it perhaps removes the 
fig leaf of algorithm agility from the process:  people actually ought 
to be prepared with a new protocol, and not hide behind the notion that 
they can simply swap algorithms if there are any problems.

iang

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 13 Apr 2015 17:32:13 +0000

On Mon, Apr 13, 2015 at 06:03:56PM +0100, ianG wrote:

> Can you give a for-instance of these features that relate to the choice of
> algorithms?

    * Not all systems have hardware AES support.  Constant-time
    software AES is noticeably slower than RC4, thus the historical
    popularity of RC4.

    * Not all systems support ECC, but some applications need more
    compact signatures or higher signing throughput (even if
    verification is slower than with RSA).

    * There will be many platforms with fast hardware AES, and
    others where ChaCha20 in software is more performant.  Some
    folks in .ru will likely want code points for TLS with GOST.
    (I on the other hand generally disable the GOST engine in
    OpenSSL as a matter of attack surface mitigation).

    * Reportedly, many constrained devices implement minimal TLS
    features with PSK.

    * Postfix prefers anonymous key agreement when doing opportunistic
      TLS.  Some folks use anon-DH with channel binding to SASL auth.

> hypothetically, tls1.4 using a single 25519 + chacha/poly combination?

Hard to say how well that will fit all the use cases, the history
of TLS is there was no one-size-fits-all combination.  Have we
found one yet?  Intel's server chips have hardware AES, but not
hardware ChaCha20, server operators might not want to sacrifice
the performance.

Perhaps we're much better at balanced universally applicable secure
algorithms now, but I don't know that we're quite there yet.

-- 
	Viktor.

---

From: Paul Lambert <[email-masked]>
Date: Mon, 13 Apr 2015 11:10:30 -0700

In documenting the requirements for identifying and selecting
cryptographic algorithms we should also consider that not having
interoperability may be a valuable service for a security protocol.
Different domains of communication may be established by mandating the use
of different cryptographic algorithms.

The need for a protocol to support a Œdiversity¹ of algorithms for
community separation is a different use case than Œagility¹ to negotiate
interoperability. Cryptographic agility assumes that all devices
interoperate and that weaker algorithms are replaced over time by better
algorithms. Cryptographic diversity allows some communities to select a
cryptographic algorithm suite of their own choice for separation of
traffic and perceived security benefits of the suite. Diversity implies
that variations in exposed identifiers may be sensitive.  The easy
identification of a unique algorithm identifier readily identifies a
particular traffic flow and its mapping to the community using the
algorithm suite. 

The current draft text mandates that a protocol ŒMUST carry¹ an identifier.

	2.1.  Algorithm Identifiers

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

Since this use of an identifier is usually part of the setup of a secure
communication flow, the unique identifier is carried in the clear and
leaks knowledge to an observer of the accepted algorithms for agility.
This is very useful information to profile the communications.  Security
protocols should be allowed to minimize such profiling.

Paul

On 6/27/14, 11:47 AM, "Russ Housley" <[email-masked]> wrote:

>Thanks for the lively discussion of the -00 version of this document.
>Please review and comment on the updated version.
>
>Russ
>
>
>
>> A new version of I-D, draft-iab-crypto-alg-agility-01.txt
>> has been successfully submitted by Russell Housley and posted to the
>> IETF repository.
>> 
>> Name:		draft-iab-crypto-alg-agility
>> Revision:	01
>> Title:		Guidelines for Cryptographic Algorithm Agility
>> Document date:	2014-06-27
>> Group:		iab
>> Pages:		8
>> URL:            
>>http://www.ietf.org/internet-drafts/draft-iab-crypto-alg-agility-01.txt
>> Status:         
>>https://datatracker.ietf.org/doc/draft-iab-crypto-alg-agility/
>> Htmlized:       
>>http://tools.ietf.org/html/draft-iab-crypto-alg-agility-01
>> Diff:           
>>http://www.ietf.org/rfcdiff?url2=draft-iab-crypto-alg-agility-01
>> 
>> Abstract:
>>   Many IETF protocols may use of cryptographic algorithms to provide
>>   confidentiality, integrity, or non-repudiation.  Communicating peers
>>   must support the same cryptographic algorithm or algorithms for these
>>   mechanisms to work properly.  This memo provides guidelines for
>>   ensuring that such a protocol has the ability to migrate from one
>>   algorithm to another over time.
>

---

From: Derek Atkins <[email-masked]>
Date: Tue, 14 Apr 2015 11:03:38 -0400

ianG <[email-masked]> writes:

[snip]
> Can you give a for-instance of these features that relate to the
> choice of algorithms?

Sure.  Extremely small (IoT) devices just can't do RSA, and even have
trouble with ECC.  Had we stuck with RSA-only we'd completely lose the
ability to deploy TLS on constrained nodes.

> Are there significant usages out there that would not be served by,
> say, hypothetically, tls1.4 using a single 25519 + chacha/poly
> combination?

Possibly, yes.  (I haven't tried implementing this yet so I don't have
actual numbers to give you, but even seck163 is way too slow in my
environments.

-derek
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: ianG <[email-masked]>
Date: Tue, 14 Apr 2015 17:46:41 +0100

Hi Viktor,

thanks, that gets me something to sink my teeth into!

>      software AES is noticeably slower than RC4, thus the historical

So, the performant sector exists because the protocol is successful. 
There is no 'feature' here.  This sector doesn't actually deliver any 
benefit in and of itself, it solely exists to make the delivered product 
to the users faster.

Such arguments therefore should be entirely completely utterly ignored 
when considering security and upgrades for the future.

(I say "should" in the IETF sense.  Of course, hardware suppliers and 
accelerator builders control substantial funds and they will mob the 
committees to turn the priorities upside down, and to their advantage. 
Their overwhelming money doesn't change the fact that these people are 
the tail, and they shouldn't wag the dog.)

>      * Not all systems support ECC,

Well, ok, so nobody supports the next version.  Which means?  We all 
have work to do...

>      but some applications need more

Again, these are envelope calculations, at the margin.  They aren't 
features.  They literally only exist because *there is a choice*.  If 
there was no choice, I'm pretty sure that they'd figure it out...

>      others where ChaCha20 in software is more performant.

Ditto.  Are we in the business of making old protocols more efficient 
but less robust through complexity, or...?

>      Some

The national champions argument.  I agree that this is a 'feature'.

But it isn't a feature that we should encourage, IMHO, and in this 
post-Snowden era I would have thought that plain:  Yes, we know that the 
Russians will balk, but the flip side of that is that the NSA managed to 
push through export ciphers, and they oh-so-desperately want us to 
demonstrate our keenness for a neoclipper 'feature'.

Meanwhile, nobody wants to particularly hand the Chinese the 'great 
feature of algorithm agility', even the Chinese!

>      * Reportedly, many constrained devices implement minimal TLS

Right, there definitely should be better support for opportunistic TLS, 
and there should be much better support for shared keys.

But that's outside the question of algorithm agility?

>        TLS.  Some folks use anon-DH with channel binding to SASL auth.

My understanding of the use of Anon-DH in this context is that it is for 
PFS or protocol forward security (PFS), but this is better for all and 
should be a standard feature.

> of TLS is there was no one-size-fits-all combination.

I'd say the history of TLS is that a lot of people have fiddled around 
at the margin, but if they'd been given only one suite, then there 
wouldn't have been anyone left off the boat.

> Have we

Right, any rollout period of N to N+1 is going to have to be planned 
with TLS quite carefully if it involves hardware changes.  And Intel 
people are going to need to be warmed up in advance.  But again, this is 
just business, just performance issues, not 'features'.

> algorithms now, but I don't know that we're quite there yet.

:) I'm not sure we have tried in committee.

To be frank, I really doubt the TLS group will decide to go for 1TCS. 
They are going to shrink their algorithms over the next 2 cycles until 
they are at a point where they are arguing about 3 versus 4.  Bitterly, 
to the death.  Then, half the group will be arguing for 1TCS and the 
other half will hold the line against them so they can get back to the 
critical 3 v. 4.

The real win is everyone else.

Establishing the better practice is going to take one of the other 
emerging protocols to pick this path, and see how we go.  Eg, our old 
whipping horse Bitcoin is a successful protocol that doesn't 'feature' 
agility, and seems to be doing fine, more or less, overall.

iang

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 14 Apr 2015 17:53:51 +0100

On 14/04/15 17:46, ianG wrote:
> There is no 'feature' here. 

I don't think that is correct. The number of concurrent sessions
a server can handle is, I believe, an important feature for folks
who develop or deploy. And I'm pretty sure I've been told that
the AES h/w vs. RC4 (and in future chacha) thing is impactful
there. (Be good if someone could confirm that or even quantify
it.)

S.