Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does no

Douglas Otis wrote:
> On Aug 22, 2005, at 3:23 PM, Scott Kitterman wrote:
>
> > Douglas Otis wrote:
> >
> > > Binding a mailbox-address or mailbox-domain to a domain signature  is 
> > > not a goal, it is a mechanism.  What is the intended goal?   What is  
> > > the selection process?  What level of administrative  effort will 
> > > this  entail?  What level of DNS interaction is required?
> > Good design questions for the group to work on once it's chartered.
>
> What practical role does DKIM play, what problems are being  addressed, 
> and what problems are potentially created?  Consider this  together with 
> potential systemic risks.
> You wish to include an anti-forgery mechanism directly within DKIM.   I 
> fear serious issues will likely derail DKIM deployment when "anti- 
> forgery" mechanisms interfere with normal email, while at the same  time 
> forgery continues.  I doubt there is a possible draft that  offers 
> obtainable goals related to anti-forgery without per-user- keys.  
> Anti-forgery appears practical for S/MIME or OpenPGP, but  becomes too 
> problematic for DKIM.  At least when done directly.
The signature and SSP parts of DKIM are completely severable.  Although 
not perfect the current SSP draft would seem to offer a basis for more 
optimism than that.
Certainly S/MIME or PGP offer greater identity assurance, but that isn't 
really the point.
> Considering the goal of protecting naive recipients, I then described  
> an add-on feature for an MUA that supplants the need to include anti- 
> forgery mechanisms directly within DKIM.  This was based upon a  
> practical assessment of the goals using a narrower focus.  For  example, 
> you said there is a need for domain-wide assertions.  I  agreed a 
> domain-wide assertion can prevent unauthorized servers.
Yes.  From my POV (and once again I don't expect us to agree on this) 
you managed to propose an alternative that is virtually completely free 
of the functionality that I'm after.
Once it gets to the MUA, it's too late.  I want to reject the message 
during SMTP (after DATA, but before OK).
> Allow the MUA to establish bindings from within the message.  This  
> would remove the need to publish inordinate amounts of binding  
> information within DNS.  At least this would provide recipients a  
> warning when messages deserve closer examination.  An MUA "mailbox- 
> address/domain-signature/opaque-identifier" snap-shot add-on,  together 
> with a simpler DKIM that remains independent of mailbox- addresses will 
> still abate most targeted spoofs.  Leave this aspect  of spoofing to the 
> MUA, which must change to provide this type of  feature anyway.  By not 
> tracking mailbox-addresses, this allows a  simpler more basic design for 
> DKIM.  The simpler design should permit  easier analysis, and provide a 
> safer outcome.
If one is after an MUA solution, that may be true.  However because of 
the time requirements for an MUA solution, I think you end up backing 
yourself into some kind of full fledged PKI infrastructure to support 
post-facto signature validation.
I expect that by constraining signature validation to the MTA/MDA and 
passing a result to the MUA, an MTA/MDA approach would be much simpler, 
lighter weight, and deployable.  I don't expect you'll agree with this 
either.
Given that domain-wide assertions can prevent unauthorized servers, I 
think that we would seriously be wasting an opportunity here if we 
didn't provide that capability.
The details of where/when and how that is done (which seems to be our 
major point of disagreement at this point) I would imagine are one 
aspect of what the yet to be chartered working group is supposed to 
figure out.
So, from a charter scope perspective, I would think that this aspect of 
the problem should definitely be included.
The threats and the potential for DKIM to deal with the subset of these 
types of threats that it does should also be included in the threat 
assessment.
Scott Kitterman
_______________________________________________
ietf-dkim mailing list
http://dkim.org