[ietf-dkim] Structure of the threat analysis...

[Jim Fenton]

Stephen Farrell wrote:

>
> Hi All,
>
> I've just been reading the threats draft, which after (or maybe
> even before!) the charter should really be our #1 thing at the
> moment (given that we're gated on progress there).
>
> First, I like the document - I think it does cover the main
> threats that will concern us. However I'd like to suggest an
> alternative structure which may make it easier to maintain
> and which would allow the reader to be clearer that the
> analysis has good "coverage" (and hence get us past the IESG
> more easily;-).

One of the biggest problems with threat analyses is that there is no 
agreement on what they should contain nor what their structure should 
be.  I believe the Security Area realizes this and will be working to 
correct that.  In the meanwhile, a structure was suggested by Russ 
Housley which is described in 
http://mipassoc.org/pipermail/ietf-dkim/2005q3/000033.html which formed 
the basis for the threat analysis I published.  I (and many others I 
have corresponded with) feel that it's most important that the document 
be satisfactory to Russ, because he will be the one to take our request 
for chartering to IESG.

I have been planning on a minor revision of the threat document before 
the revised draft cutoff (Oct 24), but can do something more aggressive 
if it's a real improvement that will move us closer to chartering.

So I would like a reading from Russ as to whether he views the structure 
you propose as an improvement, and whether the current structure is 
adequate, before making a sweeping change such as this.

Also, regarding the example you gave:

> Vulnerability: dkim servers could be a poster-child for
> timing analysis attacks aimed at getting the server private
> key - they're signers which sign anything (and loads of it)
> and where adversaries can be easily situated on both sides
> of the signer. If this could be done then the server private
> key would be compromised from the network.

There is the question of whether this document is describing (1) the 
threat environment into which we're inserting DKIM, or whether it 
describes (2) the threats that exist in the presence of DKIM (perhaps 
those motivated by DKIM), or both.  I believe that this document should 
emphasize (1), and that (2) belongs in the Security Considerations 
section of the DKIM draft(s), even though section 6 of the current draft 
does describe some of the latter.  If you accept this philosophy, the 
above threat doesn't belong in the document because the private keys 
don't yet exist.

-Jim