----- Original Message -----
From: "Earl Hood" <earl(_at_)earlhood(_dot_)com>
To: "IETF-DKIM" <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Sunday, November 06, 2005 3:51 PM
Subject: Re: [ietf-dkim] DKIM h= tag - Defauilt or required headers?
On November 5, 2005 at 16:22, "Hector Santos" wrote:
I thought I have read somewhere a few months back that the
default list of
signing headers is all headers, but I don't seem to find this reading.
Maybe I just assumed it.
See Section 5.4 of the latest draft. It specifies what must be
included. "All headers" is not the default.
I don't see or read "what must" be included. Only suggestions.
There are two parts here:
1) Good Actors
2) Bad Actors
1) For good actors, expected behavior should be non-issue.
Based on what I see, it says:
The signed header fields SHOULD also include the
Subject and Date header fields as well as all MIME header fields.
Signers SHOULD NOT sign an existing header field likely to be
legitimately modified or removed in transit. In particular,
[RFC2821] explicitly permits modification or removal of the "Return-
Path" header field in transit. Signers MAY include any other header
fields present at the time of signing at the discretion of the
signer. It is RECOMMENDED that all other existing, non-repeatable
header fields be signed.
There is no MUST here, there is a SHOULD and RECOMMENDATION. There
is no default consideration when the h= tag is empty. e.g., "h=;"
The only MUST is with:
Signers MUST sign any header fields that the signers wish to have the
verifiers treat as trusted. Put another way, verifiers MAY treat
and this is still left as a subjective consideration, opening up threat
entry points.
I guess the closest thing to a default is the informative implementator's
note:
INFORMATIVE IMPLEMENTER'S NOTE: Although not required by this
specification, all end-user visible header fields should be signed
to avoid possible "indirect spamming."
In my opinion, based on the common denominator of all mail systems in the
annals of earth-based telecommunications, the default is required and it
should be:
For OA signing:
From:
To:
Subject:
Date:
This corresponds to the implementator note of (current, common denominator)
visible fields.
For 3rd party signing:
Sender:
From: <---- MAYBE see below
To:
Subject:
Date:
About 3PS From: header, I would like to hear input here without out of scope
distractions (i.e., Opaque-Identifier).
Also, by using a default, there would less mail bandwidth, not a big
deal, but nonetheless, less signature footprint.
2) For Bad Actor, possible threats are what?
The key is what arrangements make a signature weak. What would be algorithm
loopholes? What if the bad actor used a null tag, "h=;" ? How should the
verifier react?
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
ietf-dkim mailing list
http://dkim.org