On Thu, 24 Aug 2006 00:46:12 +0100 Stephen Farrell <[EMAIL PROTECTED]> 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
