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

From: ianG <[email-masked]>
Date: Wed, 30 Apr 2014 00:55:09 +0100

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.

Folows are some more detailed comments:

   Many IETF protocols may use of cryptographic algorithms to provide
   confidentiality, integrity, or non-repudiation.

Non-repudiation is a dead concept from the 1990s.  It's not actually
possible to provide, and reference to it should be removed.

I'm guessing "may" ==> "make" in that para, also in abstract.

Also, this:

   For the mechanisms
   to work properly,communicating peers must support the same
   cryptographic algorithm or algorithms.

Begs the question:  this is talking about agility but agility isn't
introduced in the preceding sentence.

   Some approaches carry one identifier for each algorithm that is used.
   Other approaches carry one identifier for a suite of algorithms.
   *Either approach is acceptable*; however, designers are encouraged to
   pick one of these approaches and use it consistently throughout the
   protocol.

Well, disagreed!  picking a suite of algorithms is vastly superior to
allowing a caller to negotiate his own suite.  Indeed, 2.4 argues that
very case, it should end with "and therefore only selection of complete
suites is safe and permitted in future designs."  Remembering of course
that this document is read by the protocol designer and not the protocol
user...

2.3 makes a theoretical case that looks fine on paper, but it is falls
in practice.  If we look at the history of TLS, inordinate time has been
spent in allowing fashion algorithms to be mixed and matched, but the
claimed benefit of transition from weak to strong has never been
realised.  The headline example of this is BEAST, where a non-algorithm
attack resulted in transition to a weaker, deprecated algorithm!

History speaks, that benefit is not there, not available.  Instead there
is just a continuing drainage on time and effort for no benefit.  As a
data point, over on the ACH list, the team that creates the BetterCrypto
document probably spends about half of its time on one thing alone:
trying to figure out what is the better OpenSSL configuration string.
This waste is repeated across the developer and sysadm world;  it would
all disappear if there was one, only one true cipher suite.

2.4, as mentioned above, should be seen as an argument to totally ban
algorithm negotiation.

3.2 Migration mechanisms -- general comment:  In contrast to the above
arguments, if one avoids the siren of cipher suite negotiation and the
icebergs of algorithm negotiation, there is a need to upgrade the entire
protocol.  If the work that has been spent in agility was instead spent
in upgradeability, we would be better off, because this approach also
picks up where the real bugs lie:  in the protocol, which otherwise gets
too little attention because (a) it is too hard to upgrade the protocol
and (b) people are too busy arguing about vanity suites.

3.3 Does this sound like a case for them being separate protocols, with
similar internals?

4.  Also makes the case that this is a "good thing":

   The security of the Internet is improved when broken or
   weak cryptographic algorithms can be easily replaced with strong
   ones.

It assumes it is practical, efficient and delivers benefits.  None of
these things are true.  In practice, algorithm agility reduces the
security of the Internet, the sooner we get rid of it and move to faster
upgradeability, the better we'll be.

iang

---

From: Paul Lambert <[email-masked]>
Date: Wed, 30 Apr 2014 18:22:19 -0700

]-----Original Message-----
]From: saag [mailto:[email-masked]] On Behalf Of ianG
]
]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.

+1
With a slight qualification.

An ability to use a algorithm of your own choice is an important 
requirement.  This is not an "agility requirement", but a requirement
to identify a desired cipher suite. Cipher suites should be
able to be used to provide cryptographic separation of communications.
While we are all wanting to ensure interoperability, we must not forget
that NOT interoperating is a useful security feature.

In this context, a negotiation would not be appropriate for such
algorithm "diversity".  If a specific usage desired a specific
private algorithm it would not want to negotiate down to the default.

Paul

]
]
]
]Folows are some more detailed comments:
]
]   Many IETF protocols may use of cryptographic algorithms to provide
]   confidentiality, integrity, or non-repudiation.
]
]Non-repudiation is a dead concept from the 1990s.  It's not actually
]possible to provide, and reference to it should be removed.
]
]I'm guessing "may" ==> "make" in that para, also in abstract.
]
]Also, this:
]
]   For the mechanisms
]   to work properly,communicating peers must support the same
]   cryptographic algorithm or algorithms.
]
]Begs the question:  this is talking about agility but agility isn't
]introduced in the preceding sentence.
]
]
]
]   Some approaches carry one identifier for each algorithm that is used.
]   Other approaches carry one identifier for a suite of algorithms.
]   *Either approach is acceptable*; however, designers are encouraged to
]   pick one of these approaches and use it consistently throughout the
]   protocol.
]
]Well, disagreed!  picking a suite of algorithms is vastly superior to
]allowing a caller to negotiate his own suite.  Indeed, 2.4 argues that
]very case, it should end with "and therefore only selection of complete
]suites is safe and permitted in future designs."  Remembering of course
]that this document is read by the protocol designer and not the protocol
]user...
]
]
]
]2.3 makes a theoretical case that looks fine on paper, but it is falls
]in practice.  If we look at the history of TLS, inordinate time has been
]spent in allowing fashion algorithms to be mixed and matched, but the
]claimed benefit of transition from weak to strong has never been
]realised.  The headline example of this is BEAST, where a non-algorithm
]attack resulted in transition to a weaker, deprecated algorithm!
]
]History speaks, that benefit is not there, not available.  Instead there
]is just a continuing drainage on time and effort for no benefit.  As a
]data point, over on the ACH list, the team that creates the BetterCrypto
]document probably spends about half of its time on one thing alone:
]trying to figure out what is the better OpenSSL configuration string.
]This waste is repeated across the developer and sysadm world;  it would
]all disappear if there was one, only one true cipher suite.
]
]
]
]2.4, as mentioned above, should be seen as an argument to totally ban
]algorithm negotiation.
]
]
]
]3.2 Migration mechanisms -- general comment:  In contrast to the above
]arguments, if one avoids the siren of cipher suite negotiation and the
]icebergs of algorithm negotiation, there is a need to upgrade the entire
]protocol.  If the work that has been spent in agility was instead spent
]in upgradeability, we would be better off, because this approach also
]picks up where the real bugs lie:  in the protocol, which otherwise gets
]too little attention because (a) it is too hard to upgrade the protocol
]and (b) people are too busy arguing about vanity suites.
]
]
]
]3.3 Does this sound like a case for them being separate protocols, with
]similar internals?
]
]
]
]
]4.  Also makes the case that this is a "good thing":
]
]   The security of the Internet is improved when broken or
]   weak cryptographic algorithms can be easily replaced with strong
]   ones.
]
]It assumes it is practical, efficient and delivers benefits.  None of
]these things are true.  In practice, algorithm agility reduces the
]security of the Internet, the sooner we get rid of it and move to faster
]upgradeability, the better we'll be.
]
]
]
]
]
]iang
]
]_______________________________________________
]saag mailing list
][email-masked]
]https://www.ietf.org/mailman/listinfo/saag