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

[Jim Fenton]

Stephen Farrell wrote:

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

Please, let's ask.

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

When you say "vulnerability" I'm again not clear whether you mean a 
vulnerability of the existing mail system or a vulnerability of the 
proposed improvement (or both).  I can rearrange things, but when the 
document defines 4 bad acts in section 4, I don't think ranking them 
adds much.

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


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

Agree that the vulnerability is in scope (although IMO a little 
far-fetched, given the timing uncertainties of sending a message through 
an MTA.)  And agree that this belongs in the security considerations 
section of the base proposal.  What isn't clear to me is why the same 
thing needs to appear in both the threat analysis and the base 
document.  As it stands, the threat analysis mentions three important 
threats, and refers the reader to the security considerations section of 
the base document for more.  Isn't it sufficient to have it in one place?

-Jim