|
Re: [ietf-dkim] Re: Associated Signatures
2008-01-24 13:20:10
On Jan 24, 2008, at 4:36 AM, Charles Lindsey wrote:
On Wed, 23 Jan 2008 19:44:47 -0000, Douglas Otis <dotis(_at_)mail-
abuse.org> wrote:
On Jan 23, 2008, at 4:51 AM, Charles Lindsey wrote:
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.
I do not agree with a local-part exclusion.
DKIM-Signature: i=admin(_at_)example(_dot_)com d=example.com ... (no g= parameter
in key)
Sender: Tom Smith <admin(_at_)example(_dot_)com>
From: Will Jones <W(_dot_)Jones(_at_)eng(_dot_)example(_dot_)com>
This signature indicates the message is compliant with example.com's
signing policy. There should be no reason for a recipient to check
example.com's SSP record. If they did and it indicated an assertion
of "all" or "strict", this message should be considered complaint.
Inspection of this signature also indicates which entity introduced
the message. Matching this identity with the header might lead
recipient's to conclude Tom Smith introduced the message as a Sender
on behalf of Will Jones <W(_dot_)Jones(_at_)eng(_dot_)example(_dot_)com>, but this header
MUST be included within the signature's hash before reaching that
conclusion.
When highlighting whether a message is signed, and by whom, this
highlighting should be limited to information included within the
signature's hash. The signature's coverage with respect to From
header compliance should also consider the g= and t= parameter when
signing for other identities not within the From header.
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.
Agreed.
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).
I do not agree. It seems reasonable to limit SSP compliance to only
the From email-addresses. However, unrestricted signatures for other
headers must also be considered proof of policy compliance. SSP
definitions must reflect the concept that a signature _defines_ the
signer's policy.
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.
This might depend upon the level of email being handled. Expecting a
process to discover SSP records for an unlimited number of domains is
not safe for the receiver or potential targets of the transactions.
The resulting overhead is more than able to result in a denial of
service.
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.
When ebay signs a message containing Sender: somebody(_at_)ebay and happens
to contain a From also within their domain, then this message (with
the possible exception of g= t=s key parameters) must be considered
complaint. The protection being sought is for the From header. If
you feel it is important to also protect the Sender header, that is
your prerogative. A view that the domain of the signature provides
compliance works for any header. Including the Sender header will
significantly increase the number of SSP discoveries needed to support
protection of From and Sender headers since most messages are not
signed.
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?
The number of Sender headers found in messages has increased due to
the use of the PRA algorithm. There will be a large number of
messages containing different domains in the From and the Sender
header. Protection of the Sender header separately from that of the
From requires an increase of SSP discovery. Is that increase worth
doing? What abuse would it prevent?
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.
This view can result in a significant amount of targeted traffic. 10
would represent a network amplification that might be seen with many
other types of attack.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
|
|