Stephen Farrell wrote:
I thought we covered key management threats in the threat analysis
already. In any case, if it's not covered adequately, it belongs in
either the threat analysis or in -base, because there is no key
management in SSP.
Sure, but my worry is that we define SSP so that we push people
to delegate keys (as opposed to signing) and then get (properly)
criticised for not supplying the required key management. This
isn't really a comment on the SSP requirements, but rather a
worry about the consequences of how we resolve some of these
issues, (and a definite wish to not have to start figuring
which existing key management scheme(s) to pick for dkim key
delegation;-)
I finally found the citation I was looking for.
There are two classes of threat regarding key delegation:
1. Threats that exist because of the existence of the key delegation
mechanism. These might include things like publication of rogue key
records in DNS, by cache poisoning and the like. I don't think anyone
is proposing that key delegation be eliminated in favor of SSP
delegation, so these threats are unaffected by the prevalence of key
delegation deployment.
2. Threats that relate to the delegation process itself. These might
include a man-in-the-middle attack in the communication between
delegator and delegatee where the delegatee sends the delegator a public
key to publish in a selector. This is discussed in the threat analysis,
section 4.1.2, last paragraph. Since the key delegation process is out
of scope for -base (which really only discusses the signing and
verification process and the format of key records), it's not discussed
there. But this is a fine topic for the overview document, and I hope
we cover it there.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html