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

[Eric Rescorla <[e-mail]>]

I was going to respond, but I'd just be repeating myself. As I said
earlier, it's probably just easier to discuss this in Prague.

-Ekr


On Sun, Jul 9, 2017 at 8:49 PM, Peter Goldstein <[e-mail]> wrote:

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