On Jan 9, 2006, at 12:19 AM, Stephen Farrell wrote:
Unless there's a very strong consensus in that direction, I'd
really rather not deviate from the charter before its even been
posted on the IETF web site.
Let's try to work the current draft so that its in shape for a
wg last-call by the end of next month.
In that case, there could be greater clarity provided in the threat
draft by creating separate sections splitting out threats and
purported benefits related to mechanisms that extend the base DKIM
signature.
There could be extension sections that speculate on:
1) email-address based authorization
a) first From
b) multiple From
c) Purported Responsible Address
d) Return-Path
e) role-based (MSA/MUA, Mediator, MDA/MUA)
2) abusive replay abatement
a) Per-user keys
b) O-ID
c) signature reputations
d) call-back validation
e) in-channel checks
f) path registration
g) key vectored aggregated revocation record (per OpenPGP)
i. Assumes application vs DNS caching of user-keys
ii. Assumes revocation record has short TTL
3) email-address assurances (bindings)
a) always signed
b) verified local-part
c) verified address
d) account unique O-ID
e) assurance verification
4) Multiple signature handling
a) Signing roles
b) Header/Role relationships
c) MDA signatures to mitigate replay sources
5) DoS strategies
a) use of EHLO (Also 2e)
b) use of remote IP
c) maximal limit of signatures
6) Filter strategies
a) use of signing-domain
b) use of signatures
c) use of O-ID
d) use of revocation records
i. local-part fingerprint
ii. O-ID
iii. (2g)
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.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org