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