On Aug 9, 2006, at 11:43 AM, Hector Santos wrote:
From: "Douglas Otis" <[EMAIL PROTECTED]>
SMTP is not an end-to-end protocol. The store-and-forward feature
of SMTP means _any_ email-address may not be the final destination
for a message.
As far as the initial author concern it is.
No. The author does not know where the final verifier resides, or
where signature verification and policy might ultimately be applied.
When the author sends a message using SMTP, it should be well
understood the email-address used to initiate delivery may have no
direct relationship with where the message is ultimately destine.
You are referring to a relay forwarding of an email address to
another address. But to get to this node, the initial path did
reach its destination. The author had no clue that a forwarding of
the address would be taken place.
A verifier may be located in both MUAs and MTAs that forward
messages. For the very reason that the author has "no clue" would be
the reason that removal of a mechanism commonly essential for assured
DKIM verification may create significant problems.
Same wave length?
If so, a DKIM verify domain who would be receiving an email
targeted for its MDA would verify the message, and need be, then
forward it hopefully to another DKIM ready domain.
"DKIM ready" will not remain a static definition. Avoiding a
deprecated mechanism when possible is the goal of an anti-bid-down
mechanism. When a signing domain creates a policy fostering an
expectation that all messages have valid DKIM signatures, this
necessitates including signatures with mechanisms a DKIM verifier is
commonly expected to support. There is no reasonable way within SMTP
to negotiate with the ultimate destination. The signing domain
however may warn what signature should and should not be used. Don't
expect that the final verifier is able to indicate what it supports
or that this information would be useful for avoiding the bid-down.
This may create a exploitable conflict for generating bounces, or
may cause important messages, where added security matters, to be
lost or rejected.
For this particular item, how so? An example of an exploit would
be nice.
A message using "strict" policy is sent to [EMAIL PROTECTED] that
publishes a "verifier" policy indicating SHA-256 is supported. The
message is then signed using only SHA-256. When the message gets
forwarded to [EMAIL PROTECTED], that domain only handles the
required SHA-1. The "strict" policy is noticed, the message is not
considered signed, and it is bounced. A bad actor finds that
example.com publishes an ability to handle SHA-256 signatures and is
known for forwarding email-addresses discovered using exploratory
attacks with bounces to a covert address.
A bounce may cause any signature to become invalid. To make the
message interesting, an invalid signature might be added to appear to
be from the bounce victim's domain. There is no requirement a DKIM
signing domain have the same domain as that of the 2821.MAIL_FROM, or
that invalid signatures be removed. Example.com found a valid
signature, and merry-men.com trusted example.com. An anti-bid-down
mechanism can not depend upon the signer acting reliably in response
to a "verifier" policy.
I personally see this as a "highly desirable" feature that would
add a few stars to a software package. I also see this as
something very desirable in a social, vendor or business network.
The final destination of a message must be considered unknown.
See above.
I am not sure Doug if you were describing a new solution or
explaining why it won't work.
A reasonable solution would be for the signing domain to indicate
what should and should not be used when they offer multiple
signatures. If you want to trust your financial institution's
signature, follow their advice about which is the better signature.
When your verifier does not support their recommended signature,
annotate the message and look to upgrade. The verifier on its own
can not know the signer's capabilities for deciding whether a
deprecated mechanism is the best that should be expected from a
domain. This problem should be handled correctly rather than handled
in the manner you are suggesting. Do it right, or don't do it. The
only reason for considering an anti-bid-down mechanism would be to
define how this mechanism could be used in the future. It is my
understanding that the WG has concluded that solutions for the bid-
down attack are not to be considered at this time.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
