Doug,
Too many words, and trending away from resolution of pretty
much anything. I suggest you try to come to agreement between
yourselves offlist, and then share your conclusions afterwards,
Thanks,
Stephen.
Douglas Otis wrote:
On Aug 9, 2006, at 11:43 AM, Hector Santos wrote:
From: "Douglas Otis" <dotis(_at_)mail-abuse(_dot_)org>
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 jon(_dot_)doe(_at_)example(_dot_)com 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 little-jon(_at_)merry-men(_dot_)com, 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
tohttp://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html