Subject: Re: [ietf-dkim] Responsibility concerns with Designated Signing Domains

From: Scott Kitterman <[email-masked]>
Date: Sat, 26 Aug 2006 1:29 -0400

On Fri, 25 Aug 2006 22:02:40 -0700 Jim Fenton <[email-masked]> wrote:
>Scott Kitterman wrote:
>> I can see this going either way.  In the end the operator controls what 
goes 
>> out and what doesn't.  Both the author domain and the operator domain 
can 
>> allow bad things to happen.  Only the operator is in  a  position to be 
>> assured of preventing them.
>>   
>I'm pretty sure I have the "operator" terminology messed up, then.
>
Maybe it's me that's messed up.  Using Dave's operator terminology, I 
thought that meant the entity running the MTA (e.g. the ISP or domain host).

Scott K
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Sat, 26 Aug 2006 09:36:22 -0700

>thought that meant the entity running the MTA (e.g. the ISP or domain host).
I think you're using it the same way as Dave, but your message doesn't 
make sense
to me because there may not even be an "operator domain" in the path 
(ie, author-receiver
directly). I think I also read that you said that you'd expect operator 
signatures to be
the prevelent ones, but I'd expect just the opposite: author domain 
signatures will be far
and away the most prevalent. This certainly is the case right now.

          Mike

---

From: Dave Crocker <[email-masked]>
Date: Sat, 26 Aug 2006 10:29:39 -0700

>> thought that meant the entity running the MTA (e.g. the ISP or domain 

Yes, I believe that matches the way I have been defining the term.

> I think you're using it the same way as Dave, but your message doesn't make
> sense to me because there may not even be an "operator domain" in the path 

Just in case there is confusion:

We all need to be careful with the word "domain".  (I'm not saying Michael
isn't, but rather am noting a concern for this thread and beyond, just in case
the usage issues are not clear for everyone.)

When talking about an Administrative Management Domain (ADMD), its associated
domain name might not be part of the issue.  In fact, that is exactly the
distinction between using sub-domain names, for outsourced signing, versus
creating some sort of publicly visible delegation mechanism, such as DSD.

With sub-domain names, the signing domain (d=) can be the domain name of the
author.  With delegated domains, the signing domain is associated directly with
the outsourcing agent, but then is linked back to the author domain.

As I understand it, the intent is to say who actually did the signing, but then
request that their reputation not be used for evaluation, but rather that the
reputation of the author's domain be used.

I believe the above description of the different approaches is accurate and that
it should make clear that a "delegation" mechanism that is visible to the
recipient entails an entirely new layer of indirections.  Hence, additional
complexity, additional overhead, and additional risk.

If you want the reputation of the author's domain to be used for assessment,
then sign with the author's domain.

If you want the reputation of an operator's domain to be used, then sign with
that operator's domain.

Creating a mechanism that specifies "authorization" of another domain (or,
rather, a mechanism that certifies an indirect reference) is entirely unnecessary.

I keep coming back to a simple request and haven't seem clear answers:

   DSD, and the like, create a mechanism.  As nearly as I can tell, this
additional mechanism does not define new functionality.

   Hence the arguments in its favor need to be clearly and compellingly stated.
My request is that this be done.

The arguments that I believe have been made, so far, are:

   1. An additional delegation mechanism removes the "need" for passing around
security information

   2. An additional delegation mechanism is more likely to be kept up-to-date.

If there are additional assertions, folks should make them and justify them.

As for these two, here --

Passing Around Security Information:

When there is a trust relationship between two independent organizations, there
will necessarily be some trust/security-related information passed around. The
details of what information and how it is exchanged will vary, but in all cases
there will be some sensitive information exchanged. .  There appears to be a
view held by some that passwords are a special deal, but I will claim they aren't.

The difficult aspect to such an exchange is authenticating the participants.  I
will claim that once this is done, adding privacy is a relatively minor concern.
 The technology and practices for sharing secret information between consenting
participants is far too well established for anyone to believe that it imposes
particularly onerous issues.

Rather, I'll claim that *any* information depending upon the trust relationship
entails the same risk.  In other words, the primary issue is whether the parties
do trust each other and do believe that the information they get from each other
is valid (authentic). By that measure, the particulars of delegation are not the
issue.  Rather the issue is the mere fact of transactions that depend on the
trust relationship.

Keeping delegation information up to date:

Sub-domains are well-established constructs.  It is certainly true that many
kinds of domain name records are not kept up to date.  However the tools for
doing this administration are, at least, well established.

What is not clear is why anyone believe that an additional mechanism for
indirect specification will not be just as bad?

To the above issues, I'll add one more minor topic:

Efficiency:

An extra mechanism is an extra mechanism.  As John Levine points out it is
inventing a new mapping, with all the risk attendant to inventing anything.  In
this, case, however, what is being invented is a new security layer.  This ought
to worry folks, given the demonstrated difficulties in getting new security
mechanisms successfully validated, deployed and used.  Since the mechanism has a
remarkable similarity to the path registration schemes of recent focus, we
should also worry about the administrative and operational impact that the new
mechanism are likely to share with these.

This extra mechanism also entails additional effort during validation.  More to
administer; more to query; more to correlate.  As a rule, all this extra work
ought to be required to provide extremely significant benefit, over the
alternative of using existing mechanisms.

It doesn't.

d/
-- 

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Hector Santos" <[email-masked]>
Date: Sat, 26 Aug 2006 14:36:12 -0400

----- Original Message -----
From: "Dave Crocker" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, August 26, 2006 1:29 PM
Subject: [ietf-dkim] Direct vs. Indirect specification of the
accountabledomain

> As a rule, all this extra work ought to be required to
> provide extremely significant benefit, over the

Can you prove it does not?

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