Re: [Cfrg] Comparing ECC curves

[Watson Ladd <[e-mail]>]

On Wed, Jul 23, 2014 at 7:56 PM, Phillip Hallam-Baker
<[e-mail]> wrote:
> 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.

While I agree with the overall sentiment (excess agility is harmful,
we need to mandate two ciphers to
have a backup, crypto should be centralized by someone who knows what
they are doing), treating
this decision as though your draft was already ready doesn't work. In
particular this decision has to
be made assuming the status quo with regards to algorithms.

There are good reasons to have both CCM and GCM for example. A
nonce-reuse resistant protocol would
be more expensive than either, but potentially useful in cases where
protocols that fail when nonces are reused
would not be.

In particular the Great Cleanup has yet to begin: having consensus
crypto now requires reworking everything
to use it. That said, I don't think that twisted Edwards curves have
any difficulties in protocols that can negotiate
usable curves: they represent points for both signatures and ECDH.
(I do think we should compress the points: avoid nastiness).

We're going to have to change the order of encrypt then MAC in PGP
(which has no MAC), Kerberos(!),
SSH(!!), the record protocol in TLS (!!!) to get them all to be the
same. If we use AEAD it's the same issue.
Add that to the real problems of backwards compatibility and
implementation update cycles,
 and I'm not sure we can do it in a reasonable time frame.

>
> 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.

RSA is slow, requires big keys, and is usually used incorrectly in
IETF protocols:
OAEP should be be used instead of PKCS 1.5 encryption. Interesting TLS
has decided to use
DHE and ECDH, with no proposal to put RSA back on, except for
signatures (which sadly
are not PSS).

Sincerely,
Watson Ladd