Subject: Re: [ietf-dkim] Comments on draft-ietf-dkim-implementation-report-01

From: Jeff Macdonald <[email-masked]>
Date: Fri, 1 Oct 2010 11:11:50 -0400

On Fri, Oct 1, 2010 at 2:48 AM, Murray S. Kucherawy <[email-masked]> wrote:
>> The results in Section 4.1.2 mention "Author vs. Third-Party".  That
>> is more about ADSP than DKIM.
>
> True.  It should probably come out.
>

It could mean that or that most implementations default to d= From:
domain. I strongly believe that is a holdover of implementations being
based on DomainKeys code which had that constraint.

 Author vs. Third-Party:  73% of the signatures observed were author
 signatures, meaning the "d=" value in the signature matched the
 domain found in the From: header field.  The remainder, therefore,
 were third-party signatures.

I do believe the DKIM draft warns about having d= be related to other
headers in the message. Perhaps this stat could be restated as:

 d= relations:  73% of the signatures observed had a direct
correspondence to the From: header , meaning the "d=" value in the
signature matched the
 domain found in the From: header field.

-- 
Jeff Macdonald
Ayer, MA

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

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Fri, 1 Oct 2010 11:17:44 -0400

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Murray S. Kucherawy
> Sent: Friday, October 01, 2010 2:48 AM
> To: SM; [email-masked]
> Subject: Re: [ietf-dkim] Comments on draft-ietf-dkim-implementation-
> report-01
> 

<SNIP>

> True.  It should probably come out.

This is of interest beyond ADSP. It helps the community understand who
is signing. There has been much discussion of the value of Author vs.
Third-Party signing outside of the ADSP discussion.

As Jeff points out, this may be related to implementations defaulting to
signing this way (or not easily allowing 3rd party signing).

I don't think it should come out.

Mike

---

From: Steve Atkins <[email-masked]>
Date: Fri, 1 Oct 2010 08:29:33 -0700

> based on DomainKeys code which had that constraint.

+1

Also, I've talked to several people who want to use DKIM with varying d=
for the same 822.From, but can't because the signers they're using
can only sign with a single domain for any given 822.From domain,
or can only sign with the domain in the 822.From.

I don't know how widespread this misbehaviour is in DKIM signers,
but it's there.

> domain found in the From: header field.

I might even say "was identical to" rather than "matched" - so as
to make it clear that the d= value wasn't a subdomain of the
822.From domain.

Cheers,
  Steve

---

From: Michael Thomas <[email-masked]>
Date: Fri, 01 Oct 2010 08:39:42 -0700

> I don't know how widespread this misbehaviour is in DKIM signers,

It's not necessarily misbehaviour. Signers need to be careful about what they sign.
All that says is that the access control to the signer is relatively simple minded,
which is more of a marketing requirement than bad code. It's probably saying that
most implementation's requirements don't care about that kind of flexibility. And
speaking from experience, the code complexity to support it, while not enormous,
is certainly not zero.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Fri, 01 Oct 2010 08:50:44 -0700

> I don't think it should come out.

I agree. If nothing else, it may be showing implementations which have bad
access control mechanisms. But it seems to me that stats on how people are
signing is generally interesting, and isn't linked to ADSP at all.

Mike

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 01 Oct 2010 09:30:36 -0700

On 9/30/2010 8:04 PM, Mark Delany wrote:
> Thanks very much for writing this up, Murray. Very enlightening. And
> that Alt-N - a relatively small company - hosted an event for the big
> guys at their expense speaks volumes about the commitment of Arvel and
> his crew. We are in their debt.

+1

And to add to the feel-good moment, I'll note that a relatively obscure 
technical effort like DKIM would normally be expected to get a very small number 
of organizations at a first interoperability event.  My expectations at the time 
were that 5 would be a success and 10 would have been a home run.  We had 20.

d/

-- 

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

---

From: Hector Santos <[email-masked]>
Date: Fri, 01 Oct 2010 12:45:38 -0400

> signing is generally interesting, and isn't linked to ADSP at all.

What I am increasing seeing is that with the early DKIM raw signing 
(since policy was pulled and still in the works),  people are now are 
starting to question what is the purpose, the payoff, the 
uncertainties - policy (in whatever form) is the common consideration.

For example, you have a dkim=all. Following a strict RFC 4871, you end 
up with and world (IETF-DKIM world) seeing:

Authentication-Results: dkim.winserver.com;
   dkim=pass header.i=mipassoc.org header.d=mipassoc.org header.s=k00001;
   adsp=fail policy=all author.d=mtcc.com;

So what does that mean?

Well, you have to tell the world that mipassoc.org is a "good guy." 
Sure, it can isolated to certain reputation engines receivers and also 
members (list receivers) can white list it as well thus always 
trusting mipassoc.org.

But you can help the world wide general verifier market by using some 
sort of self-asserting third party "allow" or "authorization" method.

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 1 Oct 2010 10:15:27 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Jeff Macdonald
> Sent: Friday, October 01, 2010 8:12 AM
> To: [email-masked]
> Subject: Re: [ietf-dkim] Comments on draft-ietf-dkim-implementation-report-01
> 

The spec simply states that DKIM doesn't require any binding at all.  (Section 1.1)

>  domain found in the From: header field.

Since there is no binding in RFC4871, which is the focus of the implementation report, it seems more correct to me to just leave that information out.  It's more of an ADSP statistic.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 1 Oct 2010 10:20:12 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
> Sent: Friday, October 01, 2010 10:15 AM
> Since there is no binding in RFC4871, which is the focus of the
> implementation report, it seems more correct to me to just leave that
> information out.  It's more of an ADSP statistic.

I should've read the whole thread before replying.  If consensus is to keep the statistic in, I'm fine with Jeff's proposed language.

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 01 Oct 2010 10:28:22 -0700

> The spec simply states that DKIM doesn't require any binding at all.  (Section 1.1)

It occurs to me that this language permits a misinterpretation and that stronger 
and more direct language would be appropriate.

By saying "is not required to match", the current spec leaves open the 
possibility that the presence of a match might be taken to be meaningful by DKIM.

However the reality is that DKIM is literally blind to the relationship between 
a d= domain and a domain name in any other field.

I think the text should therefore be revised from:

> 1.1.  Signing Identity
...
>       INFORMATIVE RATIONALE: The signing identity specified by a DKIM
>       signature is not required to match an address in any particular
>       header field because of the broad methods of interpretation by
>       recipient mail systems, including MUAs.

(hmm.  the use of the term 'address' is probably also inappropriate since it 
means email address in the email world, rather than domain name address.)

to be:

1.1.  Signing Identity
...
      The signing identity specified by a DKIM signature is entirely independent 
of the identities present in any particular header field.  The interpretation of 
a match that is possible between the signing identity and the identifier in 
another field is outside the scope of DKIM.

(I've removed the "Informative Rationale" label because the proposed text really 
moves into explanation of the protocol, rather than explanation of its 
motivation or the like.)

d/

ps. just so no one is confused:  this does not change the protocol at all; it 
merely clarifies a point that is often misunderstood.
-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 01 Oct 2010 10:30:03 -0700

> I should've read the whole thread before replying.  If consensus is to keep the statistic in, I'm fine with Jeff's proposed language.

As a statistic in a software reporting tool, I think it's a fine a useful tidbit 
to include.

As a part of the IETF implementation report for Draft Standard, I suspect it is 
distracting or possibly worse, since it implies that that bit of data is 
relevant to the protocol and its deployment.

d/

-- 

   Dave Crocker

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 1 Oct 2010 10:30:48 -0700

> From: Dave CROCKER [mailto:[email-masked]]
> Sent: Friday, October 01, 2010 10:28 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> [...]

Works for me.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 1 Oct 2010 10:47:16 -0700

> Sent: Friday, October 01, 2010 10:30 AM
> To: Murray S. Kucherawy
> distracting or possibly worse, since it implies that that bit of data
> is relevant to the protocol and its deployment.

I agree that's true.  But on the flipside, this particular statistic pointed out that the slight text change you proposed in your previous message might be a good idea for the DS version.  It might therefore actually be useful to include as justification for such an edit should anyone ask.

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 01 Oct 2010 10:59:06 -0700

On 10/1/2010 10:47 AM, Murray S. Kucherawy wrote:
>> As a part of the IETF implementation report for Draft Standard, I suspect
>> it is distracting or possibly worse, since it implies that that bit of
>> data is relevant to the protocol and its deployment.
>
> I agree that's true.  But on the flipside, this particular statistic pointed
> out that the slight text change you proposed in your previous message might
> be a good idea for the DS version.  It might therefore actually be useful to
> include as justification for such an edit should anyone ask.

wow.  i had entirely missed that you received excellent training as an
attorney.  (or is this just an artifact of the high quality of Canadian education?)

In other words, good point.  I withdraw my suggestion.

d/
-- 

   Dave Crocker

---

From: SM <[email-masked]>
Date: Fri, 01 Oct 2010 16:24:05 -0700

Hi Murray,
At 23:48 30-09-10, Murray S. Kucherawy wrote:
>But also important is discussion about some things we didn't expect 
>to see that may reveal themselves as the protocol has matured.  For 
>example, a flawless DKIM implementation is still thwarted by the 
>injection of malformed header fields that are signed and later 
>corrected to spec by downstream MTAs.  I believe that's useful 
>information for the community.

Yes.  What is being determined through this report is whether people 
can implement the specification correctly through interoperability testing.

>Sure, but are those numbers permanent such that later readers will 
>find the same data, or should we describe each of the items that 
>came out of the Interop?

The level of detail for the report is left to the author. If we want 
later readers to find the information, we could list the 
interoperability issues in the document.

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 1 Oct 2010 16:30:24 -0700

> From: SM [mailto:[email-masked]]
> Sent: Friday, October 01, 2010 4:24 PM
> To: Murray S. Kucherawy
> Subject: RE: Comments on draft-ietf-dkim-implementation-report-01
> 

I decided I was being lazy and added a summary of the errata to the report, so they're there with their numbers for the next version.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 02 Oct 2010 13:58:58 +0100

> of the identities present in any particular header field. The interpretation of

s/identities/identifiers/ above?

S.

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 02 Oct 2010 08:22:26 -0700

...
> s/identities/identifiers/ above?

Well, I did have a similar thought, when writing the proposed change, but that's 
a more substantial change, since it moves from saying "entity" to saying 
"reference to the entity".

The usage later in the sentence needs to match earlier in the sentence where it 
says "signing identity", which is the term being defined in that subsection.

How about:

1.1.  Signing Identity
...
        The signing identity specified by a DKIM signature is entirely 
independent of the identities referenced in any particular header field. The 
interpretation of...

d/

-- 

   Dave Crocker

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 02 Oct 2010 16:33:19 +0100

On 02/10/10 16:22, Dave CROCKER wrote:
>>> independent
> Well, I did have a similar thought, when writing the proposed change,
> but that's a more substantial change, since it moves from saying
> "entity" to saying "reference to the entity".
> 
> The usage later in the sentence needs to match earlier in the sentence
> where it says "signing identity", which is the term being defined in
> that subsection.
> 
> How about:
> 
> 1.1.  Signing Identity
> ...
> independent of the identities referenced in any particular header field.
> The interpretation of...

Yeah, its a minor point and you're right that smaller changes
are better so that's fine by me.

I guess from a purist p-o-v, I think we could argue that only
identifiers appear directly in protocols, and never identities,
but since there's no need to go there, let's not:-)

Cheers,
S.