Douglas Otis wrote:
This chart also needs to be updated...
I'm trying not to have the SSP design discussion yet. While I like the
chart in general, I'm not sure I agree with all of the entries in it
either. I don't think it's necessary to correct it in order to have the
threat analysis discussion.
It's true that there is no reporting address associated with the
signer (there is the n= (notes) field in the key record, but no
guidance about putting a reporting address there). That is perhaps
something that should be added; do you think it belongs in the key
record or in the signature itself?'
Perhaps it would make sense to establish a convention, DKIM-
POSTMASTER@ perhaps. If this seems too rigid, perhaps an entry in
the key, but this makes the key even larger. Adding the reporting
address within the header could be problematic for delegated keys.
Good point here: If it's important that the domain owner control the
reporting address so that the user of a delegated key can't specify any
reporting address they want, then it needs to be in the key record
rather than the signature. But let's defer that decision until we're
actively discussing the -base document. I have asked that this be
tracked as an open issue so that we don't forget.
With respect to the replay issue, I only want to point out that DKIM
does not need to operate in a vacuum. I do not want to tie it to
any other message authentication technology.
Keep in mind there is a header selection conflict between DKIM and
Sender-ID. The conclusion reached more than a year ago, "open-ended"
authorizations are worthless. As the only safe policy to publish is
"closed," this suggests the PRA algorithm should be re-examined,
especially if Sender-ID is considered a means to offer replay
protections. There is also an alternative to the authorization
scheme that offers better protections. CSV and In-Channel checks
could be yet another alternative for message replay abuse. Leave the
email-address domain owner harmless. Only the administrator knows
who is using the email-address.
Let's have this discussion when we're actively discussing SSP.
The "hapless" email-address domain owner has the option of not
publishing a contact address (r= in the SSP is optional).
But the hapless email-address domain owner can not control those
administrators willing to equivocate about source identifiers. The
'r=' suggests this is the entity that is seen as accountable. Not
publishing the SSP record offers more protection than not publishing
an 'r=' parameter.
There are no semantics defined for the r= tag; it is just a "reporting
address" and might not even be a person, so I wouldn't call it accountable.
"DKIM is effective in mitigating against the use of addresses not
controlled by bad actors,..."
This is the portion of the statement that is highly misleading. DKIM
is not effective at mitigating the use of addresses not controlled by
bad actors unless a "closed" authorization is used such as '!' or
'.'. A clarification that a "closed" authorization is not
compatible with many common uses of email would also ensure that
someone reading this would not be dramatically mislead.
I guess it depends on what you consider to be a "mitigation". Note that
it does not say that it prevents the use.
-Jim
_______________________________________________
ietf-dkim mailing list
http://dkim.org