Subject: Re: [saag] Please review draft-iab-crypto-alg-agility-00.txt

From: "Salz, Rich" <[email-masked]>
Date: Thu, 1 May 2014 16:38:20 -0400

> But *algorithm agility is a bad practice*.  It should not be encouraged, IMHO.

I disagree. We don't have flag days any more, and there will always be a set of entities that want to communicate and will have to work their way through a list to find a common tongue.  Does it matter if we call it "TLS-A" "TLS-B"...  Or if we call it "TLS 1 with aes, 3des, ..." ?  Either way, we have millions of items in a deployed base, updated at different times and cycles (if at all) and their users want them to communicate as best as they can.

	/r$

--  
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: [email-masked]; Twitter: RichSalz

---

From: S Moonesamy <[email-masked]>
Date: Fri, 02 May 2014 02:13:18 -0700

Hi Rich,
At 13:38 01-05-2014, Salz, Rich wrote:
>I disagree. We don't have flag days any more, and there will always 
>be a set of entities that want to communicate and will have to work 
>their way through a list to find a common tongue.  Does it matter if 
>we call it "TLS-A" "TLS-B"...  Or if we call it "TLS 1 with aes, 
>3des, ..." ?  Either way, we have millions of items in a deployed 
>base, updated at different times and cycles (if at all) and their 
>users want them to communicate as best as they can.

There is the interoperability aspect.  It's where the two sides enter 
into a security negotiation which can end up as better than nothing 
security.  In other words, a little security is better than no 
security.  The argument for that is, as mentioned about, the 
difficulty in making any changes to the deployed base.

Despite the news about some national security agility the current 
trend in the IETF still looks like business as usual.  The user wants 
to communicate with as many items as possible, and safely if that's 
cheap.  There are, what I assume to be, a small number of users who 
will do the same thing as everyone else and presume that it is safe 
because that's the existing practice.  That's where the algorithm 
agility gives me a security property which is inherently unsafe.

Does it matter whether we call it "TLS-A" "TLS-B" ...?  Yes.  B is 
after A and it is safer. :-)  Does it matter if we call it "TLS 1 
with aes, 3des, ..."?  That's a long list of strings.  I do not 
understand the meaning of those strings.

Regards,
S. Moonesamy

P.S. Our previous (unrelated) exchange and this subject could be 
questions about architecture.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 02 May 2014 14:44:40 +0200

On 4/30/14, 1:55 AM, ianG wrote:
> In general, I understand that many IETF algorithms make use of the
> practice of algorithm agility.  And therefore there is a need to
> document and improve that situation overall.
>
> But *algorithm agility is a bad practice*.  It should not be encouraged,
> IMHO.  Hence the major criticism of the document is that it appears to
> promote a bad practice.

Can you say why you think it's bad?

Eliot

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 2 May 2014 09:44:03 -0400

> Does it matter whether we call it "TLS-A" "TLS-B" ...?  Yes.  B is after A and it is safer. :-)

But 3DES is better than the newer RC4.  I know you put a smiley there, but TLS-A / TLS-B is just a list of strings too, in reality.

> There are, what I assume to be, a small number of users who will do the same thing as everyone else and presume that it is safe because that's the existing practice.  That's where the algorithm agility gives me a security property which is inherently unsafe.

I don't understand your logic here.

	/r$

---

From: ianG <[email-masked]>
Date: Fri, 02 May 2014 14:54:44 +0100

On 2/05/2014 14:44 pm, Salz, Rich wrote:
> But 3DES is better than the newer RC4.

Only if you narrow your context down to some group of cryptographers
advancing their art, or some immense world war of nation states cracking
each others' codes.

Meanwhile, back on the Internet, 3DES is the same as RC4, for the
purposes of the people.

> I know you put a smiley there, but TLS-A / TLS-B is just a list of strings too, in reality.

Yes, they are.  But they are a simple set to negotiation.  Pick the
latest, move on.  They are self-ordered and self-cleansing.

> I don't understand your logic here.

I read it as, everyone (statistically) will follow the default.  So stop
the nonsense, get rid of everything by the default, and everyone
(statistically) will get a better deal.

iang

---

From: ianG <[email-masked]>
Date: Fri, 02 May 2014 14:55:24 +0100

> Can you say why you think it's bad?

I'd love to and really should but have run out of time.  Points are
emerging in debate tho.

iang

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 2 May 2014 10:25:51 -0400

> Meanwhile, back on the Internet, 3DES is the same as RC4, for the purposes of the people.

Hunh?

One of the reasons why I am in favor of agility is from a software engineering perspective.  If you keep the data structures the same (when possible) but only change the algorithm, then you only have to write the parsing and generating code once, and dispatch off to a crypto library for the appropriate pieces. And the amount of code that I have to keep "secure", and worry about things like constant-time and key exposure, is much less.

If, however, you are putting out a new version every time you want to use new crypto, then there will be immense pressure to change the data structures to "fix some defects" or "add an optimization." (RFC 893, anyone?) When that happens, the job gets bigger as does the attack surface; we have to remind everyone to think carefully about padding again, for example.  Now, this may not happen, but it could and the chance of really bad failure is pretty big. And the dispatch is now based on the data structure version and must be carried throughout (or have spaghetti code), as opposed to localized. Maybe you know of widely-used crypto packages that wouldn't fall into this trap, but I don't.

> Yes, they are.  But they are a simple set to negotiation.  Pick the latest, move on.  They are self-ordered and self-cleansing.

But as history shows us, advances in crypto aren't strictly linear. We've just been through a period of whipsawing with Lucky-13, BEAST, and Crime. What's the likely cognitive dissonance and mass confusion when we advise everyone: "do TLS-B, no TLS-C, no sorry, back to B or maybe C depending."

So crypto agility can make configuration harder (but auto-updating browsers help), but I firmly believe that they make the underlying code more stable, and therefore more secure.

	/r$

---

From: Mouse <[email-masked]>
Date: Fri, 2 May 2014 10:42:44 -0400 (EDT)

>> Yes.  B is after A and it is safer. :-)

In what respects?

That's a rhetorical question.  The point behind it is that not everyone
- not every application, not every user, not every protocol - has the
same tradeoffs.  I can easily think of applications for which I'd
prefer 3DES over arc4 and just as easily think of others for which I'd
prefer the other way around.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 2 May 2014 10:45:23 -0400

> That's a rhetorical question.  The point behind it is that not everyone - not every application, not every user, not every protocol - has the same tradeoffs.  I can easily think of applications for which I'd prefer 3DES over arc4 and just as easily think of others for which I'd prefer the other way around.

Isn't this another reason why agility is needed?

	/r$

---

From: Mouse <[email-masked]>
Date: Fri, 2 May 2014 10:46:00 -0400 (EDT)

>>> But *algorithm agility is a bad practice*.
> I'd love to and really should but have run out of time.

So all we have to go on is your assertion that it's bad.  I for one
find that rather unconvincing, especially in view of the benefits I've
seen arise from it in the case I know well (SSH) that does have
algorithm negotiation baked into the protocol.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: ianG <[email-masked]>
Date: Fri, 02 May 2014 15:50:24 +0100

> Isn't this another reason why agility is needed?

No, it's a reason why it is a nice to have.  Need is a higher barrier.

iang

---

From: ianG <[email-masked]>
Date: Fri, 02 May 2014 15:51:22 +0100

> algorithm negotiation baked into the protocol.

Yep.  Apologies.  I understand that the words written aren't a cohesive
case against.

iang

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 2 May 2014 10:55:38 -0400

> No, it's a reason why it is a nice to have.  Need is a higher barrier.

Agree with the second, but as for the first... reasonable people may disagree.  I find the risks I outlined earlier more compelling, and the belief that things are more secure without it to be just that, a belief. I think I've said all I have to on this.

	/r$

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 2 May 2014 15:27:33 +0000

> IMHO.  Hence the major criticism of the document is that it appears to

I can't in all honesty take this seriously.  The problem with
agility in TLS, for example, is that the protocol is very popular,
and thus each constituency, unsurprisingly, wants to inject their
own set of algorithms, and yet we try to interoperate, so everyone
carries the kitchen sink.  This is much more a consequence of
ubiquity, rather than bad design.

SSH also has agility but is not a general-purpose transport security
library, has agility, but the algorithm bloat is manageable, the
same is mostly true of PGP.

If you build a Skype-like single source closed application, you
can dispense with algorithm negotiation and support a very short
sliding window protocol versions, with a fixed algorithm for each.

A protocol that is used in a small number applications gets to stay
pure.  A protocol that is used by everyone grows barnacles.  That's
the cost of success.

-- 
	Viktor.

---

From: S Moonesamy <[email-masked]>
Date: Fri, 02 May 2014 08:57:24 -0700

Hi Rich,
At 06:44 02-05-2014, Salz, Rich wrote:
>But 3DES is better than the newer RC4.  I know you put a smiley 
>there, but TLS-A / TLS-B is just a list of strings too, in reality.

Here's a list of strings:

   ECDHE-RSA-DES-CBC3-SHA
   ECDHE-ECDSA-DES-CBC3-SHA
   EDH-RSA-DES-CBC3-SHA
   EDH-DSS-DES-CBC3-SHA
   ECDH-RSA-DES-CBC3-SHA
   ECDH-ECDSA-DES-CBC3-SHA
   PSK-3DES-EDE-CBC-SHA
   ECDHE-RSA-RC4-SHA
   ECDHE-ECDSA-RC4-SHA
   ECDH-RSA-RC4-SHA
   ECDH-ECDSA-RC4-SHA
   RC4-SHA
   RC4-MD5
   PSK-RC4-SHA
   EXP-RC4-MD5

I'll trim the list to exclude RC4:

   ECDHE-RSA-DES-CBC3-SHA
   ECDHE-ECDSA-DES-CBC3-SHA
   EDH-RSA-DES-CBC3-SHA
   EDH-DSS-DES-CBC3-SHA
   ECDH-RSA-DES-CBC3-SHA
   ECDH-ECDSA-DES-CBC3-SHA
   PSK-3DES-EDE-CBC-SHA

Most people won't be able to figure out which of the above strings 
are unsafe.  I agree that TLS-A / TLS-B are merely strings.  It is 
easier to follow "must implement TLS-B".

>I don't understand your logic here.

I hope the above explains the choices being given to the user.

The is a message about crypto which was posted today ( 
https://lists.fedoraproject.org/pipermail/security/2014-April/001810.html ).

Regards,
S. Moonesamy

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 2 May 2014 17:38:30 +0000

On Fri, May 02, 2014 at 08:57:24AM -0700, S Moonesamy wrote:

> Most people won't be able to figure out which of the above strings are
> unsafe.  I agree that TLS-A / TLS-B are merely strings.  It is easier to
> follow "must implement TLS-B".

GnuTLS tackles this problem by giving names to collections of
ciphersuites that signal the requisite security level.  OpenSSL
is also moving in that direction, and Postfix which uses OpenSSL
also encourages users to use named cipher grades, whose underlying
cipherlists are for experts only.

This is user-interface issue, applications that expose raw cipher
names to users as the primary interface have poor user interfaces.

-- 
	Viktor.

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 2 May 2014 14:43:36 -0400

> GnuTLS tackles this problem by giving names to collections of ciphersuites that signal the requisite security level.  OpenSSL is also moving in that direction, and Postfix which uses OpenSSL also encourages users to use named cipher grades, whose underlying cipherlists are for experts only.

I encourage the user of cipher profiles, but name them after features, which is more stable, then strength qualifiers, which is a point in time statement.
That is, pfs-ciphers, not 'strong-ciphers.'   What was strong (or HIGH, in long-standing OpenSSL shorthand) in 1998 isn't in 2014, even though the config might not have  been revisited.

I probably did not make this point sufficiently clear, when I first suggested a profile mechanism on openssl-users.

	/r$

---

From: Matthew Chalmers <[email-masked]>
Date: Fri, 2 May 2014 13:48:39 -0500

I think (but I do not know) the idea with GnuTLS Priority Strings (
http://gnutls.org/manual/html_node/Priority-Strings.html) is that their
descriptive names are vaguely accurate for the version in which they're
used, but the suites within these "buckets" don't stay static across
versions--so if you regularly upgrade, the names continue to carry the same
"accuracy" but the algorithms behind them may change. This allows
implementers to select the appropriate suite without knowing any details
and as long as they keep their version patched/upgraded their selection
remains relatively constant.

On Fri, May 2, 2014 at 1:43 PM, Salz, Rich <[email-masked]> wrote:

> ciphersuites that signal the requisite security level.  OpenSSL is also
> moving in that direction, and Postfix which uses OpenSSL also encourages
> users to use named cipher grades, whose underlying cipherlists are for
> experts only.
>
> I encourage the user of cipher profiles, but name them after features,
> which is more stable, then strength qualifiers, which is a point in time
> statement.
> That is, pfs-ciphers, not 'strong-ciphers.'   What was strong (or HIGH, in
> long-standing OpenSSL shorthand) in 1998 isn't in 2014, even though the
> config might not have  been revisited.
>
> I probably did not make this point sufficiently clear, when I first
> suggested a profile mechanism on openssl-users.
>
>         /r$
>
> --
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

---

From: Mouse <[email-masked]>
Date: Fri, 2 May 2014 15:44:38 -0400 (EDT)

>> GnuTLS tackles this problem by giving names to collections of ciphersuites $
> I encourage the user of cipher profiles, but name them after features, which$
> That is, pfs-ciphers, not 'strong-ciphers.'

"pfs-ciphers" doesn't really do what you want, because there may
someday be many ways to get PFS, even if today there's only one.  And,
while I agree that "strong-ciphers" is a constantly sliding target,
"512-bit strength" makes sense.  It may be difficult to define
precisely in many cases, and it may need rephrasing for end-user
consumption (because of the whole 40-bit/128-bit debacle they've
already had shoved at them), but it avoids the whole "what was once
high strength is now medium strength" problem.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 02 May 2014 16:05:40 -0400

On 05/02/2014 03:44 PM, Mouse wrote:
> someday be many ways to get PFS, even if today there's only one.

Technically, there's two: traditional discrete log DHE and there's
ECDHE.  But if we're nit-picking on the terminology, it's not the cipher
that determines PFS at all, but rather the key exchange part of the
negotiated cryptographic suite.  (PFS suites use the same ciphers as
non-PFS suites)

Recent versions of GnuTLS have a priority string "PFS" that selects only
suites that have forward-secret key exchange mechanisms.

	--dkg