Re: [dispatch] Updating DKIM for stronger crypto

[Eric Rescorla <[e-mail]>]

On Mon, Feb 6, 2017 at 3:48 PM, John R Levine <[e-mail]> wrote:

> Needless to say, 512 bits is now way too weak, and 1K is iffy, so it
>>> would be a good idea to update the advice.
>>>
>>
>> Well, I certainly agree that at some point it would be good to get to
>> larger
>> than 1024-bit RSA keys, we're fairly far from the point where it's cheap
>> to factor a 1024-bit RSA key ...
>>
>
> It's not urgent, but given the ARC work, it'd be nice to do this once
> rather than twice.
>
> It seems like this message suggests that the decision to store the key in
>> the TXT record is perhaps not the optimal design. If you were storing a
>> digest (as DANE does) then you could use arbitrary sized RSA keys without
>> running into the 256-character limit. This would also have the advantage
>> that if you ever needed to move to some post-quantum algorithm with big
>> keys (e.g., digest signatures), you would be in a somewhat better
>> position.
>>
>
> Hmmn.  So we'd put a copy of the verification key into the signature, and
> the verifier would hash that and see if it matched the hash in the DNS?


Yes.



>   I suppose that could work, but if we're going to open up the code, given
> that elliptic signers and verifiers are showing up in crypto libraries it's
> be a lot simpler change to DKIM.


I don't see why this would be the case. Think of signature verification as
a function

  F(K, M) -> {true, false}

Ordinarily K is the public key, and M is the message, but if you instead
store H(K_pub)
in the DNS, and send M = {K_pub, Message}, it's the same underlying
interface. And
as I indicated, this has other benefits, which include being able to handle
cryptographic
systems with much larger public keys if we ever need them.

-Ekr


> Regards,
> John Levine, [e-mail], Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
>