[ietf-dkim] issue: requirement #10 Publishing Hashing (cryptographic algorithms) methods...

[Douglas Otis]

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