Subject: [ietf-dkim] Consensus point on ADSP

From: DKIM Chair <[email-masked]>
Date: Fri, 27 Mar 2009 11:06:55 -0400

In the IETF 74 DKIM meeting, we had a brief discussion about the current state of 
ADSP, given the recent discussions on i= (and other things).  It seems to the 
chairs that ADSP isn't severely affected, and that changes would be needed only 
in section 2.7, "Author Signature", which is the only place that d= and i= are 
mentioned.  Here's the current text (from -09), for reference:

> 2.7. Author Signature
>
>
>    An "author signature" is a Valid Signature that has the same domain
>    name in the DKIM signing identity as the domain name in the Author
>    Address.  If the DKIM signing identity has a Local-part, it is be
>    identical to the Local-part in the Author Address.  Following
>    [RFC5321], Local-part comparisons are case sensitive, but domain
>    comparisons are case insensitive.
>
>    For example, if a message has a Valid Signature, with the DKIM-
>    Signature field containing "i=[email-masked]", then domain.example
>    is asserting that it takes responsibility for the message.  If the
>    message's From: field contains the address "[email-masked]", that
>    would mean that the message does not have a valid Author Signature.
>    Even though the message is signed by the same domain, it will not
>    satisfy ADSP that specifies "dkim=all" or "dkim=discardable".
>
>    Note:   ADSP is incompatible with valid DKIM usage in which a signer
>       uses "i=" with values that are not the same as addresses in mail
>       headers.  In that case, a possible workaround could be to add a
>       second DKIM signature a "d=" value that matches the Author
>       Address, but no "i=".

The current proposal is to remove i= here, and rework the text so that ADSP uses 
d= only.  We note the following:

1. If, after some implementation and operational experience, the group decides 
that i= does need to be there, it can be added back in as an extension.

2. Alternatively, if, after some implementation and operational experience, the 
group decides that the function needs to be there, it can be added as an 
extension, with a new tag (as with Jim's example of r=).

3. We don't have that operational experience at this point.  The chairs recommend 
going ahead with this proposal.

The chairs' recommendation aside, the decision is, as always, with the working 
group.  Please begin discussing this, in this thread, forthwith, and desist next 
Friday, 3 April, at which point we'll evaluate the consensus and proceed with 
ADSP.

<strike>Go wild.</strike>
<strike>Knock yourselves out.</strike>
Proceed with the discussion.

Barry

--
Barry Leiba, DKIM working group chair  ([email-masked])
http://internetmessagingtechnology.org/

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

---

From: Hector Santos <[email-masked]>
Date: Fri, 27 Mar 2009 13:50:10 -0400

DKIM Chair wrote:
> d= only.  

I guess what I didn't quite get in these discussions is "use d= only" 
for what purpose?   Are we saying the change would reflect this instead:

    For example, if a message has a Valid Signature, with the DKIM-
    Signature field containing "d=domain.example", then domain.example
    is asserting that it takes responsibility for the message.

What has been confusing to me is getting the (possibly wrong) idea 
that the domain lookup is no longer the From: domain, but rather the 
d= domain.

I guess what is lost to me is who is really "responsible" for the 
message.   This is the right way to understand it?

   - The Author Domain is responsible for the content of the message.
   - The DKIM d= domain is responsible for signing the message.

For ADSP purposes:

   - Authorization is determine by looking up the Author Domain record.

-- 
Sincerely

Hector Santos
http://www.santronics.com

---

From: John Levine <[email-masked]>
Date: 27 Mar 2009 22:10:06 -0000

>The current proposal is to remove i= here, and rework the text so that
>ADSP uses d= only.  We note the following:

That's fine with me.  I still don't see much utility in ADSP but this
keeps it from damaging DKIM.

R's,
John

---

From: Jim Fenton <[email-masked]>
Date: Fri, 27 Mar 2009 18:09:29 -0700

>>       second DKIM signature a "d=" value that matches the Author

I'll start by proposing text that we could use if we adopted an
alternate definition of Author Signature based on the d= value only. 
Then I'll describe what I think we'll lose by going to that definition.

Here's alternate text based on d=:
=====

2.7 Author Signature

An "author signature" is a Valid Signature where the domain of the
signing entity ("d=" value) is the same as the domain name in the Author
Address.  This comparison is case insensitive.

For example, if a message has a Valid Signature with the DKIM-Signature
field containing "d=example.com" then example.com is asserting that it
takes responsibility for the message.  If the message's From field
contains the address "[email-masked]", that would mean that the
message does not have a valid Author Signature because the message is
not signed by the same domain.

Informative Note:  ADSP is incompatible with DKIM signing by parent
domains described in section 3.8 of [RFC4871] in which a signer uses
"i=" to assert that a parent domain is signing for a subdomain.
=====

Here is what I see are the problems with this alternative:

1. As noted above, the use of d= means that signing by parent domains,
specifically called out in RFC 4871, doesn't result in Author
Signatures.  This is arguably less of a problem because "ADSP by parent
domains" (the ability of a domain to assert ADSP for a subdomain) was
eliminated some time ago, so ADSP records would need to each for each
subdomain.  However, management of key (selector) records in each
subdomain would still be required, while ADSP records require little or
no management such as key rotation or revocation.

2. It has been noted that a domain might have different reasons for
signing a message.  It might, for example, sign a message on behalf of a
mailing list manager operating in that domain.  When Author Signature is
based on a d= comparison alone, any signature from the same domain as
the author is assumed to be a signature representing the original
introduction of the message into the mail stream.  That may or may not
be an important distinction, but I'm pointing out that information is
lost and I'm not sure we have enough experience to say that we don't
need it.

In the words of Dave Crocker,
> OK.  Start shooting.
-Jim

---

From: Mark Delany <[email-masked]>
Date: Fri, 27 Mar 2009 21:05:18 -0700

> Then I'll describe what I think we'll lose by going to that  

Given that i= is an arbitrary value assigned by the signer, the  
question to me is what value does it add beyond what signed RFC2822  
headers can do just as well. Eg, why not set an rfc2822.Sender Field  
and sign that rather than invent i=?

IOW, what is the value-add in inventing yet another identity called  
DKIM.i= when we already have rfc2822.From, rfc2822.sender,  
rfc2822.resent-from, rfc2822.resent-sender and rfc2821.mailfrom?

Are you suggesting that DKIM.i= should have preference over signed  
RFC2822 identifiers?

Mark.

---

From: Hector Santos <[email-masked]>
Date: Sat, 28 Mar 2009 06:06:03 -0400

> Are you suggesting that DKIM.i= should have preference over signed  
Good points Mark.

I think it may help if we can take a (small) step back into the 
balcony, to better understand what ADSP was designed to over.

Without getting into details, can we summarize what the goals of ADSP are?

 From my POV, I see three goals:

   1) Provide a 1st party signature requirement authority.

   2) Provide a new technical (and indirectly legal) justification
      for the discarding of SMTP accepted message.

      RFC 5321 has  new semantics which relaxes the several decade old
      tradition of requiring a bounce notification. Prior specs
      did not have this relaxation.  See RF5321 6.2.

      For systems that are planning to process DKIM online
      (at DATA stage), this was never an issue.  ADSP will
      help systems that always accept mail and process in
      in a delayed fashion.

   3) Lay the framework for future more advanced (beyond goal 1)
      policy mechanisms, including 3rd party signatures.

It would of been my preference to see a simple YES/NO "Allow 3rd 
party" signature policy that might cater to email services like
gmail.com which allows non-gmail but verified author from addresses
to be used with d=gmail.com signings.

Personally, the ADSP response is to light. If people are concern about 
too many ADSP queries, then at the very least give it more data to be 
returned that can be useful.   I don't think we can cover all 3rd 
party scenarios, but a simple 3rd party policy with a tag contains X 
limited domains would be very useful.

     DKIM=DISCARDABLE; 3PS=gmail.com, mipassoc.org

that will say that all my winserver.com mail will be signed either by 
one of the following domains:

     d=winserver.com  (default signer based on from.domain)
     d=gmail.com
     d=mipassoc.org

I doubt a major amount of the domains will ever need more than 512 
bytes yet alone 80 or 160 bytes! But even so, for these rare larger 
needs, DNS is designed to handle a streaming request when needed.

No "opague" i= to confuse what is being attempted and valid signatures 
will probably still need reputation and trust services.  Good 
signatures is not enough to trump security.

But this will at least allow for a good segment of market to use DKIM 
in 1st and 3rd party authorized manner.

Its not ideal, but I think it would be better what we have now with 
ADSP which is so limited even the authors believe its worthless.

Well, lets get it some reason to exist.

-- 
Sincerely

Hector Santos

---

From: Hector Santos <[email-masked]>
Date: Sat, 28 Mar 2009 06:38:27 -0400

> lost and I'm not sure we have enough experience to say that we don't

I think these are addressed with an ADSP "valid signer domains" tag.

The only reason I recall for ditching this "list" idea in SSP was the 
concern it can become large.

Well, honestly, if a domain was seriously interesting in controlling 
who signs but has needs for additional signers, I seriously doubt most 
of these domains will ever need more than X amount (or bytes worth), 
whatever that value is.  Even then, such a domain what main signer 
needs, probably can still create extra records for more domains,

I think the benefits of this idea cover the needs of a much greater 
majority of domains in the network who would never have more than a 
small X amount of signers.

Plus, we can leave it open future exploration such as allowing for for 
URN reference syntax to much larger list.  I think this will be so 
limited, but who knows.

I think we have one shot at this ADSP thing in this WG to get a RFC to 
help compliant greater acceptance of DKIM).  But some people already 
believe its worthless.  Well, sure. It was watered down so much, it 
values was reduced drastically.  Yet, as we witness, the 3rd party 
issue still can not be eliminated.  The needs are very apparent. But 
now it seems we want to get rid of that too in the name of simplicity 
and rubber stamping this document.  I propose to give it some value 
and reason to exist by reintroducing the signer list idea that 
resolves the design people were attempting with i= for 3rd party signers.

-- 
Sincerely

Hector Santos

---

From: John Levine <[email-masked]>
Date: 28 Mar 2009 11:41:09 -0000

>Signatures. ...

>mailing list manager operating in that domain. ...

This, along with a lot of the i=/g= stuff, all strikes me as
attempting to address the same problem, overloading signing keys.  The
reasonable solution to both of these issues is to sign in different
domains.  For #1, sign with the same domain as the author, for #2, if
your list software doesn't control its traffic well enough to be
confident that it's not going to be spoofed, sign list mail with a
different d= domain.  (That's what I do.)  As Steve Atkins recently
pointed out, the d= domain doesn't even have to exist other than as
the key records.

I realize there are organizations with uncooperative DNS managers who
make it hard to install the key records needed. I wouldn't be
surprised if some of us even work at such organizations.  But a local
optimization that ends up demanding extra work from the rest of the
world to work around one's DNS management is, to put it mildly, not a
great idea. If DKIM is going to be deployed, part of the deployment
will be to figure out how to get the required records installed. 

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Sat, 28 Mar 2009 11:20:43 -0700

On Mar 27, 2009, at 9:05 PM, Mark Delany wrote:
>> alternate definition of Author Signature based on the d= value  
>> only. Then I'll describe what I think we'll lose by going to that   
>> definition.
>
> headers can do just as well. Eg, why not set an rfc2822.Sender  
> Field  and sign that rather than invent i=?
>

Yes.  The RFC2822 may not be restricted.  The i= value may match  
against these email-addresses within signed headers.  The i= value may  
also represent a private namespace that represents accounts granted  
access.  These accounts might not restrict email-addresses used within  
the signed headers.  In either case, the i= value when present  
provides assessors a means to track accounts granted access.  Without  
this ability, IP address associations will likely be needed to  
mitigate replay abuse.  The use of IP addresses to mitigate replay  
abuse in not preferred, nor likely robust in dealing with CGNs and the  
like.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Sat, 28 Mar 2009 11:34:36 -0700

> Are you suggesting that DKIM.i= should have preference over signed

Not at all.  Signing a particular header field doesn't have any
semantics for DKIM other than to make sure that it doesn't change
between the signer and verifier.  In other words, signing the
rfc2822.Sender field doesn't change the meaning of the signature a bit. 
It just makes sure that a man-in-the-middle hasn't changed that header
field, potentially in a deceptive way.

The "signing identity", i=, is already in the DKIM specification and
isn't a new invention of ADSP.  It doesn't take precedence over signed
RFC2822 identifiers, although there is a suggestion in RFC4871 section
6.3:  "If the message is signed on behalf of any address other than that
in the From: header field, the mail system SHOULD take pains to ensure
that the actual signing identity is clear to the reader."  I take this
as a suggestion to display it in addition to the 2822 From address.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Sat, 28 Mar 2009 11:39:18 -0700

> I think these are addressed with an ADSP "valid signer domains" tag.

I'm sorry, Hector, I really don't see the relationship between the
choice d= and i= values as having anything to do with the "designated
signing domains" (I think it was called) proposal.

> concern it can become large.

That was one reason, but there was working group consensus not to pursue
that idea and I'm fairly sure it's not the Chairs' intent to reopen
other issues that already have been decided by rough consensus.

-Jim

---

From: Hector Santos <[email-masked]>
Date: Sun, 29 Mar 2009 00:05:30 -0400

> other issues that already have been decided by rough consensus.

Thanks Jim. I appreciate the feedback.

-- 
Sincerely

Hector Santos

---

From: Eliot Lear <[email-masked]>
Date: Sun, 29 Mar 2009 08:55:09 +0200

John,

I think we're rehashing an earlier debate, but...

> will be to figure out how to get the required records installed.

This isn't quite a fair characterization.  It's not *just* uncooperative 
DNS managers, but software limitations, differing budget lines, actual 
distinct operating entities where DNS is offered as a service, etc.  I 
would expect that this problem is likely to persist in nearly every S&P 
500 company, a number of governments and educational institutions.  So 
when you call this a 'local optimiziation', maybe it is true in the 
academic sense, but the scope of the locality is quite large.

Eliot

---

From: Hector Santos <[email-masked]>
Date: Sun, 29 Mar 2009 07:22:18 -0400

> academic sense, but the scope of the locality is quite large.

+1, I think it isn't as much as being uncooperative but lack of 
understanding, the unsureness to commit, the cost prospects. DKIM 
seems so pathetically simple, yet beyond understanding but by only a 
small set of people. It is both an expensive project and product 
engineering effort. Never mind the selling of it isn't so cut and dry 
either.  At this past IETF meeting, I joined the WebEx meeting with 
the audio streaming, and I also invited two customers who have 
expressed interest in DKIM listen in as well.  You don't want to hear 
the comments one of them gave to me, and the other (an IT manager of a 
major store chain anyone with kids have visited) decided right then 
and there DKIM is not ready and had doubts it will ever be ready.

Part of the problem is that it hard to see what does it solve as it 
currently define.  What problem does it address?  DKIM lacks a sound 
description for what is the payoff. The term "responsibility" is, 
well, quite flaky and for managers that have concerns with product 
liability, using the term responsibility raises questions.  It creates 
some confusion about who owns want and what responsibility means.  I 
don't think this is a term that can intently left ambiguous. I believe 
it has lowered the incentive to implement, like maybe putting in the 
effort to write the DNS management component that is so necessary to 
get this right with customers.  When one begin to get serious about 
looking at DKIM, like John pointed out here and in the DKIM-OPS list, 
the issue of how to get DNS records added/updated in "easy" fashion 
becomes rather apparent.

If DKIM does take off en masse (widely), of course we would like the 
ISPs with their current DNS Web Management tools to add DKIM key 
generation support  But thats a manual process. DKIM needs automated 
updating concepts.  Its not like SPF where you essentially do it once 
and you're done.

It may end up as one solution by a "DKIM provider" to have their 
customers install special DKIM/DNS clients on their computers, pretty 
much like a DNS2GO service and others like it that allows secured 
automated updating of records on the vendor DNS server.

In fact, I can see an I-D to help provide a guideline for  DKIM/DNS 
Record Management, summarizes the issues, the current tools and 
methods, update protocols and to maybe lay the groundwork for 
developing consistent automated tools.

I also see an I-D that isn't as abstractly detailed as the deployment 
guide that helps with migration.  For example, a SMTP vendor can add 
ADSP/DKIM verification support before it can properly offer DKIM 
signing support.

Our migration plan was always to do:

    1 - POLICY first at some basic level
    2 - DKIM VERIFICATION 2ND
    3 - DKIM SIGNING

In my technical opinion, policy helps justify the verification. 
Without policy, its becomes a little harder to accept. Something has 
to provide a valid reason to do this verification overhead.

The signing is the hardest part because for us, it will require a 
revamp consideration of many parts. Some parts we can get rid, but 
nonetheless an expensively project to commit to.  I'm sure its not an 
issue for the Big Bucks people here, but it is for me and and don't 
wish to speak for others, other smaller systems and vendors isn't 
going to have a easy time as well. <g>

-- 
Sincerely

Hector Santos

---

From: Douglas Otis <[email-masked]>
Date: Sun, 29 Mar 2009 23:55:17 -0700

On Mar 28, 2009, at 11:34 AM, Jim Fenton wrote:

> rfc2822.Sender field doesn't change the meaning of the signature a  
> bit. It just makes sure that a man-in-the-middle hasn't changed that  
> header field, potentially in a deceptive way.
>
> isn't a new invention of ADSP.  It doesn't take precedence over  
> signed RFC2822 identifiers, although there is a suggestion in  
> RFC4871 section 6.3:  "If the message is signed on behalf of any  
> address other than that in the From: header field, the mail system  
> SHOULD take pains to ensure that the actual signing identity is  
> clear to the reader."  I take this as a suggestion to display it in  
> addition to the 2822 From address.

Email-Address annotations should require the RFC5322 identity to  
explicitly matching against the i= value.  In other words, with  
respect to message email-address annotation, the i= value determines  
which RFC5322 signed header field represents the on-behalf-of  
identifier that might be annotated and serve as an intra-domain  
reputation identifier.  When the i= value does not match against  
against an RFC5322 identity, it represents just an intra-domain  
reputation identifier that should not be displayed because it is not  
defined as representing a real identifier.  This identifier would only  
provide a means to mitigate intra-domain abuse.

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 30 Mar 2009 11:10:52 +0100

> lost and I'm not sure we have enough experience to say that we don't

I don't think that is quite right. Suppose foo.example has declared that  
it signs everything, with strength "Discardable". Then four possibilities  
arise:

From: [email-masked]            From:[email-masked]
Valid signature from foo.example     Absent/broken signature from  
foo.example
       ACCEPT                               DISCARD

 From [email-masked]             From [email-masked]
Valid signature from foo.example     Absent/broken signature from  
foo.example
       ???????                              ????????

The first two cases are obvious. The second two are Jim's example. What to  
do?

I think he misunderstands the meaning of "Discardable". It does not mean  
"Everything we sign if From: us". It means "Everthing From: us is signed  
by us".

So, in the second two cases, the semantics already prescribed by ADSP is:

Assuming there is no second signature by bar.example, LOOK UP the ADSP  
record for _bar.example_, and if that says "Discardable" then DISCARD it.

IOW, if some user at a Discardable domain sends email to a list, it had  
better be signed before it reaches the list, and the list expander had  
better not break that signature.

But if the Discardable domain operates a list expander for a list that  
anyone may post to, then it will naturally sign the expanded messages (and  
it would be polite to add i=[email-masked]), but there is no  
implication that anything should or should not be Discarded (though  
perhaps Assessors might possibly do so if Sender: was not by that domain -  
list expanders being supposed to set Sender).

> In the words of Dave Crocker,

FX: Bang!

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: [email-masked] (Wietse Venema)
Date: Mon, 30 Mar 2009 08:29:29 -0400 (EDT)

Charles Lindsey:
> Valid signature from foo.example     Absent/broken signature from foo.example
>        ACCEPT                               DISCARD

Right.

> Valid signature from foo.example     Absent/broken signature from  

ADSP is about first-party signatures. The above are not, thus
the discard rule applies. See draft section 2.7.

	Wietse

---

From: Hector Santos <[email-masked]>
Date: Mon, 30 Mar 2009 09:41:18 -0400

Right.

> better not break that signature.

Which is a touch issue.  But there are some practical considerations.

First, the user with a DKIM=ALL and DKIM=DISCARDABLE policy will be 
acting irresponsible if he selected this mode and continue to push 
mail into areas historically known to break the integrity of mail.

Second the list server should add ADSP checking into the current
subscription email verification process.  It should reject subscribing 
domains with DKIM=ALL|DISCARDABLE.  This will make it protocol 
consistent and will help protect the domain.

Hate to rehash, but it would of helped if ADSP allowed a DKIM=ANY 
which allows for any one to signed.

ADSP should not have written with an mutual exclusive ALL or 
DISCARDABLE.  DISCARDABLE should of been a policy attribute.

     DKIM=UNKNOWN | ALL | ANY [, DISCARDABLE ]

with the optional discardable attribute meaning one thing:

     No failure tolerated. Please Discard!

With DKIM=ANY (always signed by anyone), it would of allowed domains 
who use trusted services to sign on their behalf.

This would make it work better for list servers like this one, and 
systems like gmail.com what also signs mail with d=gmail.com.

> list expanders being supposed to set Sender).

I still don't get the i= thing.  I guess if a signer wants to add it, 
so what. Its part of the signature and if an accessor wants it, pass 
it and let it do what it like with it.

-- 
Sincerely

Hector Santos

---

From: DKIM Chair <[email-masked]>
Date: Mon, 30 Mar 2009 14:02:01 -0400

I don't mean to stop the discussion that's going on; if y'all want to have this, 
'round and 'round again, it's OK with the chairs.

That said, the discussion doesn't look like it's going to answer the questions we 
need to sort out by Friday, so let me try to nudge things a bit.

Jim has proposed text to address the point we need consensus on.  John has told 
me, off list, that he also has some text -- John, will you either agree to Jim's 
text or post your own for debate, please?

What we need to do by the end of the week is this:

1. Decide whether the gist of Jim's proposal is something we can accept, whether 
or not it would be our first preference?  John, for example, has said that it's 
not his preference, but he considers it "harmless", and, therefore, acceptable.

1.5. For those who think we really need ADSP to use i= or something like it, can 
you *accept* taking i= out for now, in the interest of moving ahead with the 
spec, possibly to add i= or something like it back in through an extension later 
if experience shows us that you're right?

2. Decide whether Jim's text, specifically, is what we want to go with, or 
whether we want to change it.  Item 1 is really what has the Friday deadline -- 
the chairs will be happy if it takes a little longer to settle on the exact text, 
as long as no one's using that as a ploy to buy extra time.

Carry on....

Barry

---

From: John Levine <[email-masked]>
Date: 30 Mar 2009 21:31:10 -0000

My version is pretty similar to Jim's first two paragraphs.

>not signed by the same domain.

Those are fine.

>"i=" to assert that a parent domain is signing for a subdomain.

That's not fine, since we've just gone around and agreed that the
signing identity is d=.  leave this paragraph out.

R's,
John

---

From: Jim Fenton <[email-masked]>
Date: Mon, 30 Mar 2009 15:08:11 -0700

> signing identity is d=.  leave this paragraph out.

I'm not sure what you think we have agreed, but the current (-09) ADSP
specification has an informative note pointing out incompatibility of
that version of ADSP with "valid DKIM usage" that isn't explicitly
mentioned in RFC 4871.  Since RFC 4871 does, explicitly, mention this
mode of usage of DKIM we really do need this informative note.

Or, we could just go with the -09 language, which I would prefer anyway.

-Jim

---

From: "John R. Levine" <[email-masked]>
Date: Tue, 31 Mar 2009 00:02:54 +0100 (BST)

> mentioned in RFC 4871.

Right, I wrote that note to point out fundamental breakage in the -09 
version of ADSP.

> Since RFC 4871 does, explicitly, mention this

This strikes me as gratuitously confusing, but I don't care enough to 
argue about it.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Mon, 30 Mar 2009 17:34:05 -0700

On Mar 30, 2009, at 2:31 PM, John Levine wrote:
>> domains described in section 3.8 of [RFC4871] in which a signer  
>> uses "i=" to assert that a parent domain is signing for a subdomain.
>

John is correct.  ADSP is not about receivers limiting what part of a  
domain's namespace can be signed.  ADSP should be about whether a  
signature is at or above the email-address domain.

When the i= value offers intra-domain tokens, rather than real email- 
addresses matching within a signed header fields, avoiding accidental  
namespace collisions would be desired.  Avoidance can be assured by  
using non-existing sub-domain labels.  The intent behind the ADSP  
change is to eliminate any restriction imposed by receivers on what  
part of a domain's namespace, (real or fictitious) provides a valid  
signature.

Allow DKIM to determine what is a valid signature.  The i= value does  
not need to represent a valid email-address to be useful.  By  
requiring just the domain, domains retain control over all their  
namespace at or below their domain.  ADSP currently allows domains to  
sign any sub-domain as long as it matches against the i= value.  The  
only i= value exposure is related to g= key restrictions where DKIM  
still mandates the use of specific i= values.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Mon, 30 Mar 2009 22:13:41 -0700

> Valid signature from foo.example     Absent/broken signature from  

The second two cases are not my example.  Concern #2 in my message has
to do with messages where the signing address is a different address in
the same domain as the From address.  The correct test case is:

>From [email-masked]
Valid signature from [email-masked]

Let's also use "all" instead of "discardable" as the test case because
it's the harder problem to solve.  As you point out, the mailing list
should be acting on the Discardable practice rather than trying to send
the message to the list.

Let's say that [email-masked] is a mailing list that re-signs
mail sent to the list (or it could be a forwarder or similar agent). 
foo.example's mail server gets a message from an address in the same
domain, [email-masked], that has no Author Signature or has a
broken one.  In accordance with the domain's policy, it subjects the
message to additional scrutiny because of the "all" practices and lack
of an Author Signature.  The message passes this test and is sent to the
mailing list manager.

At this point, the mailing list manager would normally sign the
message.  Let's examine this with the i= and d= choices:

Using i= as the basis for Author Signature, the list can sign the
message, and the eventual verifier/assessor that does an ADSP check will
see that it (still) lacks an Author Signature since
[email-masked] does not match [email-masked].

Using d= as the basis for Author Signature, if the list signs the
message, an eventual verifier/assessor will erroneously see that
signature as an Author Signature, and therefore might not give the
message the desired treatment.  Another option would be for the mailing
list manager not to sign this message, which means it needs to do a
special case not to sign messages if they're from the same domain and
lack an Author Signature.  This is certainly possible, but would be more
challenging if the MTA manages many domains.  I also think it's the
wrong place to solve the problem.

It's up to the WG to decide whether this is a problem that deserves a
solution or whether it's too much of a corner case to bother with
(mailing list manager with users in the same domain that uses
ADSP=all).  I do not like the idea of "just change someone's domain" or
"just change the list's domain" because it has always been DKIM's goal
to operate with existing addresses.

Hopefully this clarifies the test case so that this can be evaluated fairly.

-Jim

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 31 Mar 2009 11:25:38 +0100

On Tue, 31 Mar 2009 06:13:41 +0100, Jim Fenton <[email-masked]> wrote:

> broken one. ...

But how come it had no Author signature? Presumably because it arrived  
over some internal LAN, and internal mail is not signed (or all signing is  
done at the point where mail is finally dispatched to the Big Wide World  
outside).

> ...  In accordance with the domain's policy, it subjects the

So the mailing list manager, or some agent just prior to it, has satisfied  
itself that it was a valid message from [email-masked] (hence no  
reason not to send it out to the mailing list).
> [email-masked] does not match [email-masked].

But we are agreed that (at least for now) we don't use i= as the basis for  
Author Signature. The mailing list expander may well add  
i=[email-masked], but that is just so humans (and maybe some  
super-smart Assessors) can observe what has been happening. But, for  
normal Assessors, that i= is just "opaque" stuff that it can ignore.
> message the desired treatment. ...

Why ever not? It is From: [email-masked]. The agent that signed it  
has already satisfied itself that it is genuine ("additional scrutiny"  
maybe), and it is signed with d=foo.example. It looks like a Author  
Signature, it quacks like an Author Signature, therefore it IS an Author  
Signature. Subsequent Assessors should be perfectly happy to accept it  
(whether the ADSP for foo.example is "All", "Discardable", or anythng  
else).

So where is your problem?

> ...  Another option would be for the mailing

Why should that be? It is either signed by the mailing list manager, or it  
is signed by the outgoing gateway to the Big Wide World, or maybe both. So  
who cares? Either way, it is sufficiently well signed for it to be  
acceptable everywhere.

I just don't see what your problem is.

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 31 Mar 2009 11:01:34 +0100

> the discard rule applies. See draft section 2.7.

Indeed, but it is the signing policy of bar.example (as opposed to  
foo.example) that would have to be applied.

---

From: John Levine <[email-masked]>
Date: 31 Mar 2009 10:57:20 -0000

> Let's say that [email-masked] is a mailing list that
> re-signs mail sent to the list (or it could be a forwarder or
> similar agent).

 [ same old example of lists and individuals sharing a domain ]

It's the same old answer, if the list is a different mailstream,
use a different signing key.  We could also argue about the wisdom
of a domain publishing dkim=all when it knows that its users send
mail through lists and forwarders that are likely to break the
signature.

> I do not like the idea of "just change someone's domain" or "just
> change the list's domain" because it has always been DKIM's goal to
> operate with existing addresses.

Nobody I know is suggesting that. You use a different d= signing
domain for the mailing list mail.  As Steve Atkins recently pointed
out, the signing domain doesn't even have to exist other than the key
record, so this requires one (1) extra TXT record in the DNS.  It
doesn't strike me as a good idea to require extra complexity in the
design for the benefit of signers whose DNS ops are willing to publish
one key record but not publish two key records.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Tue, 31 Mar 2009 07:11:37 -0400

> Hopefully this clarifies the test case so that this can be evaluated fairly.

Well, I'm afraid not because they appears to be different motives.

You indicate the goal is basically to make this a plug and play 
technology and thats totally conflictive with any, and I mean any, 
mail integrity technology.  I don't think you can have it both ways.

What you are asking, I think, is the same old question that we put 
forth what 2?  3? years? ago?

     Why would you care if a original signature was broken as long
     as it was fixed up with a resigning (by a GOOD GUY presumingly)?

In other words, the source of the signing was not the problem. As long 
as it was a good guy, trusted, why should it matter if the author 
signature was redone by middle ware?

The motive of one side, thats ok.  The other side saying - no, its not ok!

As I see it, that was the dilemma in all this.

In my view, any technology that is relaxed, like a DKIM=ALL policy is 
inherently prone to problems.  So I don't see why we should expect any 
less.

Sure, you or the chairs don't want to rehash some of these, but I 
think we need clear concise policy language, and that might mean the
following:

1) Change DISCARDABLE to a policy attribute. Don't make it a mutually 
exclusive concept.

2) Offer simple policies that MATCH current expected reality:

   DKIM=UNKNOWN|ALL|ANY [, DISCARDABLE]

   UNKNOWN is the default policy (implicit or explicit)
   ALL is always sign with AUTHOR SIGNATURE
   ANY is always sign by AUTHOR SIGNATURE or D= or I= only

   DISCARDABLE would be an attribute that provides technical
   authority by the domain to the receiver to discard any
   fault in the signature. In other words, the author domain
   has no tolerance for DKIM signing failure and expects
   the mail to be discarded because they are not assuming
   responsibility for it.

So if people want to rubber stamp this ADSP and ignore all these key 
concerns, well, its your ball.

For me, I am a bottom line person. Do it right. I think the above is a 
simple compromise and addresses what we are talking about.  In all 
this, we can't ignore that the Author Domain wishes are and it pretty 
strange to me that they will sign mail only, dump it to some unknown 
arena and don't care its broken and/or resigned by others.  Very odd 
consideration when you are taking about mail integrity concepts.

Finally, we still need to use the reputation, local or remote 
assessors, that isn't remove from any of this.  But we are trying to 
use reputation was a way to solve this question versus simple 
self-asserting policies.

-- 
Sincerely

Hector Santos

---

From: Douglas Otis <[email-masked]>
Date: Tue, 31 Mar 2009 09:37:05 -0700

On Mar 30, 2009, at 10:13 PM, Jim Fenton wrote:

> Concern #2 in my message has to do with messages where the signing  
> address is a different address in the same domain as the From  
> address.  The correct test case is:
>
>> From [email-masked]
> Let's also use "all" instead of "discardable" as the test case  
> because it's the harder problem to solve.  As you point out, the  
> mailing list should be acting on the Discardable practice rather  
> than trying to send the message to the list.

It should not matter whether "all" or "discardable" is used since the  
signature has been applied by the correct domain.

> Let's say that [email-masked] is a mailing list that re- 
> signs mail sent to the list (or it could be a forwarder or similar  
> agent).  foo.example's mail server gets a message from an address in  
> the same domain, [email-masked], that has no Author Signature  
> or has a broken one.  In accordance with the domain's policy, it  
> subjects the message to additional scrutiny because of the "all"  
> practices and lack of an Author Signature.  The message passes this  
> test and is sent to the mailing list manager.

A best practice should only annotate full email-addresses when  
included within the i= value.  In the case of the mailing-list, "[email-masked] 
" has a valid author signature (one by the correct domain), but the i=  
value does not affirm that the signature was added on behalf of the  
author.  Normal semantics established for all DKIM signatures will  
differentiate these two message sources.

> message, and the eventual verifier/assessor that does an ADSP check  
> will see that it (still) lacks an Author Signature since [email-masked] 
>  does not match [email-masked].

This would be wrong.  The Author Signature should only require a  
signature by the correct domain, and then expect the receiver to  
depend upon the i= value to differentiate on whose behalf the message  
was signed.

> message the desired treatment.

The desired treatment is always under the control of the signing  
domain.  The domain retains control when limiting valid "author  
signatures" to being by domains at or above the email-address domain.

> Another option would be for the mailing list manager not to sign  
> this message, which means it needs to do a special case not to sign  
> messages if they're from the same domain and lack an Author  
> Signature.  This is certainly possible, but would be more  

The cleanest solution would be for the mailing-list to include  "i=[email-masked] 
" rather than "i=[email-masked]".  An assessor can easily  
determine that the message was on behalf of the mailing-list rather  
than someone at "foo.example.com".   There does not appear to be any  
problem not handled by existing DKIM semantics.

> It's up to the WG to decide whether this is a problem that deserves  
> a solution or whether it's too much of a corner case to bother with  
> ADSP=all).  I do not like the idea of "just change someone's domain"  
> or "just change the list's domain" because it has always been DKIM's  
> goal to operate with existing addresses.

There does not appear to be any corner case?

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Tue, 31 Mar 2009 09:30:33 -0700

> done at the point where mail is finally dispatched to the Big Wide World  

Perhaps that was the reason, but it could be a lot of things.  The
notion of "internal" is becoming harder and harder to define.

Right.

> normal Assessors, that i= is just "opaque" stuff that it can ignore.

Go back and look at the message from the Chair that started this
thread.  I had thought that we were debating the merits of the current
wording vs. an alternative that I offered that replaces the definition
of Author Signature and that means we're still discussing i= vs. d= as a
basis for Author Signature.

> So where is your problem?

My problem is that the semantics of the signature that the mailing list
applies shouldn't depend on whether the original author happens to be in
the same domain as the list.

> who cares? Either way, it is sufficiently well signed for it to be  

Perhaps.  Or the eventual verifier/assessor may have different criteria
that it uses to evaluate messages from ADSP=all domains that don't have
valid author signatures.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Tue, 31 Mar 2009 11:17:03 -0700

On Mar 31, 2009, at 9:30 AM, Jim Fenton wrote:
>>
>> Why ever not? It is From: [email-masked]. The agent that  
>> signed it has already satisfied itself that it is genuine  
>> ("additional scrutiny" maybe), and it is signed with d=foo.example.  
>> It looks like a Author Signature, it quacks like an Author  
>> Signature, therefore it IS an Author  Signature. Subsequent  
>> Assessors should be perfectly happy to accept it (whether the ADSP  
>> for foo.example is "All", "Discardable", or anythng
>> else).
>>
> My problem is that the semantics of the signature that the mailing  
> list applies shouldn't depend on whether the original author happens  
> to be in the same domain as the list.

It does not.  It would only require assertion of  i= values.

>>> ...  Another option would be for the mailing list manager not to  
>>> sign this message, which means it needs to do a special case not  
>>> to sign messages if they're from the same domain and lack an  
>>> Author Signature.  This is certainly possible, but would be more  
>>> challenging if the MTA manages many domains.  I also think it's  
>>> the wrong place to solve the problem.
>>
>> Why should that be? It is either signed by the mailing list  
>> manager, or it  is signed by the outgoing gateway to the Big Wide  
>> World, or maybe both. So who cares? Either way, it is sufficiently  
>> well signed for it to be acceptable everywhere.
>
> Perhaps.  Or the eventual verifier/assessor may have different  
> criteria that it uses to evaluate messages from ADSP=all domains  
> that don't have valid author signatures.

When the definition of valid Author Signature only considers whether  
the signature is by the correct domain, then these signature would be  
compliant with ADSP.  By asserting the i= values, when MUAs or  
assessors attempt to annotate sources, it could annotate "Sender:[email-masked] 
" rather than "From:[email-masked]".  The change in Author- 
Signature definition will not obscure where the message originated as  
long as the signer asserts i= values.  Such assertions are  controlled  
by the signing domain.

The change requires the receiver (assessor or MUA) to depend upon  
current DKIM i= value semantics for annotations, while also  
eliminating double signing to be ADSP compliant where one signature is  
on-behalf-of the "[email-masked]" and the other leaves  
the i= value at its default.

-Doug

---

From: John Levine <[email-masked]>
Date: 31 Mar 2009 23:36:44 -0000

>to be in the same domain as the list.

Of course.  That's why list mail should use a different signing
domain.  It's clearly a poor idea to sign mail from lists that have
contributors in multiple unknown domains with a d= that has an ADSP
assertion

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Tue, 31 Mar 2009 17:33:27 -0700

On Mar 31, 2009, at 4:36 PM, John Levine wrote:

>> list applies shouldn't depend on whether the original author  
>> happens to be in the same domain as the list.
>

There still does not seem to be a problem.  A DKIM signature allows  
source differentiation.

d= foo.example.com
i=[email-masked]

  - versus -

d= foo.example.com
i=[email-masked]

  - or -

d= foo.example.com
and no i=

The foo.example ADSP assertion "all" only determines whether the  
domain's messages are initially signed.  The i= value must still be  
used to differentiate messages emanated by the mailing-list or by some  
user within the domain.  When the i= value is allowed to default, the  
intra-domain source of the message can not be determined.   What  
problem specifically is created or what exploit risk does this create?

-Doug

---

From: Barry Leiba <[email-masked]>
Date: Tue, 31 Mar 2009 22:05:45 -0400

> There still does not seem to be a problem.  A DKIM signature allows

I'm enjoying this whole discussion, and I think it's productive.
Can we draw in the WG participants who haven't yet commented on this?
I'd like to hear your opinions too, and get your ideas on how you'd
like to see this question resolved.

Barry