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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 21 Aug 2006 12:05:40 -0700

Paul's note further convinces me that the correct semantics for SSP are not 'the message will be signed' but rather 'there will be a DKIM header'

The difference between the two is that adding a DKIM header need not mean the same thing as signing the message. A DKIM header might simply specify a selector for a key record that 1) specifies the NULL algorithm 2) some form of restrictions on use.

Such a use would fully address the third party policy concerns raised. 

   *	The sender would choose the from address, insert the NULL key record with the relevant selector.

   *	The Third Party sender would sign the message themselves and add in a NULL DKIM header for the selector specified by the sender.

   *	Receivers would note that the email is compliant with the sender policy and that the Third Party Sender claims responsibility. 

In this scheme everything works fine. The semantics of the policy language are simple but effective. There is no need for crypto to be exchanged between the parties unless they want to. The complexity is kept out of the policy record, everything is in the key record. 

The optimum semantics remain 'there will be a DKIM header with a selector of the form *.xyz.example.com'

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Hoffman
> Sent: Monday, August 21, 2006 11:28 AM
> To: [email-masked]
> Subject: Re: [ietf-dkim] Delegating responsibility: a make 
> vs. buy design decision
> 
> At 10:40 AM -0400 8/21/06, Damon wrote:
> >>It sounds like what you and few other people want is an SSP policy 
> >>that says "if you receive a message that is supposedly from 
> this site 
> >>(for some definition of "from") and it doesn't have the 
> mark that says 
> >>that XYZ is authorized to sign the message, assume the message is 
> >>forged". Is that a correct summary of the requirement you see?
> >
> >
> >I am glad you put a question mark at the end.
> 
> But you didn't answer: is that a correct summary. (And, if 
> not, is there a summary that looks like this one?)
> 
> >It took me a while to read through this can of worms, but for every 
> >argument against the optional flags that myself, Hector, and I few 
> >others are looking for, I see contrary arguments that only 
> bolster the 
> >point that these thing we are hinging on are OPTIONAL. Just because 
> >they are OPTIONAL does not automatically make them irrelevant nor 
> >unnecessary.
> 
> True. However, even if they are optional, they have to be 
> fully specified in order for people in the WG to understand 
> if they are relevant or necessary. The parts that I miss in 
> this thread is: "for this particular optional statement of 
> policy, what is the recipient of that policy message expected 
> to do? What are the requested to do?"
> 
> I see people who supposedly agree with each other about the 
> policy appear disagree on the required and requested response 
> to the policy. 
> Some of that is because the tone of the messages is "this is obvious" 
> (which it is not), and some of it is because there are 
> long-winded discussions of the usefulness of the messages 
> that don't concretely say what the recipient should/must do.
> 
> Note that the above summary of this one point has such a
> specification: "assume the message is forged".
> 
> --Paul Hoffman
> _______________________________________________
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html
> 
> 

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

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 21 Aug 2006 15:05 -0400

On Mon, 21 Aug 2006 08:28:21 -0700 Paul Hoffman <[email-masked]> wrote:
>>>that says "if you receive a message that is supposedly from this site
>>>(for some definition of "from") and it doesn't have the mark that
>>>says that XYZ is authorized to sign the message, assume the message
>>>is forged". Is that a correct summary of the requirement you see?
>>
>>
>But you didn't answer: is that a correct summary. (And, if not, is 
>there a summary that looks like this one?)
>
>>others are looking for, I see contrary arguments that only bolster the
>True. However, even if they are optional, they have to be fully 
>specified in order for people in the WG to understand if they are 
>relevant or necessary. The parts that I miss in this thread is: "for 
>this particular optional statement of policy, what is the recipient 
>of that policy message expected to do? What are the requested to do?"
>
>I see people who supposedly agree with each other about the policy 
>appear disagree on the required and requested response to the policy. 
>(which it is not), and some of it is because there are long-winded 
>discussions of the usefulness of the messages that don't concretely 
>say what the recipient should/must do.
>
Not speaking for anyone else, but "assume the message is forged" is what 
I'm after.  What the receiver does with it is a matter of receiver policy 
that I think there is consensus should not be standarized.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 22 Aug 2006 21:34 -0400

On Tue, 22 Aug 2006 15:59:00 -0700 Jim Fenton <[email-masked]> wrote:
>Scott Kitterman wrote:
>> On Monday 21 August 2006 01:34, Jim Fenton wrote:
>>> Scott Kitterman wrote:

>>>> Yes, but the fundamental operational problem will be to pick the 
correct
>>>> domain to sign with.  You have to make that decision either way.  The
>>>> basis upon which you make the decision is the same.  I agree that the
>>>> result LOOKS less ambiguous with the NS delegation approach, but the
>>>> fundamental security issue is don't pick the wrong domain to sign with
>>>> and that's no different.
>>>>       
>>> When using the "authorized signing domains" approach, the signer uses
>>> its own domain name, not that of the domain doing the delegation.  I
>>> don't see where there is a choice for the signer to make (which is also
>>> the source of the ambiguity).
     
>> We had been discussing the need to segregated authenticated traffic 
(where 
>> authorization to use the 2822.From has been established) from other 
traffic 
>> being signed by use of a subdomain.  This is to avoid issues like your 
>> mailing list concern.  The authorized signing domain would be the 
subdomain 
>> that the operator has designated for the purpose.  

>Sorry, having trouble keeping the context of the discussion right.

I certainly understand.  There are lots of messages flying around all 
saying slightly different things.  

>This could be done, but dilutes the simplicity argument that motivated
>the Authorized Signing Domains approach in the first place.  Formerly
>the ISP just signed using their own domain name; now they must create a
>subdomain for each of their customers, publish keys there, and sign each
>using the proper subdomain?  Or do they sign using i=@cust49.isp.com and
>d=isp.com perhaps?
>
The  point that relates to SSP and the feasibility of a desgnated signer 
list is that what I've referred to as controlled and uncontrolled traffic 
should not be signed with the same domain.  This, I think cures your 
mailinglist concern.  

Whether the operator signs controlled traffic with a single domain or a 
different one per customer is not something that I thinks needs to be 
standardized now.  It is related to reputation and not SSP.  I could see an 
operator promoting a positive reputation for their signing domain as a 
value added advantage.  I can equally envision an operator promoting per 
customer domain signing so that other customers can't affect the 
reputation.  None of that matters for SSP.  for SSP, all that is needed is 
a signing domain that is only used for controlled traffic.  If an operator 
only deals in controlled trafffic, then no special domain is needed.

>But there is a residual problem.  Suppose [email-masked] is a
>subscriber to this list and someone spoofs a message from
>[email-masked] to the list.  [email-masked] accepts the
>message and sends it to isp.com, their Authorized Signing Domain, and it
>is signed and sent.  Is the signature from jdoe (the author) or
>ietf-dkim (the mailing list)?  Without Authorized Signing Domains, you
>could tell by looking at the local-part of i=.  But now you can't.  I
>think this is an important distinction, even if it only applies in a
>subset of use cases.

I think if you've painted youself into the looking at localparts of 
anything then you've got a scalability problem and not a solution.

I would argue that your example is a case of uncontrolled operations.  It 
is up to the MSA to prevent forgery.  The author in this case is still 
[email-masked].  If mipassoc.org lists an authorized signing domain it 
needs to be at the very least something like controlled.isp.example.com and 
the mailing list traffic (since it's pretty much inherently uncontrolled) 
must not be signed by the same domain.  It might be just isp.example.com or 
some other, more specific, subdomain.  It really doesn't matter what.

I've got a very clear picture of how this would work in my mind.  I wish I 
could devote more time to a concise and more coherent description of this.  
Unfortunately, since this is volunteer work for me, I'm having a hard time 
carving out dedicated time to work through it.  Sorry I'm not doing a 
better job of it.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 22 Aug 2006 21:43 -0400

On Tue, 22 Aug 2006 16:06:08 -0700 Jim Fenton <[email-masked]> wrote:
>Scott Kitterman wrote:
>
>On Mon, 21 Aug 2006 14:55:08 -0700 Michael Thomas <[email-masked]> wrote:
>Scott Kitterman wrote:
>OTOH, it seems to me that it's been said Ad Nauseum. Where feasible I 
agree it's better, but there are operational frictions that will impede 
this approach in some cases.
> What I believe that we've discovered is that this isn't nearly simple as 
some people hoped. Doing as little up front as possible so that you can get 
operational experience is almost certainly better than guessing -- 
especially when the guessing wrong is a likely outcome. In this particular 
case, I dooubt there will be harm because receivers will always have an 
incentive to make better decisions (and hence the desire to upgrade).
> I disagree. What I think we've discovered that there is no additional 
complexity for signers or authors. It is, in fact, simpler for signers.
>
> With the need to choose the appropriate subdomain depending on which 
author-domain submitted the message to the signer, I think the complexity 
for signers is now about the same as for key delegation, assuming that the 
signer uses the same public key for all of its customers.  About the only 
thing that changes from author-domain to author-domain is the i= address 
and the d= domain.
As I said in the previous message I don't think it's necessarily a 
sub-domain per customer.

I think the simplicity for the designated signer approach is for the author 
domain.  All that's needed is the ability to publish a TXT record with an 
underscored domain name in their DNS.  These are the same DNS requirements 
that exist for DKIM base.  I think it's both fair to small author domains 
and an aid to deployability to provide this kind of mechanism.

I'm not seeing any significant downside to it that isn't equally a problem 
for the NS delegation/operator signs first party for the author approach.

Scott K

---

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

On Thu, 24 Aug 2006 01:28:48 +0100 Stephen Farrell 
<[email-masked]> wrote:
>
>Dave Crocker wrote:
>> So, the degree of enforcement for the content of *any* signed field is 
not
>> stated as part of DKIM's specification.

For DKIM-base, yes, but not for DKIM.

>Yes, that sounds right. DKIM-base says how to sign stuff but really
>says little about what that stuff might mean.
>
Yes, but DKIM-SSP gets beyond that.  The content of the 2822.From has to be 
meaningful.

>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.

I think it changes not much.  An operator signing first party need to 
ensure 2822.From isn't forged.  This is true whether they sign first party 
based on the signing domain being the same or by being a DSD.

Scott K

---

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

On Thu, 24 Aug 2006 17:39:36 -0700 Jim Fenton <[email-masked]> wrote:
>...  In addition to other objections I have, if it is not
>significantly simpler I question the need for an additional mechanism,
>especially in a security context such as this.

I think the real question is simpler for who.  I think it makes sense for 
operators to take on complexity is it simplifies thing for authors.
...
>I have a list of other concerns, which I'll post separately.  I started
>with the security concern because it seemed the most clear-cut objection.

I look forward to it.  I don't want to do it if it's dumb.

Scott K