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

From: ianG <[email-masked]>
Date: Thu, 03 Jul 2014 19:07:02 +0100

On 27/06/2014 20:25 pm, Christian Huitema wrote:
> Am I the only one who believes that the draft would be stronger if it also discussed the "pitfalls of agility?"

You're not the only one, and I would go further.

For the document to be useful, I think the document should describe what
purpose, what it is, and *how it works*.  From the intro:

  "cryptographic algorithms
   become weaker with time.  ...  Algorithm
   agility is achieved when a protocol can easily support more that one
   set of cryptographic algorithms.

describes the first two, but I have trouble with the how;  all
discussions about how we actually switch from A to B tend to be short of
a reasonable plan.

Section 2.3 "Transition from Weak Algorithms" says:

   To facilitate transition, protocols MUST be able to advertise which
   algorithms are supported.  This may naturally occur as part of an
   algorithm selection or negotiation mechanism.
   ...
   In any case, there come a point where one refuses to use the weak
   algorithm.  This can happen on a flag day, or each installation can
   select a date on their own.

So we've got

   + first party selection and/or second party negotiation.
   + flag days.

This seems to be pretty weak in contrast to the criticisms levelled.
Consider this statement:

   When selecting a suite of cryptographic algorithms, the strength of
   each algorithm MUST be considered.

Yet, we know that most (or all) users are not capable of considering the
strength of algorithms, and certainly not capable of balancing the
strength of a suite.  This is a job for experts.

> The poster child for that is probably TLS. [good points snipped...]

My first thought then is that we should not be allowing the swapping of
algorithms;  only suites should be swapped, because only suites can be
balanced.  (And, by extension, only complete suites.)

Second point being, if we are recommending alternate suites, then there
has to be a way for those above mentioned experts to then make a switch
so.  The first mechanism above (selection/negotiation) is something done
by users or user software, and it fails to answer how a user would know.
 The second does speak:

   In any case, there come a point where one refuses to use the weak
   algorithm.  This can happen on a flag day....

How is this day declared?  I can imagine that if the WG declares that on
a certain date suite A is deprecated, then that would work, at least for
further discussion.  But, I'd like to see that stated up front.  I
wonder if this is actually what IETF is set up to do, so I'd really like
to see some views here.

And, to repeat myself, if the document is suggesting that the users
themselves decide, this is dangerous advice, not friendly at all.

> There are counter arguments, e.g. national governments insisting that their communications be secured via homemade crypto. ...

In this time of post-Snowden revelations, is the national government
argument still relevant?

iang

---

From: ianG <[email-masked]>
Date: Fri, 04 Jul 2014 20:21:20 +0100

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

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sun, 06 Jul 2014 19:08:20 +0200

On Fri, 2014-06-27 at 19:25 +0000, Christian Huitema wrote:
> Am I the only one who believes that the draft would be stronger if it
> also discussed the "pitfalls of agility?" The poster child for that is
> probably TLS. The protocol includes a negotiation capability, so that
> the parties can chose from a list of enumerated options. In theory,
> that's very nice. As time passes, better options become available and
> can be negotiated, providing for better security. But in practice,
> there are issues: downgrading attacks, code bloat, unclear rules for
> how to choose the "best" option, difficulty to remove obsolete
> options... As a design rule, it seems that "few good options" is better
> than "unfettered negotiation."

Indeed, but this is a side-effect of independent of the agility. You may
provide a protocol without future agility of algorithms, and still
provide a ton of options to use. If you implement all the ciphersuites
defined in TLS 1.0, you'll find out it is an enormous number of
combinations defined on the main protocol. The later additions were very
little in comparison to original numbers; since TLS 1.0 in standards
track we only got AES-CBC/AES-GCM as well as elliptic curves, whilst in
TLS 1.0 we had RC2-40, RC4-40, RC4, DES-40, 3DES, IDEA, several
ciphersuites with static DH keys that were never actually used and so on
(to their defense that was at a time that cipher research was at its
infancy and supporting more options seemed like a good idea).

What was more of an issue with the agility in TLS was that for a few
years after it was deployed we had implementations, that would
disconnect the client if proposed ciphersuites that were not referenced
in the original spec, or advertised its support for TLS 1.1. That caused
several interoperability issues, and was one of the fact that TLS 1.1
was never actually deployed (which would have made BEAST and several
other attacks a non-issue). So while TLS is now considered an agile
protocol, that was not the case in mid-2000, and its agility
capabilities caused more trouble than solved issues.

regards,
Nikos

---

From: Derek Atkins <[email-masked]>
Date: Mon, 07 Jul 2014 08:40:29 -0400

> confusion or ignorance, waste in maintenance of too many components.

I hit this problem a couple weeks ago.  I was trying to buy a train
ticket online but I was getting an SSL error:  no common cipher.  It
turns out the server *ONLY* supported a few DES ciphers, which of course
I had turned off.  They didn't support any of the AES or RC4 ciphers
that firefox-30 supported.  Quite annoying.  "Luckily" I know how to
enable those ciphers in firefox, so I was able to get my train ticket,
but I certainly feel like I need to watch my credit card statement for
the next month or two.  *shudders*

> to implement, no negotiation woes.

And no way to recover if the suite is found to be bad.  C.f.: DES+MD4.

-derek

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

---

From: ianG <[email-masked]>
Date: Mon, 07 Jul 2014 20:06:18 +0100

>> possibilities, with full intent to be rewritten entirely, just in case

Derik comments on 1. and 5.  Should we take that as endorsement for the
extremes?

> the next month or two.  *shudders*

As long as you don't advance that as some sort of positive experience to
keep those practices going, it's a fine beer anacdote ;-)

> And no way to recover if the suite is found to be bad.  C.f.: DES+MD4.

Wait, someone was still using that?  Post mid 1990s?  That's ...
irresponsible.  No need to discuss, there is no good advice for that
sort of stupidity.

iang