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