Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-crypto-03.txt

I agree with John here.  If we don't have even a single concrete notion of
a future key type that would need fingerprinting, why should we try to bias
the implementation in that direction?

It's also not clear to me why fingerprints are the more 'general'
solution.  As John notes, fingerprints wind up using more time and space -
an additional hash computation, and the addition of the base64 key to all
signed messages.  Fingerprints provide no benefit, other than a workaround
for DNS crudware that can't handle multi-string TXT records.  And in the
EdDSA case it doesn't even provide that benefit.  There's no compelling
reason to make fingerprints the default.

+1 to moving forward with the -03 draft.

Best,

Peter

On Tue, Jul 4, 2017 at 8:09 AM, John R Levine <johnl@taugh.com> wrote:

> I agree with ekr on this one: publishing a key fingerprint is the more
>> general solution, even if right now we can't think of keys that require it
>> other than RSA. So why not, in the future, always publish key fingerprints?
>>
>
> 1)  For the next decade or so, to the extent anyone uses a signature other
>    than plain rsa, I expect they'll use eddsa since it's faster than rsa
>    and the keys are smaller.  (Librariess will have the code since they
>    need it to verify other people's signatures, the only question is
>    whether they use it, just like sha-1 and sha-256 body hashes now.)
>    Key hashes use more time and space while providing no benefit to eddsa
>    signatures.  It doesn't seem like great design to pessimize the common
>    case.
>
> B)  Barring surprises, eddsa should be good enough to last as long as DKIM
>    does.  But if we have surprises, they tend to be, you know, surprising.
>    Maybe we'll switch to some other elliptic curve which has keys smaller
>    than 1100 bits, in which case key hashes still have no benefit.  Or
>    maybe some mega-parellel rainbow table scheme will come out of left
>    field and we'll deprecate all of the sha-N hashes.  It doesn't seem
>    like great design to plan for stuff that we can't predict and that will
>    probably never happen.  Our crystal ball has never been great: back in
>    2006 would anyone have suggested that crudware that can't handle
>    multi-string TXT records would be a design issue a decade later?
>
> iii)  It seems unliely that Cisco will assert your patent, but until they
>    say something one way or the other, who knows.  It'd be prudent to be
>    prepared for the eventuality, particularly since it costs us nothing to
>    do so.
>
>
> Regards,
> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
>
> _______________________________________________
> Dcrup mailing list
> Dcrup@ietf.org
> https://www.ietf.org/mailman/listinfo/dcrup
>

-- 

[image: logo for sig file.png]

Bringing Trust to Email

Peter Goldstein | CTO & Co-Founder

peter@valimail.com
+1.415.793.5783