[Cfrg] What the CFRG could do (was Re: Comparing ECC curves)

[Watson Ladd <[e-mail]>]

On Thu, Jul 24, 2014 at 6:25 AM, Phillip Hallam-Baker
<[e-mail]> wrote:
> 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...

We also got asked by the W3C to make an algorithms guide for webcrypto. In that
document we will be describing the risks of the algorithms included.
Not one of those
risks results from cryptanalysis: all result from poor design
decisions and a desire to
preserve backwards compatibility with some bad ideas.

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

Well, someone needs to do it.

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

Yes, this is a real problem. DES didn't die until 2009 or thereabouts, despite
very short key size.

However, a single IETF wide algorithm repository requires work on
negotiating what
to do: all protocols have their own negotiation methods, with their
own constants. It's not possible to have a central repository right
now, and updating a method will still require work.

(This might address new protocols, but we don't have many of those)
>
>
>> 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.

A choice which protocol designers keep getting wrong. That encrypt then mac is
secure is obvious and was known in 1995: Rogaway's comments on IPsec say this,
and are from that year. Oracles in CBC mode were from 2001, again in
2003, and it should
be no surprise that in 2014 we have not forgotten how to make them sing.

The only issue with TLS that your proposal would have solved was RC4.
>
> 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.

It's not consistency: it's about ensuring that we don't have nasty
surprises. People haven't looked at Kerberos, or CMS. (Well, the
people who let us know when we mess up) Protocol designers should not
do cryptographic protocols: cryptographers should.

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

RSA key transport is dead. You are right: I didn't include PKIX in
TLS, hence the confusion.
>
> 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.

Sincerely,
Watson Ladd


-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin