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

[Stephen Farrell]

Jim Fenton wrote:
> 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.

That's a fair question. Though I'm not sure if Russ is listening here
right now.

However, you could still structure the putative section 2 (the
vulnerability analysis) like that. What, I'd still like to see
in the end is:-

- For each vulnerabilty some consideration of impact and likelihood
   (i.e. the ranking thing) to the extent that we can do that now, so
   we at least convince ourselves we're focusing on the more important
   (relevant) things

- A collection of MUST/SHOULD etc. constraints imposed on the protocol
   which is basically the output of the threat analysis (so we've
   something to check the protocol against later)

> 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.

Well, that's a fair question in principle, but given that the
draft charter refers to draft-allman-dkim-* I think its fair to say
that that those keys do exist, and so IMO the vulnerability is in scope.
(And yes, it ought result in a statement in the sec. cons. of the base
protocol.) That's not to say that the anaylsis should only focus on
threats introduced as a result of the dkim protocol of course, and the
point of the example was just to point out that it doesn't fit easily
into the current structure, something about which we seem to agree.

Stephen.

> -Jim
> 
>