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

[Russ Housley]

Jim:

I am skimming the DKIM list.  I do not have time to read it everyday.

I do not think that the document needs to be restructured to get a DKIM 
charter approved.  However, I think that Stephen has made some good 
suggestions if this document were to go forward as an Informational RFC.

Russ

At 12:25 PM 10/12/2005, Stephen Farrell wrote:


>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
>
>_______________________________________________
>ietf-dkim mailing list
>http://dkim.org
>