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

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.

Therefore, we can have no future proofing. All talk of future proofing is
pointless because we cannot future proof for this event until we AT LEAST
can move to category 3 instead of 4. And to move to category 3, we need to
be able to specify something that explicitly addresses the future event.

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.

On Sat, Jul 8, 2017 at 1:08 AM, Jim Fenton <fenton@bluepopcorn.net> wrote:

> On Jul 7, 2017, at 4:24 PM, Salz, Rich <rsalz@akamai.com> 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
> Dcrup@ietf.org
> https://www.ietf.org/mailman/listinfo/dcrup
>