Re: [ietf-dkim] New DKIM threat analysis draft

Amir Herzberg wrote:

> Jim Fenton wrote:
>
> > Amir Herzberg wrote:
>
> > > I have only one real reservation. In section 6.3, discussing the 
> > > message replay attack, esp. in 2nd paragraph... It is presented as 
> > > if DKIM cannot be applied against replay since replay is 
> > > indistinguishable from acceptable acts e.g. forwarding. This is not 
> > > necessarily true. A legitimate application of DKIM may require 
> > > senders to indicate specific recipient; this would allow replay 
> > > prevention, of course in the price of requiring additional support 
> > > to deal with legitimate forwarding. I'm not suggesting DKIM should 
> > > be modified to support that, indeed this is not required at DKIM 
> > > level at all, but I think the text now seems to exclude this usage, 
> > > and this should be fixed imho.
> >
> > What matters here is really the envelope-to address.  There are some 
> > fairly large obstacles to signing the envelope-to address, including 
> > the fact that it's not available to MUAs and the fact that it gets 
> > changed when a message is legitimately forwarded, so I'm not sure how 
> > this would work.  Can you provide more details of what you have in mind?
>
> Please notice, I'm _not_ suggesting that signing the recipient should 
> be another DKIM requirement. On the contrary, I agree that DKIM can 
> have significant value without this and that signing recipients is a 
> non-trivial issue, e.g. with legitimate forwarding scenarios. But I 
> think it is fair to say that this is not a DKIM issue, in the sense 
> that some DKIM users (senders and recipients) may agree on some 
> standard solution, without requiring change to DKIM - so, the text 
> simply needs to be modified so that we don't _exclude_ such usage of 
> DKIM. BTW, I believe this issue is Ok with Meta-Signatures.
I'll skip delving into the details of what you have in mind, since, as 
you say, this is not a DKIM issue.  But the intent is that others be 
able to build on DKIM -- for purposes like you describe, for reputation 
and accreditation, and for links to other key distribution systems, to 
name a few.  So please point out places where you think any of the DKIM 
specifications exclude such things.
My main concern is that such extensions be additive:  we want to define 
a signature format that remains usable by verifiers that don't implement 
all these extensions.  For example, supplemental key management systems 
are fine, as long as whatever baseline key management is still present 
(with whatever limitations that implies for verifiers not implementing 
the extension).
-Jim
_______________________________________________
ietf-dkim mailing list
http://dkim.org