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

[Douglas Otis]

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