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

From: "Hector Santos" <[email-masked]>
Date: Tue, 8 Aug 2006 21:36:00 -0400

| 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.

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.

I used the example of a Bank using DKIM for its user e-Banking needs. The
user signs up, and the bank gets the user's email address.  The bank runs a
quick check to see if the email address is

    a) DKIM verifier ready,
    b) Highest Hashing Security available.

If not, it might offer the user a special DKIM secured email address maybe
from another DKIM vendor (business opportunity).

Think about it from a company policy liability standpoint.

If a high-value domain is going to now have a new borderline legal
responsibility by simply implementing DKIM as part of it signature process,
it would be prudent that it will take some measure to increase the
survivability, the strength of the "highly private" email communication with
the user where there is a high expectation or desirability for no failure.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Wed, 9 Aug 2006 10:43:58 -0700

On Aug 8, 2006, at 6:36 PM, Hector Santos wrote:

> 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

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 9 Aug 2006 14:43:17 -0400

----- Original Message -----
From: "Douglas Otis" <[email-masked]>
To: "Hector Santos" <[email-masked]>

> 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.  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.

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.

> cause important messages, where added security matters, to be lost or

For this particular item,  how so?  An example of an exploit would be nice.

> 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.

I just need to see why it won't work.

---
HLS

---

From: Douglas Otis <[email-masked]>
Date: Wed, 9 Aug 2006 16:13:38 -0700

On Aug 9, 2006, at 11:43 AM, Hector Santos wrote:
>> 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.
>

A message using "strict" policy is sent to [email-masked] 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-masked], 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 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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Aug 2006 00:43:54 +0100

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:
>>> message.
> 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.
> 
> 
> 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.
>>>
>> 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
>