[ietf-dkim] draft-fenton-dkim-threats-00

[Hallam-Baker, Phillip]

> From: Jim Fenton [mailto:fenton at cisco.com] 

> >> * Given the previous attempts to do this type of work why is DKIM 
> >> likely to be more successful?
> >
> >
> > I agree, there should be greater clarity with regard to realistic 
> > defenses offered by the DKIM mechanism, especially in the 
> third-party 
> > scenario you described.
> 
> Do you really agree?  I read Phill's comment as "we could go 
> on forever, but this is pretty good now" while I read yours 
> as "needs improvement".

I think he is agreeing with my statement of the question but not the
answer.

As you know, I intend to take DKIM considerably further, but not in this
particular forum at this particular time. At this stage I want the MASS
group to produce just the engine. There are plenty of coachbuilders but
only one place where I can get the engine.

> >> What DKIM does is to allow a party to accept responsibility for an 
> >> email message. This is very different to the traditional 
> S/MIME, PGP, 
> >> PEM, MOSS objectives.
> >
> > ...
> >
> > Repudiation offers _minimal_ value when combined with an easy to 
> > exploit mailbox-domain authorization scheme.  Abusers will adopt 
> > requisite conventions that defeat repudiation.  Ascribing 
> repudiation 
> > as a goal would be a mistake when reputation _must_ be applied as a 
> > defense.  However, with minor modification permitting replay 
> > abatement, reputation should offer protection.
> 
> On good advice, I steered clear of the topic of repudiation.  
> Is there someplace the document implies repudiation protection?

DKIM offers responsibility, not repudiation.

Non repudiation is a useful objective in some contexts but these mostly
occur about three layers up in the stack from where DKIM works.

If you are interested in non-repudiation take a look at SAML. That would
be the starting poiint I would use. But even that requires a lot more
mechanism to be added to make a working system. Making email
non-repudiable by default is not a good idea.


		Phill