On Feb 20, 2008, at 9:55 PM, Jim Fenton wrote:
Jeff Macdonald wrote:
On Tue, Feb 19, 2008 at 03:04:08AM -0800, Douglas Otis wrote:
Expanding upon the effect of the SSP-02 Author Signature
definition based upon a conversation with Jim...
Jim suggested that to comply with SSP-02, signatures will not make
use of the i= parameter, since the i= parameter is needed only
for g= restricted keys.
Is that really true? I thought one could use i= in cases like so:
d=bar.org
i=(_at_)foo(_dot_)bar(_dot_)org
I didn't think g= was needed in that case.
Including the local-part is only required for g= restricted keys,
where often the default of "i=@<d=domain>" is likely to be used. A
signature is not valid when the key is domain restricted, and the
domain of the identity is within a sub-domain, which should make this
case moot.
I was misunderstood here. A local part on i= is REQUIRED if the
signing key is "restricted" through use of a g= parameter other than
*. i= can be used at other times and for other things as well, as
you point out. In the example you gave, i=(_at_)foo(_dot_)bar(_dot_)org
would result
in an Author Signature when the Author Address on the message is
something like jdoe(_at_)foo(_dot_)bar(_dot_)org(_dot_)
Although excluding the local-part from the i= parameter is possible,
the identify of who introduced the message becomes ambiguous. For
example:
Sender: sdoe(_at_)foo(_dot_)bar(_dot_)org
From: jdoe(_at_)foo(_dot_)bar(_dot_)org
Dkim-signature: d=bar.org i=foo.bar.org (SSP-02 compliant with "all")
A perfectly valid signature identifying sdoe(_at_)foo(_dot_)bar(_dot_)org as
introducing the message (per RFC 4871 definition where i= indicates on
who's behalf the signature was added) would not be compliant with an
SSP-02 assertion of "all"!
Sender: sdoe(_at_)foo(_dot_)bar(_dot_)org
From: jdoe(_at_)foo(_dot_)bar(_dot_)org
Dkim-signature: d=bar.org i=sdoe(_at_)foo(_dot_)bar(_dot_)org (SSP-02
non-compliant
with "all")
The SSP-02 Author-Signature definition _requires_ use of an
"ambiguous" signature in these rather common cases. So when the
signing domain wishes to ensure clarity in who introduced the message,
it must add an additional signature for the same message. To defend
against signature removal, the explicit signature needs to be included
within the ambiguous signature, or, to ensure walking up the header
stack does not lead to confusion when lacking the explicit signature,
empty Sender, Resent-* headers must be listed to preclude their use.
The preclusion of headers when using a single signature will prevent
practices that might have been able to preserve the original
signature. A potential for confusion results in the SSP-02
requirement that the "Author Signature" MUST specifically identify the
From header address, or MUST BE ambiguous about the local-part. This
SSP-02 definition is attempting to ensure those using g= restricted
keys are unable to sign compliant messages where the identity is not
included within the From header.
SSP-02 would be a better specification and would create fewer problems
by adding a non-normative statement that messages signed with local-
part restricted keys where the identity is not within the From header
should cause great caution, regardless of the SSP-02 policy
assertions. Would anyone disagree with such advice?
To allow the properly evaluation of results returned by a signature
validation process, the following should be enumerated:
2 bits Signed By: no-one 0
first-party 1
third-party 2
authorized third-party 3 (future)
1 bit local-part restricted, 0 not /1 is
1 bit domain restricted, 0 not/ 1 is
2 bits policy: no policy 0
"all" 1
"repudiate-able" 2
"SMTP disavowed" 3
1 bit TPA policy" 0 not used, 1 used (future)
Instead of a practice that offers an explicit token (even one that
is opaque) identifying the user/agent that introduced the
message, once again examining the header stack and guessing which
header might apply again becomes necessary. It is also unknown
whether the entire header stack will have been captured within
the signatures hash, so this guessing may also be prone to the
introduction of spoofed headers while attempting to resolve top
most identifiers.
Secondly, this also means that MUAs attempting to highlight who
the signature indicates as having introduced the message is also
prone to getting this wrong, because the signature's identity
(i=) MUST BE absent whenever the entity introducing the message
is _not_ represented by the email-addresses within the From
header. : (
Huh?? ASP does not prohibit other signatures, it just provides no
additional information about them.
When the entity is not represented by the From header, to be specific
about on-who's-behalf the signature had been added SSP-02 essentially
requires two signatures be added. Needing two signatures as part of a
normal process adds overhead and complexity, and increases the
difficulty of defending the verification process. There is no
justification for _requiring_ the use of multiple signatures. No
additional information is being added by the SSP-02 compliant
signature. This signature is purely wasted overhead that increases
complexity and risk.
Although unlikely, some domains may feel compelled to sign the
message twice. One signature to comply with the SSP-02 Author
Signature definition, and another to clarify who actually
introduced the message. : (
I think being able to use multiple signatures offers flexibility.
Sure, and doesn't signing the Sender header field clarify who
actually introduced the message, if that's important?
RFC 4871 allows multiple signatures, but these multiple signatures of
the same domain are needed _only_ because SSP-02 requires _less_
information be contained within the policy compliant signature!
As a result, instead of DKIM offering a "reportable" or
"displayable" identifier clarifying who introduced the message,
this identifier must again be guessed. : (
I don't think it really matters who introduced the message. What
really matters is if any of the DKIM identities are recognizable.
Yes, that's the point.
A DKIM signature from the Author Signature's Domain provides a
recognizable identity, the _domain_. Why stipulate the local-part
MUST NOT be included within a signature in order to be SSP-02 Author
Signature compliant when added on-behalf-of the entity represented by
the Sender header? The definition of Author Domain Signature should
allow this type of signature to be compliant.
Jim's example as to why this definition is needed offers yet
another problem with this scheme.
Don't overlook the situation created by Jim's example, that when there
is a desire to ensure the identity on who's behalf the signature is
being added, ambiguous signatures only add to possible confusion when
required these signatures are required to achieve compliance with an
"all" assertion. Wandering up the header stack when only one
signature is used increases the likelihood of this identification
process becoming prone to spoofing.
<snip>
Recommendation:
1) Change "Author Signature" to "Author Domain Signature".
2) Change "Author Signing Policy" to "Author Domain Signing Policy".
3) Accept the premise that when the "Author Domain" signs the
message, the message is complaint with the "Author Domain's
Signing Policy" _by definition_.
4) Only when the message is not signed by the "Author Domain", is
the "Author Domain Signing Policy" in need of checking.
These seem reasonable to me, but I don't know if we need to be that
fine grained.
Just because the signing policy is expressed only at the domain
level doesn't mean that the definition of Author Signature must also
be at exactly the same level of granularity. So an Author Domain
Signing Policy can still deal with Author Signatures.
Compliance with your definition of Author Signature, when signing on
behalf of an entity not within the From header, requires the
signature's identity be falsified, or to remain ambiguous. Forcing
use of falsified or ambiguous signatures potentially enables
exploitations, as the verifier/MUAs may attempt to guess the most
likely identity. These identities that may not have been included
within the signature's hash as well, as this is not required.
Requiring two signatures be added in a specific order to retrain a
secure indication of the i= parameter makes no sense. This
requirement only exposes the process to additional risks. Verifiers
will not have any trouble assessing the level of risk associated with
a local-part restricted key where this identity is not found within
the From header. Policy is not needed to identify this type of
signature as being risky. The Author Signature is being overly
restrictive as it precludes a signature from containing essential
information.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html