|
[ietf-dkim] Re: Associated Signatures
2008-01-23 12:59:44
On Jan 23, 2008, at 4:51 AM, Charles Lindsey wrote:
On Tue, 22 Jan 2008 19:43:43 -0000, Douglas Otis <dotis(_at_)mail-
abuse.org> wrote:
On Jan 22, 2008, at 3:12 AM, Charles Lindsey wrote:
On Tue, 22 Jan 2008 02:32:28 -0000, Douglas Otis <dotis(_at_)mail-abuse(_dot_)org
> wrote:
1) To be SSP "strict" or "all" compliant, the identity associated
with a signature:
Add:
e) Each entity with a "strict" or "all" SSP within the following
headers
From, Sender, Resent-From, Resent-Sender
must be matched by an associated signature (if, in some
complicated case,
this requires the presence of several signatures, then so be it).
What benefit is derived by imposing an explicit i= parameter
requirement on an originating header for "all" or "strict"
compliance?
I don't know, but what has that got to do with my suggestion above?
You said "an associated signature". It was not clear whether you
meant "associated" using the d= tag ignoring the i= tag, or using the
i= tag (and its default)?
RFC 4871 does not require signatures to identify specific entities,
and may produce ambiguous signatures lacking an i= local-part.
A signature identifies a domain. By implication, it identifies any-
local-part(_at_)that-domain(_dot_)
A signature is allowed to not include the local-part, or might include
the local-part of an email-address within the Sender header that is
within the same domain as that of the From email-address in question.
When the signature fails to include the local-part, the entity
introducing the message remains ambiguous and such signatures do not
identify any-local-part. However, such an ambiguous signature
currently satisfies "strict" compliance. Nonetheless, a signature
associated with the Sender header identifies who introduced the
message, but currently does not satisfy "strict" compliance.
It would seem your agree that a signature on-behalf-of the Sender
within the same domain as the From should satisfy compliance with
either "strict" or "all".
For SSP to impose a requirement that signatures _MUST_ identify
specific entities is beyond the WG charter.
And nobody has suggested any such thing. Please look at my proposed
additional "e)".
You (a verifier) see a bunch of addresses in a bunch of From/Sender/
Resent-From/Resent-Sender headers.
You also see a bunch of valid signatures on behalf of an assortment
of domains.
So you look through the domains that are signed for, and you tick
off all the addresses in all those headers that contain those
domains (well, maybe only for the headers explicitly covered by the
signature, where "From" is alwys covered, of course).
When you said "explicitly covered by the signature, you mean those
those headers included within the signature's hash?
If, when you are done, you have ticked off all the available
addresses, then there is nothing to be suspicious about. But, if any
address has not been ticked, you are entitled to ask "why not?".
You wish to include SSP discovery for any header, rather than just for
those within the From header lacking a signature within a domain at or
above the email-address domain?
So, for each unticked address, you look up the SSP, and if you find
some of them are 'strict' or 'all', then your suspicions are
aroused. What happens next depends on exactly how we define 'all'
and 'strict', including how they apply to the various headers (and
it may depend also upon your local policies and reputations that may
be to hand, but those considerations are beyond our scope).
Checking SSP for all headers might cause an excessive level of SSP
discovery. Excessive SSP discovery increases the overhead related to
DKIM, and increases concerns related to DDoS effects.
As to whether we need to consider all of From/Sender/Resent-From/
Resent-Sender, we can discuss that. But consider, supposing Ebay has
a 'strict' SSP, how could
Sender: somebody(_at_)ebay
legitimately come about and not get signed by Ebay?
This strategy could be done differently, while only focusing upon the
From header email-addresses.
Any valid signature with a domain at or above the email-address domain
contained within the From header removes the need to discover SSP for
that domain. An exception should be made for signatures using a g=
restricted keys. These restricted signatures must be on-behalf-of (i=
tag match) with that of the From header to satisfy "strict" or "all"
compliance. In essence, only the From header email-addresses are
protected by SSP policy.
Or, suppose someone outside sends email to someone(_at_)ebay(_dot_)com who then
decides to resend it to someone outside. How could that NOT get
signed by Ebay on the way out?
This strategy could introduce an inordinate level of SSP discovery.
Conversely, the Sender someone(_at_)ebay(_dot_)biz could be signed by ebay.biz,
but should not satisfy "all" or "strict" compliance with a From of someone(_at_)ebay(_dot_)com
. However, when a signature is on-behalf-of (i= tag match) of the
Sender of someone(_at_)ebay(_dot_)com, then an email-address of someone-else(_at_)ebay(_dot_)com
within the From header should still satisfy "all" or "strict"
compliance where an exception is made only for signatures using g=
restricted keys.
2) SSP references should be done for:
Add:
bb) All From email-addresses PLUS the Sender address, if any
+2
How many From email-addresses should be allowed?
As many as the verifier can be bothered to check. If he sees 1000
From addresses he may assume it is just a DOS attack and discard the
whole message with no further checks.
When should a verifier decide to not discover SSP records? At two,
three, four, twenty, fifty? When the verifier decides there are too
many From email-addresses, the treatment given that message must be
that of an SSP non-compliant message, or this situation becomes a
means to bypass SSP checking. This variable restriction becomes an
unspoken limit that might cause messages to become rejected.
In addition, it would not be hard to place "From" within a folded
Display Name to confuse recipients about the email-address really
being the sixth email-address contained within the From header.
SSP MUST specify a limit or it will cause interchange problems.
What benefit is derived imposing policy for Sender headers?
Would a From header referenced policy override a Sender header
referenced policy?
See my Ebay example above.
Due to MUA displaying the Sender header, this might seem logical.
However, allowing a signature on-behalf-of the Sender header (within
the same domain as that of the From email-address) to satisfy "strict"
or "all" compliance, ebay remains protected when SSP policy is only
checked for email-addresses within the From header.
Currently, a small percentage of emails are signed using DKIM.
Sender header policy requirements substantially increases overhead
related to SSP.
In 99.99% of cases the sender domain will already be in one of the
Froms, so no additional overhead.
It seems there would be little benefit derived by the added overhead.
The From email-addresses are where SSP conflicts are important, and
where signatures are most needed.
3) Keys restricted by a g= parameter are treated as valid and are:
Add:
a) SSP "all" or "strict" compliant only when on-behalf-of a From,
Sender,
Resent-From or Resent-Sender header email address.
Allowing compliance with headers other than From permits a holder
of a g= restricted key to sign a message purporting to be "From"
anyone within the signing domain. ...
Where do you get that? Please provide an example.
Example 1:
Sender: ads-r-us(_at_)ebay(_dot_)com (i=ads-r-us, g=ads-r-us restricted key)
From: customer-service(_at_)ebay(_dot_)com
Subject: Account information requested
This should not be "strict" or "all" compliant.
While ads-r-us(_at_)ebay(_dot_)com would be a valid signature from ebay, g=
restricting keys was an attempt to avoid local-part abuse. When just
the domain of signature is considered significant to handle cases like:
Example 2:
Sender: admin(_at_)ebay(_dot_)com (i=admin, unrestricted key)
From: general-manager(_at_)ebay(_dot_)com
Subject: New holiday hours
This must be "strict" or "all" compliant. Otherwise, the signature
would need to remain ambiguous about who introduced the message, or
need to falsify a signature containing i=general-manager.
Unrestricted keys MUST BE controlled by systems that assure compliance
with the domain's signing policy. It would be illogical and wasteful
to require verifiers to discovery SSP for ebay.com and check whether
Example 2 is compliant. ebay MUST control which messages they sign
using unrestricted keys.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
|
|