|
Re: [ietf-dkim] Re: Associated Signatures
2008-01-24 05:42:42
On Wed, 23 Jan 2008 19:44:47 -0000, Douglas Otis <dotis(_at_)mail-abuse(_dot_)org>
wrote:
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(_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)?
OK, an address in one of those headers matches the signature iff the
various d=, i= and g= tags so determine according to RFC 4871, taking the
local-part of the address into account if necessary.
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".
Yes, unless there is a g= tag that does not encompass both.
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?
Yes. (The preecise wording to be used in the document would need some
care).
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?
Yes, it should apply to any header which ought not to have escaped outside
the signers boundary without being signed, according to his published SSP.
Our SSP draft would specify exactly which those headers were (and maybe
there would be more tags in the SSP records than we have proposed so far).
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.
NO IT DOESN'T, because we all agree that these cases of multiple different
addresses in the headers mentioned are going to be exceedingly rare. In
99.99% of cases there will be just one From address, the Sender (if
present) will be from the same domain, and there will be no Resent-*
headers at all.
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.
You haven't answered my question. If you see a message with no mention of
Ebay in its From, but with Sender: somebody(_at_)ebay and with no signature
from Ebay (who claim to sign everything leaving their boundary), then how
can that message possibly NOT be bogus? That seems to be a sufficient
reason for saying that 'all'/'strict' ought to include whatever is in the
Sender.
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.
HOW? Do you suppose that the number of outside messages Resent by Ebay
will be more than a tiny fraction of the messages originating within Ebay
itself?
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 number gets big enough that the DNS overhead REALLY really starts
to hurt. If I had to choose one of those numbers to write into our
document as the minimum that SSP owners could reasonably expect to be
accepted, then I would choose "fifty", as being way beyond any normal
usage and still not likely to enable a serious DOS attack on the DNS
system.
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.
Correct. And it would not be compliant according to the rule I have
proposed.
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.
Correct. And it would be compliant according to the rule I have proposed.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131
Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
|
|