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;-).
Sorry to do this, but I'll start with slide#52 from one of
the courses I teach which says: "Evaluate threats based on
the impact and probability of occurrence of the vulnerability
concerned" - that leads to the probably classical way of
doing risk analysis where we first try to identify
vulnerabilities then rank them (to the extent possible)
in terms of impact and probability of occurrence. We then
deal in most detail with those in the "high,high"
category. Seems to work fairly well and is a recognised
way of doing things. (End of pompous lecturer bit:-)
If we applied this to the threats draft it'd end up
with a structure like this:
2. Vulnerabilities
- mostly existing text but easier to extend as new
vulnerabilities are considered, internal structure
here is less important than naming/numbering the
vulnerabilities;
3. Ranking
- new section, mainly a table with H/M/L entries
and justification thereof (where necessary) - of
course this'll never be "right" since there's
no specifics available on the deployment
environment, but we can do something even at this
stage of the game
4. Security requirements
- based on the ranking, we say what we think are
important MUST/SHOULD/MAY security *requirements*
for dkim so we can compare the protocol spec with
this section later on (we don't say exactly which
countermeasures will be used though since at this
stage that's a moving target); ideally this section
covers addresses all vulnerabilities but in practice
we cut the cloth according to the effort available
(but we can easily incorporate additional IESG
comments here at a very late stage too)
There's an example below of how we might use this for
something we ought include but which doesn't seem to easily
fit into the current structure.
If we did restructure this way then I think we could also
have a bit of a vulnerability brainstorming session in
Vancouver where we try to flesh out the putative sections 2/3
and then finish the job (section 4) via email subsequently.
The main benefit here is that this structure provides us
a way to manage the threat analysis and which leaves the
reader with the (correct:-) impression that we've covered
all the bases.
If we did structure it this way could we get a -01 version
with such a TOC out before Vancouver?
Or, are there reasons to not make this change?
Regards,
Stephen.
PS: This structure also allows us to ask contributers to
frame their contributions so they'll fit in, say like the
example below, so we may end up saving the editor some
time here!
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.
Ranking: High impact (private key a gonner) but low probability
since its unlikely that a dkim server will include sufficiently
fine-grained timing information in signed messages to allow
timing analysis and the network traffic timing will probably not
allow the signing-execution-time to be easily distinguished
Countermeasure: Protocol SHOULD NOT include fields which make
timing attacks easier; Guidance about timing attacks SHOULD
be included in the base spec. security considerations.
_______________________________________________
ietf-dkim mailing list
http://dkim.org