On Thu, 24 Aug 2006 00:46:12 +0100 Stephen Farrell
<stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie> wrote:
Jim Fenton wrote:
Some workarounds have been proposed whereby the signing domain uses
subdomains to work around some (but not quite all) of this ambiguity. I
believe that this removes some of the supposed simplicity that was the
motivation for SSP DSD in the first place.
I didn't follow all of those details, but I'd agree that, in general,
and in this case, a complex delegation mechanism is worse than none.
I don't think it is more complex. It just puts the complexity in a
different place. Less complexity for author domains at the expense of
slightly more for operators and verifiers. Given that this mechanism is
targetted at small non-technical author domains, I think this is good. Put
the complexity where there is the expertise to deal with it.
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. Be good to document that explicitly. (This
might be just my ignorance of course, but its not very clear to
me.)
In at least some cases, bad actors and good actors may share the same
domain. Suppose a bad actor shared the same domain with a good actor
and a mailing list. The bad actor could spoof a message to the mailing
list from the good actor. If the domain uses SSP DSD, the signature
would not have any way of indicating whether it was on behalf of the
good actor or the mailing list. The "damage" to the verifier is the
interpretation of a mailing list signature as being an author signature
from the good actor.
But that depends upon how the verifier has (mis)interpreted the
signature - something I thought we generally try to steer away from.
The proper interpretation (at the dkim level) of the "SSP DSD"
signing case is surely that company.com nominated isp.com to sign
for company.com and that that's all correct (or not, whatever). A
verifier that thinks it means that isp.com says that it got the
signed-bytes directly from company.com seems to be making
decisions/assumptions at the wrong layer.
+1
I'd still like to see a concrete case of something that can happen
here that cannot happen if no "SSP DSD" mechanism is defined.
Thanks. Modulo that uncontrolled signing is not a suitable approach for a
SSP DSD (and I think we all agree on that - I've volunteered to write the
spec language warning about this), I don't think there is anything.
Sorry for being obtuse, but I'm concerned that we're maybe eliminating
a requirement that has some support (unless those supporting it have
been convinced already), and where the basis for elimination is
something that can happen in any case (which basically seems to be
that funny things can happen before signing and the verifier will
be blissfully ignorant).
In case there's any doubt, I'm not convinced.
There are domains out there that cannot do the NS delegation trick.
Including the DSD requirement makes DKIM less dependent on specific
infrastructure requirements.
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html