On Mar 27, 2006, at 8:33 AM, Stephen Farrell wrote:
Michael Thomas wrote:
Stephen Farrell wrote:
I think that a number of those in favour have stated their
reasoning, as have you. So I don't think there's a lot that
remains to be said in this particular debate. But if I've missed
something that you reckon still needs a response (quite possible)
then send me a link to the archive.
Yes, here's the message I sent out last week which I haven't
heard a reply from the proposers of this change:
Actually, I thought there'd been a couple of responses to that, in
any case some did discuss some of the issues you list even if no-
one so far has given a blow-by-blow response.
There has been an attempt.
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002823.html
I believe I haven't seen a response to your point that verifiers
will still be waiting for the key and may have hashed the entire
body before the key arrives (I assume the response will be the
obvious "caching" and "signer benefits" points;-)
When a message includes many signatures, fetching keys in parallel
can be mitigated by checking the body hash contained within the
signature header. Without this hash parameter, the value of each of
the multiple signatures to the message is not apparent. The lack of
a hash requires individual signature verification to ascertain
whether the signature is still of value.
A signature could be added by a mailing list after flattening the
message. With the hash of the body included in the header, checking
which signature includes a valid hash can exclude DNS transactions
for already broken signatures. When several signatures include the
same hash value, but incorporate different headers, the value of the
signature clearly relates to the information added to the message via
additional headers. With a potential for network amplification,
fetching keys for all signatures within a message is perilous. The
hash of the message body within the signature enables a means to
better prioritize which signatures are checked.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html