Dave Crocker wrote:
So, the degree of enforcement for the content of *any* signed field is not
stated as part of DKIM's specification.
Yes, that sounds right. DKIM-base says how to sign stuff but really
says little about what that stuff might mean.
2. (Overlaps with #1.) The scenarios nicely demonstrate how the
verifier can't tell exactly what's happened, but don't seem to
say exactly how the bad actor benefits, nor what damage might
occur to the verifier.
Isn't it as simple as: A signer might have practices that permit header fields
to have invalid content?
If so, then that doesn't seem to be dependent on the "SSP DSD"
mechanism. I've no position on whether that's right or not, but
haven't understood what the "SSP DSD" mechanism changes.
3. If we could describe what we do/don't want to happen as a
security requirement that'd be good to include in the requirements
document (along with the problematic scenarios).
Certainly would be good for us to be clear about!
Agreed.
4. If there is a requirement to achieve similar functionality via
delegation of keys, then we (as a WG) need to be very clear about
how those keys are managed, or else have to provide a convincing
argument that such management is not our problem. (Any such key
management being non trivial.) It is at least arguable that the
overall system would be less secure due to problems with key
management, when compared to problems arising from corner cases,
or bad behaviour happening, prior to delegated signing.
You lost me here.
DKIM says nothing about key management now. Why does this need to change, for
the particular case of having keys used by someone in another ADMD?
My earlier mail to Jim may have explained. But saying it again another
way can help so:
If we support delegation of signing ("SSP DSD") then I can easily
see how to do that (by including the delegatee name in some SSP
practice statement). If however, we don't support delegation of
signing, then it may be more likely that folks make more use of
delegation of keys. Once we start down the road where delegation
of keys is common (or nearly so), then there's an onus on us to
say how to do that, and there's a lot of complexity there. For
example, what if domain1 tells domain2 to use privatekey1 but
domain2 then (mistakenly or otherwise) tells domain3 to re-use
the same key? If private key delegation were common then we'd
have to analyse that, and other, cases. (Which is lots of work,
a thing from which I regularly shy away:-)
S.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html