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>
|
- Re: [ietf-dkim] [Fwd: I-D ACTION:draft-fenton-dkim-threats-02.txt], (continued)
- Re: [ietf-dkim] [Fwd: I-D ACTION:draft-fenton-dkim-threats-02.txt], Eliot Lear
- Re: [ietf-dkim] [Fwd: I-D ACTION:draft-fenton-dkim-threats-02.txt], Michael Thomas
- Re: [ietf-dkim] [Fwd: I-D ACTION:draft-fenton-dkim-threats-02.txt], Douglas Otis
- Re: [ietf-dkim] [Fwd: I-D ACTION:draft-fenton-dkim-threats-02.txt], Douglas Otis
- Re: [ietf-dkim] [Fwd: I-D ACTION:draft-fenton-dkim-threats-02.txt], Stephen Farrell
- Re: [ietf-dkim] [Fwd: I-D ACTION:draft-fenton-dkim-threats-02.txt], Jim Fenton
- Re: [ietf-dkim] [Fwd: I-D ACTION:draft-fenton-dkim-threats-02.txt], Douglas Otis
- Re: [ietf-dkim] [Fwd: I-D ACTION:draft-fenton-dkim-threats-02.txt], Jim Fenton
- Re: [ietf-dkim] [Fwd: I-D ACTION:draft-fenton-dkim-threats-02.txt],
Douglas Otis <=
- Re: [ietf-dkim] [Fwd: I-D ACTION:draft-fenton-dkim-threats-02.txt], Arvel Hathcock
- Re: [ietf-dkim] [Fwd: I-D ACTION:draft-fenton-dkim-threats-02.txt], Douglas Otis
- Re: [ietf-dkim] [Fwd: I-D ACTION:draft-fenton-dkim-threats-02.txt], Stephen Farrell
- Re: [ietf-dkim] [Fwd: I-D ACTION:draft-fenton-dkim-threats-02.txt], Douglas Otis
- [ietf-dkim] open-ended threats (was: [Fwd: I-D ACTION:draft-fenton-dkim-threats-02.txt]), Frank Ellermann
- Re: [ietf-dkim] open-ended threats (was: [Fwd: I-D ACTION:draft-fenton-dkim-threats-02.txt]), Douglas Otis
- Re: [ietf-dkim] [Fwd: I-D ACTION:draft-fenton-dkim-threats-02.txt], Stephen Farrell
- Re: [ietf-dkim] [Fwd: I-D ACTION:draft-fenton-dkim-threats-02.txt], Douglas Otis
- Re: [ietf-dkim] [Fwd: I-D ACTION:draft-fenton-dkim-threats-02.txt], Stephen Farrell
- Re: [ietf-dkim] [Fwd: I-D ACTION:draft-fenton-dkim-threats-02.txt], Jeff Macdonald
|
|
|