Subject: Re: [ietf-dkim] Consensus point on ADSP

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 01 Apr 2009 10:18:49 +0100

On Tue, 31 Mar 2009 17:30:33 +0100, Jim Fenton <[email-masked]> wrote:

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

BUT IT DOESN'T!

I am perpetually amazed that people on this list still seem to have no  
idea of how ADSP is supposed to work. They seem to think that the ADSP  
record is somehow related to the domain in the d= of the signature. IT  
ISN'T!

It is primarily related to the domain in the From: header.

The existence of an ADSP record states that "If you see this domain in the  
From: header of any email, you should expect to see also a valid signature  
with this same domain in its d= (and maybe we also invite you to discard  
it if such a signature is absent)".

So if a particular mail happens to have foo.example in its From: header,  
and has also been forwarded to a list by that same domain, then WHO CARES  
whether the signature was put there by the mailing list expander, or by  
the normal signing machine for that domain (maybe it had even acquired two  
signatures, one from each and both using the same key)? IT DOESN'T MATTER,  
since it is amply proved to be a genuine message vouched for by that  
domain.

Whether smart Assessors or smart humans choose to look at any i= that may  
be present and may indicate whether the actual signature was put there by  
the mail-list machinery or not is a minor secondary issue. Again, WHO  
REALLY CARES?

So I still don't see that you have raised an actual problem.

-- 
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: Barry Leiba <[email-masked]>
Date: Wed, 1 Apr 2009 11:06:47 -0400

Jim says...
>> the same domain as the list.

Charles says...

>From separate conversations with Jim, I see this as the central point
of disagreement.  It's the question of whether the signatures relate
*only* at the domain level, or whether there's a concept that the
domain signs "on behalf of" an entity.

Mostly, I agree with the side of the discussion that says it's just
the domain, so don't worry.  But DKIM does make a nod to the other
side by suggesting that the domain, when signing, might consider what
it knows about the actual sender.  In RFC 4871, section 5.1; note the
last clause:
      INFORMATIVE NOTE: Signing modules may be incorporated into any
      portion of the mail system as deemed appropriate, including an
      MUA, a SUBMISSION server, or an MTA.  Wherever implemented,
      signers should beware of signing (and thereby asserting
      responsibility for) messages that may be problematic.  In
      particular, within a trusted enclave the signing address might be
      derived from the header according to local policy; SUBMISSION
      servers might only sign messages from users that are properly
      authenticated and authorized.

In a situation where, say, the domain chose not to sign the message
submitted by the original user, but did choose to sign the copy
forwarded by the mailing list.  Then you'd trip over the problem that
Jim's concerned about.

You might say that in that case, "the mailing list shouldn't sign the
message," since it wasn't signed before.  But the mailing list isn't
signing the message -- the domain is.  The domain might say that the
mailing list is properly authenticated and authorized, so I sign.  And
the mailing list may have no way to vet the original sender, one way
or the other.  Should *it* behave differently when the sender who's
posting is in the same domain than it does when the sender is not?

I do see the issue.

That said, I think it really is out of DKIM's scope, and I don't see
it as a problem with DKIM.  It's one of the examples that makes the
whole issue of authentication and mailing lists problematic, whatever
authentication mechanism you use.

My opinion, as a participant, is that this case isn't a compelling
reason to keep i= in ADSP, and that *if* we need to address this case
in the real world (which I don't think we do), we should consider it
later, when we have more experience and a better idea of how we might
deal with it properly.

Barry (as participant)

---

From: Douglas Otis <[email-masked]>
Date: Wed, 1 Apr 2009 10:02:32 -0700

On Apr 1, 2009, at 8:06 AM, Barry Leiba wrote:

> You might say that in that case, "the mailing list shouldn't sign  
> the message," since it wasn't signed before.  But the mailing list  
> isn't signing the message -- the domain is.  The domain might say  
> that the mailing list is properly authenticated and authorized, so I  
> sign.  And the mailing list may have no way to vet the original  
> sender, one way or the other.  Should *it* behave differently when  
> the sender who's posting is in the same domain than it does when the  
> sender is not?

A DKIM signature within a message will not offer information without a  
validation process.  Conveying validation information, as defined by  
the Authentication-Results header, includes whether the signature is  
valid, the d= and i= values.  Domains running a mailing-list at the  
same domain shared by their users will produce ADSP compliant messages  
for the mailing-list as well as all the users of their domain.  When  
their own mailing-list does not properly handle their domain's ADSP  
assertions, this can be remedied through the use of the i= values,  
even when only applied with mailing-list messages, such as "i=[email-masked] 
" where "[email-masked]" is the address for the mailing- 
list.

There is actually a benefit achieved by sharing the user domain with  
that of a mailing-list.  This mailing-list will produce ADSP compliant  
messages for users within the domain, where they would be disadvantage  
by a mailing-list at a different domain.  The only cautionary  
information that seems important in the case of sharing a domain with  
a mailing-list would be to ensure message compliance within the  
domain, or/and to assert the i= values for the mailing-list at least.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Wed, 01 Apr 2009 15:38:39 -0700

One more try to clarify things, then I'll stop trying.

> record is somehow related to the domain in the d= of the signature. IT  

If "people on this list" is referring to me, please say so.  I do not
think as you assert that ADSP is keyed to the d= of the signature.  That
wouldn't make sense, because ADSP has to function in the absence of any
[valid] DKIM signature.

> It is primarily related to the domain in the From: header.

If "primarily related to" means "you use the domain in the From: header
and look up the ADSP for that domain", yes.

> it if such a signature is absent)".

Go look at draft-ietf-dkim-ssp-09.  It doesn't say anything about using
d= in this way; it requires a valid Author Signature.  See section 2.7
for the definition of Author Signature, which involves comparing the
>From address and the i= address.

> So I still don't see that you have raised an actual problem.

So you're voting for the alternative that I posted the other day that
does the comparison with d= instead of i=.  Please correct me if I have
this wrong.

-Jim

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 02 Apr 2009 08:15:02 -0700

Jim Fenton wrote:
>      The correct test case is:
> 
>>From [email-masked]
> Valid signature from [email-masked]
...
> 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.  

I think there are two sources of confusion for this round of ADSP discussion.

The first is that the term "Author Signature" encourages one to think that DKIM 
is used to sign with the full author email address, rather than with the 
/domain/ of the author's address.  We fixed that error in the name of the 
document, but forgot to carry it through to the details of the spec.

DKIM is about domains, not email addresses.  And that's all ADSP should be. 
Using i= encourages this cofusion.  Using "Author Signature" rather than "Author 
Domain Signature" also encourages it.

The second is whether a receiver should be asked to enforce controls for usage 
by folks /within/ the originating domain's span of control.  It's one thing to 
worry about unauthorized use by someone /outside/ of the owning domain's 
control, but quite another to ask a receiving system to help keep the owning 
domain's own house clean.

If the domain owner cannot exert enough administrative control, to keep 
signatures for mailing lists separate from signatures for authors, then that's 
the owner's problem.  It shouldn't be the receivers.

The same applies for one author vs. another, within the same domain.

The specification and semantics of ADSP get simpler, cleaner and properly 
scoped, when d= is used.  Using i= really does invite a complex of issues that 
should be outside the scope of DKIM and ADSP.

Use d=.

d/

ps.  That includes dropping the "ADSP is incompatible" note.

-- 

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

---

From: "Siegel, Ellen" <[email-masked]>
Date: Thu, 2 Apr 2009 11:55:10 -0400

> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Dave CROCKER
> 
[> ] 

I think you may have put your finger on the root of much of the interpretation differences. It might in fact be a really good idea to replace the term "Author Signature" with the term "Author Domain Signature" throughout the ADSP spec to help address this. It seems like the only real "author signature" would be a PGP type signature that is truly attached by the author rather than by some part of the email infrastructure on behalf of the author. Since the validated signing identity can only be a domain, it's inherently misleading to use a signature label that implies otherwise. I think we've all agreed that the information in i= is an assertion made by the signing domain rather than a validated signing identity in its own right, so we should make the spec terminology agree with that clarification. That doesn't denigrate the usefulness of that assertion data to various consumers, it just clearly distinguishes it from the identity/identifier of the signing entity itself. 

> should be outside the scope of DKIM and ADSP.
[> ] 

+1

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Thu, 2 Apr 2009 21:33:06 +0530

On Thu, Apr 2, 2009 at 9:25 PM, Siegel, Ellen
<[email-masked]> wrote:

> I think you may have put your finger on the root of much of the interpretation differences. It might in fact be a >really good idea to replace the term "Author Signature" with the term "Author Domain Signature" throughout the >ADSP spec

+1

+1

-- 
Suresh Ramasubramanian ([email-masked])
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Thu, 2 Apr 2009 10:19:12 -0700

On Apr 2, 2009, at 8:15 AM, Dave CROCKER wrote:
> The first is that the term "Author Signature" encourages one to  
> think that DKIM is used to sign with the full author email address,  
> rather than with the /domain/ of the author's address.  We fixed  
> that error in the name of the document, but forgot to carry it  
> through to the details of the spec.

Agreed. :^)

> DKIM is about domains, not email addresses.  And that's all ADSP  
> should be.  Using i= encourages this cofusion.  Using "Author  
> Signature" rather than "Author Domain Signature" also encourages it.

Agreed.

----
Change:

1. Introduction:

This inquiry is called an Author Signing Practices check.

To:

This inquiry is called an Author Domain Signing Practices check.
----
Change:

Section 2.7 Author Signature.

To:

Section 2.7 Author Domain Signature.
----
Change:

An "author signature"

To:

An "Author Domain Signature"

Then:
s/author signature/Author Domain Signature/

> The specification and semantics of ADSP get simpler, cleaner and  
> properly scoped, when d= is used.  Using i= really does invite a  
> complex of issues that should be outside the scope of DKIM and ADSP.

Within the Security Consideration section, mention use of the i= could  
be required to differentiate intra-domain sources that might otherwise  
confuse From header fields as the message source, such as a mailing- 
list sharing the same domain.

Append to the initial paragraph within the Security Considerations  
section:

Use of the i= value (AUID) may be necessary to disambiguate message  
sources, such as those messages handled by a mailing list sharing the  
same domain.

> Use d=.

To determine ADSP compliance.  Agreed.

> ps.  That includes dropping the "ADSP is incompatible" note.

----
Strike the following in Section 2.7:

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

-Doug

---

From: Barry Leiba <[email-masked]>
Date: Thu, 2 Apr 2009 13:24:02 -0400

> Domain Signature" also encourages it.

Indeed.
As I recall, when we started this, both pre-IETF and bringing it into
the IETF, one goal was to allow, in the architecture, extension to
individual authors... but *not* to deal with individual authors at
this stage.  It was, in fact, one (of several) of the arguments about
why we couldn't just use S/MIME.

> the owner's problem.  It shouldn't be the receivers.

I agree.

Barry (participant)

---

From: Hector Santos <[email-masked]>
Date: Thu, 02 Apr 2009 14:37:35 -0400

Dave, I agree with all your comments here. +1, +1, +1, +1000, +1.

However, two comments:

1) I find it hard to believe, well, shocking, that we have gone around 
in circles just to come back to what the DKIM specification always 
was. It was always about the domain. We used terms as the originating 
domain.  The only tie-in to the local part was the From: header 
binding in the hash.  Then the word game began.......

2) I still have a concern with what I feel is a mindset that middle 
ware (namely mailing list server) can do what they please.  I think 
there are key people here that honestly believe this ASDP is all for 
nothing - waste of time because it does not jive well with the mailing 
list.  I always feel ADSP was too watered down by removing the the 
domain authorization to explicit expose a 3rd party signing allowance. 
   IMO, that is the reason we had this issue with d= and i=, and 
semantics of who signs what.

I think the often repeated point that domains need to take 
responsibility about how they will begin to use DKIM, especially those 
that want to use policies, is important. It is their problem. Yet by 
the same token. this also means the mailing list server needs to be 
more careful about signing mail as well.

For example, for our mail list server, there are three key software 
change considerations for DKIM + POLICY:

    - subscription, adding to a packages existing subscription
      confirmation a subscribing domain ADSP check for DKIM=ALL
      and DISCARDABLE policies.  The software SHOULD reject this
      subscriptions to protect the domain.

    - Periodic scanning the accounts to send notifications about
      ADSP protected domains that exist in the database.

    - Provide per member options such as:

         [_] Please don't sign my mail

The last one are for people who do not, nor wish to participate in 
supporting DKIM for whatever reason they might have.  I can forsee 
issues just like I have now with your list server "blinding" signing 
my mail as a 3rd party.  Out of laziness I have not unsubscribed yet 
but I should do so soon and just use my junk gmail.com account.

This is another reason why I think the lost of the "I NEVER SIGN" 
policy was a negative direction.  Until people are ready to sign, some 
domains will find it useful to add some reason that tells the 
receivers "Look, don't expect any signature from us, so if you see 
one, discard it."   Someone said, I think it was Eric, "Just add a 
NULL public key."   But when I repeated that here a few months ago, 
others said say "that won't work"  :-(

Other than that, +1.

-- 
Sincerely

Hector Santos
http://www.santronics.com

---

From: [email-masked] (Wietse Venema)
Date: Thu, 2 Apr 2009 16:46:18 -0400 (EDT)

Siegel, Ellen:
> I think you may have put your finger on the root of much of the
> interpretation differences. It might in fact be a really good idea
> to replace the term "Author Signature" with the term "Author Domain
> Signature" throughout the ADSP spec to help address this. It seems
> like the only real "author signature" would be a PGP type signature
> that is truly attached by the author rather than by some part of
> the email infrastructure on behalf of the author. Since the
> validated signing identity can only be a domain, it's inherently
> misleading to use a signature label that implies otherwise. I
> think we've all agreed that the information in i= is an assertion
> made by the signing domain rather than a validated signing identity
> in its own right, so we should make the spec terminology agree
> with that clarification. That doesn't denigrate the usefulness of
> that assertion data to various consumers, it just clearly
> distinguishes it from the identity/identifier of the signing entity
> itself.
> 
> > 

I am all for this.

+1

	Wietse

---

From: Mark Delany <[email-masked]>
Date: Thu, 2 Apr 2009 14:01:12 -0700

>>> properly

Agreed. Let's have a simple ADSP that minimizes the wiggle room  
available for confusion or complexity. After some real world  
experience, we can add complexity as needed.

Mark.

---

From: Jim Fenton <[email-masked]>
Date: Thu, 02 Apr 2009 15:48:48 -0700

> Domain Signature" also encourages it.

If the definition changes from i= to d= (and it looks like there will be
consensus to do that), Author Domain Signature is the better name for
that.  The Chairs had tasked us to make only a surgical change to this
section, however, so we should check if that's OK.
> ps.  That includes dropping the "ADSP is incompatible" note.
If you mean the note that I included in the alternative text that I
posted, I disagree.  Parent domain signing is a technique described in
RFC 4871.  If it can't be used with ADSP because ADSP compares against
the d= value rather than the domain part of i=, then that limitation
should be pointed out in an informative note so that domains don't get
stung by setting up parent domain signing and then find that ADSP
doesn't do what they expect.

-Jim

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 02 Apr 2009 17:49:52 -0600

+1

-- 
J.D. Falk
Return Path Inc
http://www.returnpath.net/
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 02 Apr 2009 18:15:12 -0700

> doesn't do what they expect.

First, this is one of the simplifications we get by the change that the working 
group agreed to, with the RFC4871 Update about to be formally approved, and with 
the use of SDID, rather than AUID, in ADSP:  the issue of a "parent" disappears. 
  All that is left is the more general question of deciding how to distinguish 
among outgoing mail streams with different SDID values.

Second, either the d= matches the domain in the rfc5322.From field, or it 
doesn't.  There is no complexity or subtlety to the test, so there are no 
"implications" that need to be pointed out.

d/

-- 

   Dave Crocker

---

From: SM <[email-masked]>
Date: Thu, 02 Apr 2009 22:24:35 -0700

At 11:02 30-03-2009, DKIM Chair wrote:
>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?

This issue was discussed within this WG in 2007.  There was also a 
discussion about whether "SSP" is appropriate.  ADSP was chosen as it 
is a signing practice advertised by the Author Domain.  The Author is 
what is in the From: header field.

Granularity is one of the features offered by DKIM to restrict what 
signing address can be used.  What constitutes a signing address is 
left to local policy.  If we are using ADSP, we can, for example, 
match against the From: header field.

People can put anything in the i= tag.  We have seen that being done 
in practice.  The effect is that it may not match the email address 
in the From: header field.  One of the interesting features of the i= 
tag is that it can be used for subdomains.  This means that I can 
have one public key under example.com and reuse it for my 
subdomains.  Some people may argue that I could use a CNAME RR to 
point the subdomains to the public key.  That requires changes to 
DNS.  Most of us may find that trivial but it is complicated for DKIM 
users as DNS may be handled by a different entity.

My preference is not to take out the i= tag.  I think that the i= tag 
value should be used for the ADSP match.  If two parties want to use 
the i= tag for their local purposes, they can use an extension 
tag.  I only have to know what the value represents if there is a 
specification for it.

I prefer to see the note at the end of Section 2 of 
draft-ietf-dkim-ssp-09 removed.  Most users will not do multiple 
signatures because they see it as complex and because of the 
overhead.  If people want to use ADSP, keep it simple by telling them 
what signature constitutes a valid Author Signature.  When you say 
that "ADSP incompatible with valid DKIM usage ...", people will 
register the word "incompatibility" and view valid DKIM usage as 
mostly about third party signatures.

I find it difficult to comment on this point alone as the issues are 
intertwined.  The arguments by both sides open up questions about the concepts.

Regards,
-sm

---

From: Hector Santos <[email-masked]>
Date: Fri, 03 Apr 2009 04:01:49 -0400

> "implications" that need to be pointed out.

So are you saying, this is the new problem (3rd party) that needs a 
solution?

-- 
Sincerely

Hector Santos

---

From: HLS <[email-masked]>
Date: Fri, 3 Apr 2009 04:19:36 -0400

I agree.  This reduces the issue down to a well defined subtle problem
that always existed.

      From.domain does not match d= domain

So what?

---

-- 
hls

---

From: Hector Santos <[email-masked]>
Date: Fri, 03 Apr 2009 05:04:01 -0400

> wouldn't make sense, because ADSP has to function in the absence of any

Which includes a valid 3rd party signature?  Correct?

> does the comparison with d= instead of i=.  Please correct me if I have

It should be noted RFC 4871 already has an inherent protocol rule:

     d= equals RHS of i=  (or is a sub-domain of d=)

So the comparison is burned in for any DKIM verification 
implementation to make, sans ADSP or not. if i= exist, per RFC 4871, 
they have to match directly or by sub-domain.

Maybe some pseudo code might help here:

    //
    // DKIM (RFC 4871) RULE
    //

    if MSG.DKIM.I.Domain exist and
           Not PrimaryDomainDomatch(MSG.DKIM.I, MSG.DKIM.D) then
        Msg.DKIM.Status = INVALID
    end if

    //
    // ADSP (RFC XXXX) RULE
    //

    select case( ASDP(MSG.From.Domain) )

      case "DISCARDABLE":
           if Msg.DKIM.Status = INVALID
                 OR MSG.From.Domain <>  MSG.DKIM.D.Domain then
              DiscardThisMessage()
           end if

      case "ALL":
           if Msg.DKIM.Status = INVALID
                 OR MSG.From.Domain <>  MSG.DKIM.D.Domain then
              // UNDEFINED
           end if
    end select

So as you see, ADSP DKIM=DISCARDABLE gets the invalid status of the 
DKIM  d=, i= comparison failure.  It doesn't need to compare the i 
because DKIM already states what the format must be

-- 
Sincerely

Hector Santos

---

From: Eliot Lear <[email-masked]>
Date: Fri, 03 Apr 2009 11:21:39 +0200

Dave,

> among outgoing mail streams with different SDID values.

If what you are saying is that the subdomain check is deprecated, that's 
fair.  But that doesn't mean the check is incompatible.

> "implications" that need to be pointed out.

This is unresponsive to Jim's point.

Eliot

---

From: Hector Santos <[email-masked]>
Date: Fri, 03 Apr 2009 08:52:29 -0400

[email-masked] wrote:
> 3rd party signing was removed from discussion some time ago

Only by name, just like Dave stated here:

   "All that is left is the more general question of deciding how to
   distinguish among outgoing mail streams with different SDID values."

Call it want what you please, the issues of 1st party vs 3rd party is 
still in play. What do you think this i= thing was all about?

-- 
Sincerely

Hector Santos

---

From: Hector Santos <[email-masked]>
Date: Fri, 03 Apr 2009 09:15:18 -0400

Again, call it what you want, UAID, SDID, Author Domain Signature vs
Gmail domain signatues or mipassoc.org domain signatures, etc, when 
you have this:

   DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple;
                   d=mipassoc.org; s=k00001; ....
   From: "J.D. Falk" <[email-masked]>

or this:

   DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple;
                   d=mipassoc.org; s=k00001;....
   From: HLS <[email-masked]>

which by the way

   DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple;
                   d=gmail.com; ....
   From: HLS <[email-masked]>

Before mipassoc.org got its hands on it, is all about 3rd party "mail 
DKIM interference" with 1st party or other 3rd party signatures.

If you don't control this, then we will undoubtedly begin to see:

   DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple;
                   d=some_phisher.com; ....
   From: Poor User <[email-masked]>

If COX.NET has not plans to deal with this, either with ADSP or 
something else, that pity the Poor User at cox.net.  Sure, the fancy 
reputation system will eventually score up points on some_phisher.com 
or someone will report it early on, but it might be too late for Poor 
User at cox.net.

If you ask me, if here is monetary harm for Poor User and he hires joe 
the lawyer, this is a valid case of engineering neglect and 
malpractice - experts in the field knew the problem existed and 
allowed was still allowed to perpetuate. Cox.net might had to deal 
with this.  But don't take none of this from me. Present it like I 
said to your chief council and see what he says.

-- 
Sincerely

Hector Santos

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 03 Apr 2009 16:17:01 +0100

>> From address and the i= address.

Ah! I stand corrected!

OTOH, that is not how the meaning of i= has been portrayed in recent
discussions of Dave's Errata. If, as the present RFC is alleged to state,
and Dave's Errata confirm, the i= tag is merely opaque information that
may be useful, but forms no essential part of the protocol beyond the fact
that it is there and the signature proves that it was there when
originally signed, then it follows that the ADSP draft is inconsistent
with the RFC.

In that case, one or the other needs to be changed, and the mood of recent
exchanges is that the RFC should be left alone (or confirmed by the
Errata), in which case ADSP needs to be changed. And we had better not
proceed any further until we have agreed on that.

> does the comparison with d= instead of i=.  Please correct me if I have

Yes, it would seem so. It certainly removes any confusion where the
signature applied by the mailing list also has to do double duty as the
Author Signature. Though it might be regarded as Best Practice for the
message to acquire two signatures in that case (likely with different i=
tags, but signed with the same key), just as would have happened if the
message for the list had arrived from some external domain that had
already supplied an Author Signature.

---

From: Jeff Macdonald <[email-masked]>
Date: Fri, 3 Apr 2009 11:20:00 -0400

+1

-- 
Jeff Macdonald
[email-masked]

---

From: <[email-masked]>
Date: Fri, 3 Apr 2009 08:40:08 -0400

On 4/3/09 4:01 AM, "Hector Santos" <[email-masked]> wrote:

--
Sincerely

Hector Santos

---

From: "J.D. Falk" <[email-masked]>
Date: Fri, 03 Apr 2009 12:14:22 -0600

> 3rd party signing was removed from discussion some time ago

...with the intention of discussing it again after seeing how the industry 
deals with 'em, both with & without ADSP.

1st party, as addressed in ADSP with d=: simple, easy to understand, but 
doesn't apply to all possible use cases.

3rd party: complex, difficult to understand, and the use cases are 
infinitely varied.

Until then, we're just guessing.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 3 Apr 2009 12:03:04 -0700

On Apr 3, 2009, at 2:21 AM, Eliot Lear wrote:

>>
>> Second, either the d= matches the domain in the rfc5322.From field,  
>> or it doesn't.  There is no complexity or subtlety to the test, so  
>> there are no "implications" that need to be pointed out.
>

Agreed.  The current ADSP Author Signature definition in Section 2.7:
,---
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.
'---
ADSP is not intended to be applied across sub-domains, so there is  
little reason to accommodate parent domain signing.   Requiring  
publication of the DKIM public key _and_ ADSP record for each email- 
address domain does not seem like an undue burden.   There is nothing  
wrong with Jim's request to add a note regarding the restriction, but  
this restriction is not being changed.  That portion of the Author  
Domain Signature definition has not be discussed.

IMHO, the definition is being changed by striking the following in  
Section 2.7:
,---
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.

'---

-Doug

---

From: Hector Santos <[email-masked]>
Date: Fri, 03 Apr 2009 15:12:14 -0400

> deals with 'em, both with & without ADSP.

But you been discussing it all along. It never went away. What do you 
think this i= was about?

Plus the industry is already seeing what affects it can have with you 
have a mailing list like mipassoc.org and ESP's gmail.com blindly sign 
all mail regardless of policy (see below).

> doesn't apply to all possible use cases.

No, it applies to the HUGE market of private domains that have no 
expectation of having resigners do their mail.

> 3rd party: complex, difficult to understand, and the use cases are 

Again, there is a HUGE market of private domains that simply want one 
thing:

     "I DON"T WANT 3rd party signers"
     "I allow these signers"

Its that simple.  If the 2nd one is too complex, the first one should 
be possible - we have that in ADSP.  But it make it worst for DKIM 
resigners issues.

> Until then, we're just guessing.

You know, I'm growing tire of such thinking.

This isn't the 1970s/80s where there many unknowns. These early 
relaxed ideas for security related issues where justified.  But after 
30 years, there are what?  millions of industry man-hours experiences 
in how the mail system works and know exactly where are the threat 
entry points. I don't think I am the only one, maybe here but I don't 
think so,  that understand that.  It doesn't take a PHD to understand 
that we have a legacy mail problem that promotes spoofing.

DKIM helps raise the bar to a new level of email expectations.  It 
would move the mail into a non-legacy mode.

I believe in the incremental approach, I am very conservative. But we 
can't approach this with another relaxed period of many years to 
confirm what we already know can cause problems today.  In my view, 
this would be engineering neglect.

We know what the problems are and there are some pragmatic solutions 
to it. The frustration of mine is that we didn't remove these ideas 
for technical reasons, but for conflict of interest reasons. 
Reputation was suppose to be out of scope, but even when it repeated, 
the KEY documentation gurus keep making it a vital part of the DKIM 
solution with less emphasis on policy.  Policy was never their prize, 
  Reputation trust services where.  So lets the record straight. I am 
not wasting your time here.  The WG is wasting everyone's time.

I doubt we will get another chance like we have now to "Get right it, 
the first time" (Sorry, I was Westinghouse trained with this QA 
engineering motto).

If we don't, we are going to have to raise the bar again with a new 
level of email expectations because DKIM/ADSP will be become the next 
legacy email framework or worst, completely useless it is ignored.

We are already see this in motion with this mailing list and services 
like GMAIL.COM signing mail on behalf of others. So it might bee too late.

Finally, I haven't implemented DKIM. To me, that says a lot because I 
  would be among the first to implement solid technology.  I like to 
think I represent a part of the market place that will be concern with 
problematic technology.

So no, its not guessing on my part. Its called engineering with 
history behind you to know what to expect and not expect.

-- 
Sincerely

Hector Santos

---

From: DKIM Chair <[email-masked]>
Date: Fri, 03 Apr 2009 18:26:34 -0400

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

The chairs note that this proposal has rough consensus.

Jim has suggested that if we do this, and in view of the discussion of "Author" 
vs "Author Domain", we should make sure the documents consistently refers to 
"Author Domain Signature".  We think that's a good idea, and we don't guess 
there'll be much objection to it.

The discussion has not settled on the exact text, so the chairs ask the 
co-editors of the ADSP spec to settle on that, and post another draft.  We'll 
have a quick WG review of that before passing it back to Pasi.

Barry

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Sun, 05 Apr 2009 12:14:39 +0100

>    From: HLS <[email-masked]>

Neither of those are Author (Domain) Signatures. They indicate that  
mipassoc.org has processed them, and that mipassoc believes they are  
"worthy of all men to be believed" (whatever that means). I would not  
expect a simple minded Assessor to be impressed, or to take any action  
either way (unless there are _additional_ signatures that are more  
impressive). A smarter Assessor that knows the reputation of mipassoc.org  
_might_ be a little more impressed.

Neither signature does any harm, but they don't do much good either.
>    From: HLS <[email-masked]>

And that looks like a perfectly good Author Signature, which any assessor  
SHOULD pass without further ado.
> If you don't control this, then we will undoubtedly begin to see:

I don't see WHY you want to control this. All the examples are harmless.
>    From: Poor User <[email-masked]>

And that should be harmless too, unless some_fisher.com has acquired an  
excessively negative reputation.
> or someone will report it early on, but it might be too late for Poor

Why? Of course it would be better if COX.NET had added a signature first,  
with an ADSP record to explain it, but that is not essential.

I just do not see what you are getting at.