Subject: Re: [ietf-dkim] Delegating responsibility: a make vs. buy design decision

From: Scott Kitterman <[email-masked]>
Date: Thu, 24 Aug 2006 0:17 -0400

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

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 24 Aug 2006 12:23:02 -0400

No one has shown that open ended unrestricted DKIM-BASE 3rd party signing
engines are safe and exhibit no open harm to original domain owners.

So where is the guessing?

 a) Unrestricted DKIM-BASE 3rd party signatures are safe?

Or

 b) Optional Controls for DKIM-BASE 3rd party signatures will help
    secure 1st party signatures or 1st party expectations?

If there is a desire to not do any more work in the area, then in my
opinion, there is a burden to show there are no viable threats of major
concern for 1st party domains in an unrestricted DKIM-BASE 3rd party signing
(by anyone) environment.

If that can't be shown, then all that is being done is guess work too and
also guess work about what's good or ok for original domain properties
owners.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

----- Original Message -----
From: "Michael Thomas" <[email-masked]>
To: "Scott Kitterman" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, August 24, 2006 10:10 AM
Subject: Re: [ietf-dkim] Delegating responsibility: a make vs. buy
designdecision

> Scott Kitterman wrote:
> Today. Whether there are any alternative tricks that they can perform is
> speculation. Given what I've seen proposed, I see no reason for
> encouragement.
> What we do have a good chance for is to screw the pooch by wasting a huge
> amount of time engineering to guesses.
>
>        Mike

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 24 Aug 2006 18:03:09 +0100

Hector,

Independent of DKIM, there's a problem with your argument.

You seem to be requiring those on the other side of the argument
to demonstrate the absence of vulnerabilities, and that can never
be done. One can argue (endlessly;-) but can never demonstrate the
total absence of badness.

But, we've been here before, so we don't need to go around all
this yet again,

Stephen.

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 24 Aug 2006 13:29:07 -0400

Steve,

I agree, but I think the efforts has been shown there are unrestricted 3rd
party signing concerns and there are technical sound recommendations to help
control it.

And yet, these concerns has been just pushed aside and labeled as
unwarranted, unimaginable guess work when in fact, the concerns are
technical sound, illustrated real potential issues with a very high
potential to exist.

The simplest case is when the DKIM switch is turned on (deployed).
Receivers will continue to receive as they do now, indirect attacks with
non-signed mail.   It is not guess work to envision this to be a problem
when the domain expects his mail to be signed in the new DKIM world.

And there are other obvious deployment potentials that have been expressed
which are being pushed as aside as "guess work as the only counter argument.

If we don't want to continue this line of thinking, then at the very least
it should be the burden of those who don't want it to show that unrestricted
3rd party signatures are indeed safe and would be desirable and acceptable
by 1st party domains in all cases.

Just implying to "trust us. unrestricted 3rd party signing engines are ok
for everyone," is guess work and in my opinion, surely not sound
engineering.

So yes, I agree, I prefer this would all be completely and decided by now,
but to have all the technical work and expressed concerns labeled as
questionable guess work, well, frankly, I find that professionally offensive
and rude.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 24 Aug 2006 07:10:06 -0700

Mike