Subject: Re: [ietf-dkim] Re: What the verifier can do

From: Tony Hansen <[email-masked]>
Date: Mon, 01 May 2006 09:28:06 -0400

Or bite the bullet now and introduce hh (header hash)? It would act
exactly like bh (body hash), but be a hash of all headers except
dkim-signature. The signing algorithm would then be done over just the
dkim-signature header. This would make the header hash explicitly
present, simple to access, and easier to check against. If you wanted to
do additional heuristics, this is as opposed to getting the hash back as
a side effect of doing the signature verification and having to know
something about how rsa works on the inside.

Which is more confusing? :-) (If we were to hum right now, I'd hum for
making the header hash be explicit.)

	Tony Hansen
	[email-masked]

Eric Rescorla wrote:
> Michael Thomas <[email-masked]> writes:
>> If we ever move to a new signing algorithm that doesn't encrypt
>> like RSA does, it seems like that might be a worthwhile thing to
>> do. As it stands now, we don't have the need so it would probably
>> not do much more than add confusion.
> 
> That's fine, but if we believe that in order to have an operational
> system you're going to need to be able to do signature message 
> recovery in some way, I think that needs to be explicitly stated
> somewhere, not just left silent.

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 1 May 2006 08:52:37 -0700

>making the header hash be explicit.)

I'm fine with either way. I think the chance that we will ever switch 
from an RSA-based signature scheme of some sort is so remote that we 
don't need it, but I agree with Eric that having an explicit hash 
value is cleaner in case we do.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 1 May 2006 13:52:19 -0400

Hi Tony,

The only reason I see for having a hh (header hash tag) is to confirm a
recalculation and offer the difference as a possible failure reason in
reporting, logging, rejection and/or presentation to users (if the verifier
domain wishes to risk to push the failure to end-users).

But why would I want this if the recalculation is suppose to work?

  - Missing h= headers
  - Modified h= headers

The only time anyone should expect modified headers is once a MDA is concept
and the message is being redistributed as in a mailing list.

Missing headers is less of a problem in practice but it is possible also
with a mailing list.   But this is where the signing domain needs to be
prudent and understand not to use headers that are susceptible to change
(e.g., Reply-To:, Subject:).

So the question becomes, suppose we had an hh= header, how does this change
the end result?

What if the recalculated header hash did not match the signer's hh= exposed
hash?

What do you want the verifier to do?

Is it still considered "Invalid" but now we have a REASON?

If so, that is good enough for me, but can't we come to this same reason and
conclusion if the body hash (bh=) is satisfied, but the final signature hash
is not?

  signature = rsa(bh + hh)

if we have the bh= available and it recalculates successfully, and the rsa
fails, then the only logical reason is a failure in the headers.

Anyway, for me, I don't have a problem with extra "information" to work
with, but what is more important to me is what do with the end-result.   It
is really the same issue that we had with the expiration.   What if the
expiration is a true state?  We now watered it down to a MAY be considered
invalid.    Is this the same administrator dominated defined relaxed
heuristic we want for this bh= and possible this new hh= tag errors?

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com