On Jan 9, 2006, at 10:45 AM, Stephen Farrell wrote:
Doug,
Douglas Otis wrote:
In several places within the current draft, declarations of
benefits assume a particular extension, SSP. The benefits,
related limitations, caveats, and extension specific threats
should be placed into separate sections. The list of _possible_
extensions should not be limited to just that currently defined
in SSP.
While I'm not sure I agree with your list (its too long for a
start), I do think that the less that the threats document assumes
about ssp, the better it'll be. So structuring it so as to be vague
in respect of ssp may be the right thing to do.
The general sections should be vague (make no assumptions of
benefits, etc), but a section specific to a range of options that
would fall under the general SSP email-address authorization scheme
should be mentioned there.
I also agree that the list of possible extensions should not be
limited so ssp-only, but I do not agree (if you're saying so) that
the document has to treat each potential extension equally.
The long list was to indicate the many possible uses of the base DKIM
signature. Compiling the list of positive and negative aspects of
these various choices could help select/justify the final choice(s).
There should not be any need to treat each option equally, as some
will have disqualifying aspects which preclude any further exploration.
I think the wg should guide the author on the level of detail, and
there are clearly more than a couple of folks who consider that
something-like-ssp is a fairly criticial extension (yes, I know
there is at least one who thinks the exact opposite:-), and
something-like-ssp was part of the BoF and is part of the charter
so it won't go away just now.
Agreed. This section for email-address authorization could include:
1) Risks associated with the misuse of "open-ended" authorizations.
2) The disruption caused by "closed" authorizations.
3) Possible coercive ratings when not publishing the record.
4) Exploitation of "open-ended" authorization being unfairly
attributed to the mail-address domain owner.
5) Overhead when most records are not present for the email-addresses.
6) Label depth found in abusive email versus legitimate email.
7) Accommodating "closed" policies at the Mediator.
8) Increased overhead checking multiple From addresses. (Defeating 7)
9) Dictionary attacks of local-part authorizations.
10) Unintended DoS for short TTLs with authorizations.
But before anyone starts drafting other extensions, I'd expect that
any other extension proposed would have to fit with the charter and
be addressed in sequence (i.e. earliest after the base is done) and
needs significant enough buy-in from the wg generally. If, for
example, you were to continue to develop your opaque-id ideas
outside the wg and then bring a more mature draft back to the wg
after wg-last-call on the base draft, then you might well get a
much better reception than if you tried to get that work done here
and now. (Or maybe not, I don't know.)
The threat draft should speculate about actions and counter-actions,
so considering a wider range of mechanisms may help flush out
neglected aspects to ensure there are fewer surprises. Of course an
individual writing an extensions draft to explain a mechanism does
not mean this will become a WG draft. Not writing the draft however
would ensure just the opposite.
Consideration should be given with respect to rehabilitating a domain
that has an inordinate number of signed messages being used
abusively. Any avenue where there is no defense will quickly become
a busy highway of abusive traffic.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org