Re: [Dcrup] Review of draft-ietf-dcrup-dkim-crypto-03

[Peter Goldstein <[e-mail]>]

>
> Support for larger keys isn't the issue at hand.  The issue is the 255
>> character limit imposed by the DNS crudware.  And I think keys for each of
>> those curves easily fit under the limit.
>>
>

> I'm referring to the claim that hashing doesn't provide any value. For any
>> curve > 256 bits, it does.
>
> Nope, that's the wrong limit in this case.  By itself we have no interest
in whether the hashed key is smaller than the key itself.  Using a hashed
key is always a loss on space (need to include the full key on each
message), time/CPU (computing the hash) and complexity - even when the
hashed key is smaller than the key itself.  It's always a loss - the
question is whether the loss has any offsetting value.

Hashing only provides value if the base64 encoded public key pushes the
record over the 255 byte limit.  The point of my math was to show that the
larger key size EC algorithms work fine within this limit without hashing.
There is a limit, but it's higher than the key size for all plausible EC
algorithms likely to be introduced in the next decade.

If we didn't have to deal with the 255 limit, we wouldn't be talking about
hashing RSA 2048.  We'd just use a bigger key with the existing format and
algorithm and be done with it.  We wouldn't even need a new RFC (support
for 2048 bit keys is required by RFC 6376
https://tools.ietf.org/html/rfc6376#section-3.3.3)

There was zero interest in adding fingerprinting for RSA 1024 bit keys -
even though the fingerprint would be much smaller than the key.  The
existing format works fine for these keys.  So it's safe to say we could
handle any EC curve <= 1024 bits without fingerprinting.

The value of the hashing is entirely in its ability to help DNS
administrators avoid this 255 byte limit.  And my point is that for the
likely alternatives that would be added in the future, larger key RSA
aside, hashing adds no value.

Best,

Peter