[ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?

[Jim Fenton]

Earl Hood wrote:

>On August 18, 2005 at 09:57, Douglas Otis wrote:
>
>  
>
>>1- Employs DKIM
>>2- Employs DKIM universally
>>3- Allows TP signing
>>4- Allows sub-domain TP signing
>>5- Disallows all TP signing
>>6- Never sends email
>>
>>It would seem counter productive to for assertion 5 to be the default  
>>taken as this would greatly discourage larger ISP from universally  
>>signing all outbound mail.
>>    
>>
>
>Why sign messages when there will be no value in doing so?
>
>The OA is important here, and automatically signing messages without
>explicit permission from the OA is not playing nice.
>  
>
They might be "not playing nice" or they might just be naive.  Maybe 
they weren't able to get an answer from the OA domain and wanted to 
forward the message anyway rather than queue it -- actually, sending 
lots of mail from an OA domain with non-responsive SSP servers might be 
an interesting attack.

The question is whether out-of-policy signatures (e.g., disallowed 
third-party signatures) are considered indicative of an attack or just 
irrelevant.  The same for broken (invalid) signatures.  Hopefully we 
wouldn't have a situation where a message with a broken out-of-policy 
signature is considered "better" than a message with an out-of-policy 
signature that is intact!

My preference is just to ignore broken and out-of-policy signatures as 
if they weren't there at all.

>Except, if DKIM signatures were not limited to OA SSP binding, then an
>ISP could blindly sign messages, making the assertion, "this what I
>got before I sent it out."
>
>Now large ISPs (like Y!) control the domain of their users (the bulk
>of their users are under yahoo.com), so defining the proper SSP records
>(for 1st-party signing) is not more difficult than defining the signer
>public key entries.
>
>For ISPs servicing multiple domains, they should only sign if the
>domain owner allows it, creating a 1st-party signing relationship
>versus a TP one.  Note, domain owner does not necessarily equal
>domain administrator.
>
>(Note, any first-party relationship will probably need to have
> a legal basis.)
>
>IMO, from the OA perspective, enabling TP signing is bad policy from
>a security perspective.  OA will not care if other entities sign a
>message (for traceability purposes) as long as they are not claiming
>a 1st-party association.
>  
>
I'm confused about this paragraph: "enabling TP signing is bad policy" 
but "OA will not care if other entities sign...not claiming a 1st-party 
association".  A third-party signature doesn't claim a first-party 
association, or at least that's my interpretation.  The intent of 
restricting third-party signatures is to prevent messages signed by 
mailing lists and the like (and particularly by attackers posing as 
such) from being considered verified if there isn't also a valid OA 
signature.

>Side Note, I think it would be useful if the OA SSP allowed for
>an OA to designate a list of allowable signers.
>  
>
I'm very concerned about the scalability of the allowable signers list.  
There are circumstances where it would be very long.  The OA domain 
could delegate its _domainkey subdomain, or a subdomain of that, to an 
allowed signer; since these signers are probably people "in the email 
business" (outsourced email services) anyway, they should be able to 
deal with that.

>  
>
>>For those where this would matter, then  
>>making the assertion should be required.
>>    
>>
>
>You are assuming that a domain owner is aware of DKIM.  When DKIM is
>deployed, you cannot require all domain owners to set up SSP records
>immediately.
>  
>
I'm confused about who's saying what, apparently.  I thought you (Earl) 
were advocating a default SSP of "I don't sign anything" which would 
require the SSP to be set up at the same time as the selectors.

>  
>
>>>Exactly.  Are you suggesting that the default should be:
>>>(1) Treat any signature from the OA (example.org) with suspicion, or
>>>(2) Treat any signature on a message from the OA with suspicion ?
>>>
>>>If it's (2), it means that domains that haven't deployed DKIM that  
>>>send through mailing lists to domains that are checking SSP would  
>>>have those messages marked as suspicious.
>>>      
>>>
>>Here the trade-off is rather clear.  The restrictions on TP  
>>signatures is related to combating phishing exploits which affect  
>>only a minority of domains.  The majority of domains should be  
>>willing to allow their messages to be "spoofed" (third-party  
>>signatures) out of sheer convenience.
>>    
>>
>
>There is no "willing" for domains that do not know of DKIM or have
>yet to adopt it.  DKIM must not facilitate spoofing.
>
>  
>
>>Another view would be for the mailing-list to leave all signed  
>>messages intact.  There would then be no added overhead groping for  
>>SSPs.  The mailing-list may adopt a convention where new headers  
>>replace the technique of message modification.
>>    
>>
>
>The List-* headers are well-defined, but many MUAs probably do
>not display them (by default).
>  
>
Right.  If you look at this message, there will be List-Post:, 
List-Archive:, List-Help, etc. headers but it still applies a trailer to 
the body because it will be seen.

-Jim