On Aug 8, 2006, at 6:36 PM, Hector Santos wrote:
| 10. [PROVISIONAL] A domain holder MUST be able to publish a
Practice
| which enumerates the acceptable cryptographic algorithms for
| signatures purportedly from that domain.
|
| [INFORMATIVE NOTE: this is to counter a bid down attack; some
| comments indicated that this need only be done if the
| algorithm was considered suspect by the receiver; I'm not
| sure that I've captured that nuance correctly]
My input:
This is a implementation and "Product Feature" concept.
Having this available will offer implementations the ability for
DKIM domains to predetermine the failure or survivability of a
message being send to a target. It also allows for any need for a
domain to explore and offer new more secure hashing methods.
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. Mechanisms generally needed for compatibility MUST NOT be
excluded in response to a verifier's policy assertion of supported
mechanisms. The exclusion of these mechanisms by the signing domain
may result in messages being lost or rejected at subsequent domains.
This may create a exploitable conflict for generating bounces, or may
cause important messages, where added security matters, to be lost or
rejected.
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. A
practical method for preventing a bid down attack that is compatible
with SMTP would be for the signer (not the verifier) to assert the
deprecated mechanism. This signer information can be combined with
either the deprecated key or other signer related policy assertions.
A message could then safely offer both deprecated and non-deprecated
signatures, where the deprecated mechanism can be avoided once the
final verifier supports the non-deprecated mechanism. Where this
might matter would likely be for a signer that represents a financial
enterprise issuing transactional messages. The criticality of the
required protection will be known by this signer long before most
verifiers have upgraded. By the signer indicating what is
deprecated, adopters of a new mechanism obtain protection during what
is likely a fairly prolonged period. A moderate percentage of lost
or rejected messages will prevent a deprecated mechanism from not
being offered.
The WG however has decided that avoiding a bid-down attack does not
represent a problem that the WG needs to currently consider. A mode
of operation for excluding a deprecated mechanism has not been
defined by the DKIM-base. Until such time when the WG decides that a
mechanism is needed to avoid a bid-down attack, inclusion of
information related to this problem should be excluded from a policy
assertion. In addition to be a scheme for avoiding a bid down
attack, assertions of acceptable mechanisms by the verifier are not
consistent with the general architecture of SMTP.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
