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