ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] [Fwd: I-D ACTION:draft-fenton-dkim-threats-02.txt]

2006-01-16 11:28:50

On Jan 15, 2006, at 1:40 PM, Jim Fenton wrote:

Douglas Otis wrote:
On Thu, 2006-01-12 at 16:49 -0800, Jim Fenton wrote:

The signature itself proclaims the role of being accountable for the message. A signing-domain matching the domain of some email- address does not mean the signing-domain has verified permissions for the email-address. In addition, the 'i=' parameter does not need to exist or match any email-address. When the 'i=' parameter does match some address, reliance upon this parameter must be conditioned upon whether the key is delegated, and whether the header is included within the signature.

I'm not sure how one tells that the key is delegated, nor why that is relevant to the verifier.

With DKIM and SSP, the verifier has few reliable elements of information beyond the verification of the signature. When a key has been delegated, additional elements within the signature itself are therefore less reliable. There is no clear indication within DKIM when this information is or is not reliable. There is not even a strong statement the 'i=' element should be used.


SSP adds the ability to provide some advice on what to do about unsigned messages. It doesn't authorize anything -- depending on the policy, it may determine that certain messages are "suspicious". It never makes a positive assertion. A "signs some" policy is the same as not having SSP at all; the other policies are more restrictive.


This is really a matter of semantics. The glass half full or empty, or in this case, affirmed acceptable (authorized) or not.

When the signing-domain matches the email-address domain, the SSP record plays no role. The SSP record may affirm that the message is still acceptable when the email-address domain owner approves the lack of signatures or the signatures of foreign domains.

I basically agree. It's a fine point, but what the email-address domain is actually doing is describing its practices, since it doesn't have any standing to approve anything for the verifier.

A domain does have the standing to proclaim messages using email- addresses within their domain will not always include their signature, an open-ended policy. This proclamation could be called any number of things. Even when restricted to semantics of actions rather than authorizations or affirmations for these types of messages, the same information is conveyed. I agree _how_ this information gets used is well beyond the control of the sender. As such, publishing closed policies offers _less_ risk of being block- listed than publishing open-ended policies. Fortunately, DKIM should not require the use of open-ended policies.

There are no protective benefits obtained publishing open-ended policies. The crux of the concern appears to be whether there is any risk of being held culpable for the abuse permitted when publishing an open-ended policy. The basis for this concern only requires that verifiers increase the ratings of messages when a policy is obtained for an email-address. This is not inconceivable, and is perhaps even likely, as there are major providers already making this type of assessment. Not allowing the publishing of open-ended policies by design better ensures this type of coercion (holding the email- address domain owner culpable rather than the signing-domain) is avoided.


It is rather meaningless to offer such policy distinction. A bad actor can sign messages. If the message goes through a mediator, the signature could be damaged and thus considered to not exist. This policy makes little sense.

This is a good topic for discussion when we are discussing SSP itself, not the threats document.

This statement was directed specifically to the purported purpose of an open-ended policy, as compared to risks publishing open-ended policies. Allowing the publishing of open-ended policies makes it far more difficult to ensure a major domain will not take advantage of this lowered threshold and increase the ratings for a message when any type of policy is found. The risks related to this possible and perhaps even probable behavior should be apparent.

Just as the verifier's behavior can not be predicted, statements related to the protection of an email-address should be equally couched, but they are not.

-Doug

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

<Prev in Thread] Current Thread [Next in Thread>