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

[Eric Rescorla <[e-mail]>]

On Sun, Jul 9, 2017 at 7:21 PM, denis bider <[e-mail]>
wrote:

> We can break down the following levels of future proofing:
>
> (1) Future event occurs, and no changes are needed by anyone. The event is
> already accounted for by configurations, implementations, and
> specifications.
>
> (2) Future event occurs, and changes are needed to configurations. The
> event is already accounted for by implementations and specifications.
>
> (3) Future event occurs, and changes are needed to implementations, which
> must then be deployed. The event is already accounted for by specifications.
>
> (4) Future event occurs, and changes are needed to specifications, which
> must then be implemented and deployed. The event is not accounted for.
>
> In this case, when we're talking about "future proofing", we are dealing
> with category (4). We cannot do (1), (2), or (3) because although we know
> what the future event might be (quantum computing), we do not have a
> solution we can specify at this time.
>

Actually, this isn't entirely true. We could presumably deploy hash
signatures, they're just not very efficient. In fact, the one thing that we
do know with high probability about any PQ algorithm is that it is likely
to be less efficient than the existing algorithms, and one of the ways in
which it might be less efficient is large public keys, in which case having
hashes will be useful.

Moreover, QC isn't the only possible event that could cause us to wish to
have larger keys. There might be a modest improvement in dlog that would
make Curve25519 problematic but Curve448 or P-521 comfortable (indeed, this
is how we got to the point where we wish to have RSA keys > 1024).


Requiring fingerprints for ECDSA or EdDSA does nothing for future proofing.
> If the future event occurs, we will still be dealing with a category 4
> event that requires new specifications, new implementations, and new
> deployments. No work will be spared.
>

I don't agree with this for the reasons above.

-Ekr


>
>
> On Sat, Jul 8, 2017 at 1:08 AM, Jim Fenton <[e-mail]> wrote:
>
>> On Jul 7, 2017, at 4:24 PM, Salz, Rich <[e-mail]> wrote:
>>
>> >> For what it's worth, I agree with Jim and Ekr. Hashing is just fine.
>> >
>> > Is it fine, or is it a required or just good?
>> >
>> > Nobody is saying there is anything wrong with hashing.  Several are
>> saying that, given the limitations of some DNS deployments, it is useful to
>> avoid the indirection and just put the key when we can.
>>
>> What DNS deployment limitation would be adversely affected by the use of
>> a hash? I can't think of any.
>>
>> "Avoid the indirection" makes it sound like more network round-trips
>> would be required if a hash is used. No more network traffic is involved;
>> the verifier only needs to compute the hash of the key included in the
>> message and compare that with the fingerprint included in the key lookup
>> response from DNS. The verifier can even check the signature prior to
>> receiving the DNS response, if it wants.
>>
>> I'm supporting publishing key fingerprints because I think it's slightly
>> more future-proof, and having been burned by that once already, I don't
>> want to make the same mistake again. But if rough consensus decides
>> otherwise, we go with that of course.
>>
>> I still haven't heard an answer to the following question I posed about
>> the fingerprints, though: Will the fingerprints always be sha256, or do we
>> need to specify the fingerprint algorithm in the DNS record? In other
>> words, will we assume that sha256 will be strong enough for the life of
>> this protocol?
>>
>> -Jim
>> _______________________________________________
>> Dcrup mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dcrup
>>
>
>