Re: [Cfrg] Comparing ECC curves

[Phillip Hallam-Baker <[e-mail]>]

On Wed, Jul 23, 2014 at 9:10 PM, Watson Ladd <[e-mail]> wrote:
> On Wed, Jul 23, 2014 at 4:17 PM, Phillip Hallam-Baker
> <[e-mail]> wrote:
>> On Wed, Jul 23, 2014 at 6:33 PM, Benjamin Black <[e-mail]> wrote:
>>> On Wed, Jul 23, 2014 at 3:28 PM, Phillip Hallam-Baker
>>> <[e-mail]> wrote:
>>>>
>>>>
>>>> 3) Do we need to consider 2^192 work factor?
>>>>
>>>> I can't see any case where I am interested in a work factor of 2^192.
>>>> Either I am willing to make some concession to performance or I want
>>>> it gold plated and 2^256. I would quite like to see the 2^192 work
>>>> factor nuked.
>>>>
>>>
>>> Phillip,
>>>
>>> This was our conclusion, as well. If you haven't seen it, here's the NUMS
>>> TLS draft which only specifies the twisted Edwards curves at 128 and 256 bit
>>> security levels: http://tools.ietf.org/id/draft-black-tls-numscurves-00.txt
>>
>> Just trying to push back on the idea we need the options .. :-)
>>
>> Similarly, I am not interested in a set of curves that is
>> hyperoptimized for TLS and can't be used for S/MIME. When we were
>> discussing random curves, changing the curve was pretty much the same
>> as changing the key. Now that we are doing the close to powers of 2
>> curves with highly optimized code, changing the curve is like changing
>> to a whole new algorithm.
>>
>> As far as the code is concerned it is better to think about them as
>> choosing between ECDHE-25519 and ECDHE-256p rather than ECDHE with a
>> named curve. Changing the curve is going to select a different
>> implementation.
>>
>>
>> The end product I want from this is a set of backup public key
>> algorithms that can be made a RECOMMENDED algorithm with a view to
>> making them a MUST algorithm replacing RSA-2048 at some point in the
>> future. I want to encourage dedicated hardware support, etc. etc.
>
> Why will that happen with these curves when it didn't with the NIST
> curves vs. RSA?
> Yes, I'm aware of patent issues that used to exist, but this was an
> unforced error in
> standardization: RSA is of a similar vintage.

Several reasons.

First off, we had this philosophy that lots of algorithm choices was a
good thing. It is only recently that it is generally acknowledged that
adding stronger algorithms does not improve security. Only stopping
using weak algorithms helps matters.

So back in the mid 90s we had dozens of symmetric ciphers and RSA and
DSA and DH and it was thought to be a good thing. Then we got the idea
that there should be as few algorithms as possible, preferably one
good one. And now I am pushing for a scheme where we have one REQUIRED
and one RECOMMENDED per type of algorithm and make no other
recommendations except in unusual circumstances where a legacy
transition is in progress.

The main reason we haven't had consensus across the IETF on mandatory
to implement algorithms before is that the decisions were taken at
different times and the field moved on. So the mandatory to implement
algorithms for quite a few specs are now out of date. S/MIME requires
3DES for example. This was changed for SIP but not for mail as far as
I can see.

It is possible that some people used to enjoy algorithm discussions.
At this point I think we all realize that the discussion is necessary
but not so much fun that I want to have it repeated for each working
group.

But the main reason I want to change that practice is that when we
decided to move to AES in place of 3DES, that was a decision made
independent of any particular protocol but implementation required us
to make changes to every protocol separately. That is silly and
tedious and lots of makework for authors and the IESG.

Hence the rationale for this draft:

http://tools.ietf.org/html/draft-hallambaker-consensuscrypto-00

The idea of this is that future protocols would not make MTI choices
of algorithms, they would reference the consensus RFC and leave it at
that. If we change our idea of what necessary crypto is, the consensus
RFC would be made obsolete and replaced by a new one.

The reason for having backup algorithms is that unless we are in panic
mode (like Google starts selling a Quantum Computer just for S&G) the
pattern should be that the new REQUIRED algorithm is a previous
RECOMMENDED algorithm. Since they are backup algorithms there is a
requirement that they be constructed in a distinctly different fashion
(e.g. SHA-3 is a logical backup to SHA-2 because it is spongeworthy).
The backups also need to be distinctly stronger.

I will also note that it looks like we now have a pretty strong
primary and backup for hash functions and MACs and seem to be
approaching consensus on public key (RSA plus ECC exact scheme to be
decided). That leaves a gap for backup encryption algorithm.