[ietf-dkim] Structure of the threat analysis...
housley at vigilsec.com
Wed Oct 12 14:51:46 PDT 2005
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.
At 12:25 PM 10/12/2005, Stephen Farrell wrote:
>Jim Fenton wrote:
>>Stephen Farrell wrote:
>>>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
>>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
>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.
>ietf-dkim mailing list
More information about the ietf-dkim