[Cryptography] IETF discussion on new ECC curves.

ianG iang at iang.org
Fri Aug 8 12:28:12 EDT 2014


On 8/08/2014 16:14 pm, John Kelsey wrote:
...
> Where I see some benefit to giving the user (or sysadmin) the ability to configure the crypto that's used is:

to play devil's advocate...

> a.  If there's some widely reported attack that means a particular ciphersuite is bad, you'd like it to be possible to turn that one off.  (It's much more important in this context to be able to turn a ciphersuite off than to be able to select it.)  

Yeah, I for one think that is a bad reason.  Let's see some data?  Some
results?

We've been doing secure protocols long enough, if this was a reasonable
design practice we'd have seen enough benefit by now to justify it.

> b.  If your organization has some rules about which ciphersuites you use (like federal users preferring FIPS approved algorithms), you may want to be able to select the ciphersuite.  It may even be that occasionally, there's a good reason to select those ciphersuites, though I suspect most of the time, it will be pointy-haired bosses mandating or forbidding something they read about (and didn't quite understand) in the news.  


Why do we pander to these organisations?  People quote Russian and
Chinese ciphers, but I don't see why we should inflict the choice on the
rest of the net just because some organisation thinks they'd like to
push an agenda.

It seems to be a logical absurdity.  NIST has a standards suite that
people think highly of.  So we have to accept NIST.

So, if we accept NIST, we now must let the Russians GOSTs in.  And the
Chinese.  ... We're back then at the same place of vanity ciphers, 'cept
on a national level.  Absurd.


> c.  If there's a performance/security tradeoff, that might be worthwhile to expose to the user, but only if the performance option is still secure and the secure option still performs okay.  

That argument seems to have died now that crypto consumes <1% of one core...

The hardware people do push that they have implemented certain
algorithms and modes in hardware, so therefore we have to support them.
 Personally, I think there are reasons to not support them, as much as
there are reasons to support them.


> Are there other reasons to allow many choices?  I mean, the practical reason we have a gazillion choices for every security standard is because that's how standards group politics works--everyone champions their favorite algorithm.  This has been known to have some downsides now and again, though, so it would be nice to eliminate it except where there's a real benefit you can point to in having different choices about ciphersuites or algorithms or curves or whatever.  

It is easy for a standards group / committee to add things in.

But they've got no answer as to how to take things out.  It's the sysadm
community that has to take it out, and they aren't doing that sort of
work en masse, their world is more about upgrading in isolation than
re-configuring as a herd.  And, sometimes not even upgrading.

If say IETF committees followed Microsoft and announced end-of-life
dates for ciphersuites, then it might work.  But even that is a stretch,
look how hard it was for NIST to push 2048 bit RSA keys as a minimum
standard.

iang


More information about the cryptography mailing list