A quibble, a non-quibble and an aside:-)
Jim Fenton wrote:
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.
The quibble: the threats are not unaffected if the liklihood changes.
The vulnerability is unaffected, yes, but the threat is affected.
(If, as I do, you consider a threat as being a combination of a
vulnerability, an impact and a probability of occurrence.)
Why its a quibble: because otherwise I agree with you, I've not
heard anyone say SSP delegation totally eliminates the requirement
for other types of delegation.
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.
The non-quibble: The overview document will be informational. If we want
to have a standard way to do key, (or SSP DSD), delegation then don't we
need some (perhaps new) normative document? [To be clear: I agree that
base doesn't need this since, as you said, key (and all) delegation is
out of scope for base.]
And as an aside, the threats paragraph you reference is a good one. It
says that one might use signed public keys (e.g. maybe with some other
key in some other key record, or else using certificates) or that one
might use "customary" precautions against the exposure of private keys.
That latter might be taken to mean things like key splitting, which if
adopted (I wouldn't argue for it btw), would require a bit of protocol.
(Saying "send a p12 with <foo> constraints" is way better probably for
that case.) My point is that if we do encourage key delegation then we
may need a bit more normative specification somewhere (but not in base).
S.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html