Re: [Cfrg] Comparing ECC curves

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

On Wed, Jul 23, 2014 at 11:50 PM, Watson Ladd <[e-mail]> wrote:
> On Wed, Jul 23, 2014 at 7:56 PM, Phillip Hallam-Baker
> <[e-mail]> wrote:

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

I don't think so. The Status Quo emerged from the days when each WG
made the choice of algorithms independently. We have already decided
to only make that decision in CFRG.

The reason for pointing to the draft is that it makes the argument in
greater detail, not to suggest it was a decision already made.

We discussed the need for the draft in SECDIR and I was asked to write
it. So far, yours is the first response...


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

There we get into protocol design and the question is whether we
should standardize on 'AES' for encryption or AES-CBC / AES-GCM, etc.

I would really like to standardize on AES-GCM going forward for new
protocols. But right now I can't use that in Windows .NET without
writing my own AES code. Hmmm.

For existing protocols written before encrypt and authenticate became
fashionable, I would not want to go back and try to retrofit use of an
E&A scheme. That would certainly not be something to do in the
consensus draft.


> In particular the Great Cleanup has yet to begin: having consensus
> crypto now requires reworking everything
> to use it.

No, not at all. The idea of stating what the consensus is so that an
implementation can state that it complies with RFC-6071 and RFC-XXXX
and tell people that it will interoperate securely with
implementations that comply with either.

So if HMAC-SHA1 is specified as MTI in the base spec and
HMAC-SHA-2-256 as MTI in RFC-XXXX, then an implementation claiming to
be compliant with both would have to implement both.

What this approach does not fully address is what to do if the base
spec specifies MD5 and there is no RFC that has come out saying 'do
not use MD5'.


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

Order of operations is a protocol design choice, not an algorithm
choice. Funny thing is that people keep telling me that it is
absolutely vital that the order be one or the other 'because security'
but which is better changes.

Obviously the order is going to have an effect on security. But
changing it has a bigger effect on code. If people wanted consistency
at that level they would have to write drafts for each protocol to
harmonize them all. I don't see the point in that unless it is part of
the ongoing process of rewriting everything in JSON.


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

Well the PKIX stack in the WebPKI is currently limited to RSA2048 in
practice, so I don't know what that means.

The RFC cited in the draft specifies OAEP and PKCS 1.5. It should be
just OAEP. I was looking for the OAEP draft, didn't notice it also has
the PKCS 1.5.