Re: [ietf-dkim] New DKIM threat analysis draft

On Oct 9, 2005, at 3:39 PM, John Levine wrote:

> The point of the threat analysis is to be able to look at a  
> proposed spec and see whether it addresses the problems it's  
> supposed to address.
...

> I specifically don't want to say anything about signing messages  
> intended for a specific recipient, because that is a problem that  
> existing IETF message signing standards like S/MIME already address  
> pretty well.  If it's there, someone in review will ask why are we  
> revisiting it.  It just adds something else for people to nitpick.
The SSP multi-level authorization mechanism is dependent upon either  
2822.From or Sender in conjunction with either a first-party, first- 
party/third-party, or no DKIM signature and raise similar issues.   
This SSP scheme is based upon DNS registration of the 2822.From  
unless this header contains multiple addresses, then the 2822.Sender  
is used.
This SSP approach changes email conventions by not handling  
2822.Resent* or 2822.Reply-To headers.  In addition, it may not  
always be obvious when there are multiple addresses.  Some addresses  
could be intentionally invalid or may have invisible pretty names to  
confuse recipients as to which header is significant.  The priority  
scheme itself may also confuse the recipient simply by changing basic  
assumptions, and then conditionally changing them again. : (
A simpler assertions could be made within the message signature  
header that could be reinforced by a server related assertion.  There  
will need to be separate server verifications to provide requisite  
DoS protections, but there could also be a scheme that captures  
message based assertions to minimize other communication overhead  
that is also likely much less secure.
Assertions made by the message or the server:
 a) Domain always sign their own email (as based upon email  
conventions.)
 b) Other domains are not authorized to resend this domain.

For 'a', header selection would be left to standard email conventions  
to ensure compatibly and minimize possible service disruptions.  For  
'b', to abate phishing attacks with commerce related emails, disallow  
other domains signing messages that include _any_ headers related to  
a message's origination which contains a domain requesting this added  
protection.  This 'b' assertion SHOULD encompass the 2822.Resent-*,  
Sender, From, Reply-To, and 2821.MAILFROM to prevent _all_ possible  
exploits by non-signed or third-party signers.
There is little value asserting a domain _may_ sign their message,  
when a server verification would offer far greater value.   
Conventions for header use should remain unchanged.  The SSP header  
selection approach, in addition to creating possible exploits,  
conflicting with email conventions, replicating S/MIME and OpenPGP  
efforts, also introduces a possibility that administrative  
accountability could be shifted to the mailbox-domain owner.  The  
mailbox-domain owner could be coerced into providing authorization  
when the authorization mechanism is extended to include a list of  
third-party domains.  More positive anti-phishing protections would  
be provided by simply removing authorization for use of any  
_possible_ originating header from non-signed or third-party signer  
sources.  Keep it simple and close the door on burden shifting.
By holding email administrators accountable with DKIM signature and  
some form of reputation, there can be an assumption that those  
signing messages remain diligent at removing abusive accounts and  
revoking the related messages.  With that in place, there is no need  
to look beyond the signing domain when deciding whether to accept a  
message.  In the majority of cases there is no need to examine  
headers once the signer has been verified and their history has been  
checked.  To satisfy option 'b', the recipient or filters may wish to  
retain a list of those domains that have precluded their use in non- 
signed or third-party signed email.
---


The threat analysis only mentions there could be DoS attacks.   
Reputation in conjunction with a verified identifier forms the basis  
of DoS protections.  Just as with DoS protections, provisions to  
ensure reputation can be protected must not be seen as optional.
Without an ability to defend servers and protect reputation, little  
in the way of protection can be provided by the DKIM mechanism.  The  
scheme suggested by Earl and raised again by Amir may provide a means  
to mitigate revocation checks.  If DKIM adopts conventions for server  
verification for DoS protections, then 2821.RCPT TO mitigation would  
not be needed.  Server verification could mitigate the need to do  
revocation checks.  An ability to mitigate revocation checks offers  
added justification for DKIM over S/MIME or OpenPGP.  When a  
revocation mechanism is added, the responsiveness of DKIM to abuse  
could then be much faster without incurring absorbent overhead.  This  
responsiveness would also make DKIM more effective at abating all  
forms of abuses.
-Doug


_______________________________________________
ietf-dkim mailing list
http://dkim.org