Subject: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-04

From: Jim Fenton <[email-masked]>
Date: Mon, 28 Mar 2011 14:27:01 -0700

Some comments on the new rfc4871bis draft.  Some of these comments are 
continued from the discussion on -03, where in many cases I dropped the 
ball on a previous thread.

A previous comment of mine, and Dave Crocker's response to which I will 
finally reply:
>
>> Section 2.3, Identity: I realize this is taken from RFC 5672, but the
>> definition is not clear to me. Suggest that the second sentence read,
>> "Identities that may be associated with DKIM signatures include 
>> authors and
>> their organizations, ISPs along the message handling path, and 
>> mailing list
>> operators." (I'm not sure how the independent trust assessment 
>> services apply
>> here, since their assessment happens AFTER signature verification). 
>> [same as
>> last call comment on -02]
>
> 0. Can you clarify what it is about the definition that is not clear?  
> (Any guidance at all will help for understanding the nature of what 
> needs fixing.) The initial text is the definition and it's simplicity 
> makes it difficult to guess what the problem is.
>
> 1. "authors and their organizations" could be misinterpreted to mean 
> that the conjunction defines a single identity.

But the current text says "...examples include the author, ..." so that 
misinterpretation exists there as well.  I'd be fine with just "authors' 
organizations".
>
> 2. It turns out that this sort of text is much clearer when it makes a 
> singular rather than plural reference, especially given that the term 
> being defined is singular.

I'm fine with singular.
>
> 3. One form of assessment service -- of which the late Goodmail was an 
> example
> -- can give a priori assessment and then indicate tghe assessment by 
> providing the signature to the message before it is sent.  That is, 
> the authoring organization passes the message to the assessment 
> service and the assessment service hands back the signature to be 
> included in the message.  (The details can vary, of course, but this 
> describes the basic model.)  Hence the signature is somewhat akin to a 
> capability token. [I thought I had explained this processing option a 
> number of times over the years, specifically citing the Goodmail 
> example.]

That's a specific example of an ISP along the handling path.  The 
potential for misinterpretation of this is greater than the benefit of 
explaining this potential usage scenario, especially since "assessment" 
has a very specific definition in the DKIM context.

>> Section 2.9, Common ABNF tokens:  Two new tokens are defined based on
>> field-name and dkim-quoted-printable.  But where are field-name and
>> dkim-quoted-printable defined?
>
> field-name is defined in Section 2.10
>
> DKIM-Quoted-Printable is defined in Section 2.11

Would it be beneficial to rearrange the sections to avoid the forward 
reference?

Section 3.2, paragraph 2:  dkim-quoted-printable is now defined in 
section 2.11, not 2.6.

>> 6.3 paragraph 5 has changed "signing identity" to SDID. The signing 
>> identity
>> really corresponds to the AUID.
>
> That has not been correct for any version of rfc4871bis.  The term 
> Signing Identity has no normative value and is now only used in the 
> introductory text.
>
> Also note that the Update removed any meaningful semantics for AUID:
>
>       The AUID comprises a domain name and an optional
> <Local-part>.  The domain name is the same as that used for the
>       SDID or is a sub-domain of it.  For DKIM processing, the domain
>       name portion of the AUID has only basic domain name semantics; any
>       possible owner-specific semantics are outside the scope of DKIM.
>
> In fact, the AUID is not part of DKIM's formal output.  So the formal 
> specification cannot then direct it be supplied to the assessment engine.

Nevertheless, suppose a message with From address 
<[email-masked]> was properly signed with 
i=marketing.example.com and d=example.com.  What the text is telling us 
is that the mail system SHOULD take pains to ensure that example.com is 
visible to the user.  This is counter to all of the text in the DKIM 
specification that permits keys for a subdomain to be managed in a 
parent domain. If these is consensus to eliminate signing for 
subdomains, there is a lot of other stuff that needs to be removed from 
the spec, including the i= tag itself, the "s" flag in the key record, 
the text in section 3.9, and the security consideration in section 8.13.

The Update removed semantics associated with the local part of the AUID, 
and not the domain-part.

If there is not consensus to remove subdomain signing, the wording 
described here makes it meaningless.  This goes to the heart of why I 
have been arguing that the output of DKIM should be the AUID (or its 
default value, which is the SDID), and not the SDID itself.

=====
In today's meeting, I took an action on the Jabber chat to write some 
informative text cautioning signers not to put empty g= values in their 
key records.  Here is an attempt:

Appendix C.  Key Record Considerations (INFORMATIVE)

C.1. Creating a Public Key

[current Appendix C text goes here]

C.2. Compatibility with DomainKeys Key Records

DKIM key records were designed to be backwards-compatible in many cases 
with key records used by DomainKeys [RFC 4870] (sometimes referred to as 
selector records in the DomainKeys context).  One area of 
incompatibility warrants particular attention.  The "g" tag/value may be 
used in DomainKeys key records to provide finer granularity of the 
validity of the key record to a specific local-part; a null "g" value is 
valid for all addresses in the domain.  This differs from the usage in 
the original DKIM specification [RFC 4871], where a null "g" value is 
not valid for any address.  In particular, the example public key record 
in [RFC 4870] section 3.2.3 is not compatible with [RFC 4871].

Although the "g" tag has been deprecated in this version of the DKIM 
specification, signers are advised not to include the "g" tag in key 
records because some [RFC 4871]-compliant verifiers will be in use for a 
considerable period to come.

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 28 Mar 2011 21:04:47 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Fenton
> Sent: Monday, March 28, 2011 2:27 PM
> To: IETF DKIM WG; Dave Crocker
> Subject: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-04
> 

Since it's in definitions for "Identity" in general, and the "i=" could conceivably identify a specific author, is this a correct change to make?  It doesn't seem to be talking specifically about "d=".

> has a very specific definition in the DKIM context.

I think I'll let Dave reply to this one, since I lack the context.

> Would it be beneficial to rearrange the sections to avoid the forward

OK by me.  I'll swap the "Imported" and "Common" sections.

> Section 3.2, paragraph 2:  dkim-quoted-printable is now defined in

Fixed.

> >> 6.3 paragraph 5 has changed "signing identity" to SDID. The signing identity

Again I think Dave is the better one to reply as he has the context for the debate, but I suggest that the SDID is the only thing that is completely vetted by DKIM, because the AUID doesn't necessarily correspond to anything real (other than the substring matching the SDID).

An implementation that wants to cater to a DKIM consumer which wants the AUID is free to do so, and Paragraph 5 of Section 6.3 doesn't proscribe such an action (in fact, OpenDKIM has mechanisms to provide either).  It's simply describing a minimal compliant implementation.

> [...]

Replaced my text with yours.

-MSK

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 29 Mar 2011 13:53:20 +0200

Jim,

I found that I got seriously bogged down on some parts of your note, as you and 
everyone else will surely see.  I am glad to try to set up a phone call to get a 
better channel for discussing this.  Beyond the obvious timezone challenges, 
this week, I've got quite a bit of flexibility in time and am glad to find a 
slot where I can call you.

Also, everyone else is hereby invited to jump in and straighten me out.

That said, here's where I got in responding:

On 3/28/2011 11:27 PM, Jim Fenton wrote:
>> 1. "authors and their organizations" could be misinterpreted to mean that the
>> conjunction defines a single identity.
>

How is the "examples" list a misinterpretation?

The list was crafted carefully to draw some distinctions that can be 
significant. Your wording loses the distinction between author and author's 
organization.

I think the distinction is worth maintaining.

Just to be clear:  A domain name is capable of being author-specific.  I 
recognize that it's not typical, but the construct of 'author' is so fundamental 
in this game, it's worth acknowledging that it is (still) permitted.

>> 3. One form of assessment service -- of which the late Goodmail was an example
>> -- can give a priori assessment and then indicate tghe assessment by providing
>> the signature to the message before it is sent. That is, the authoring
>> organization passes the message to the assessment service and the assessment
>> service hands back the signature to be included in the message. (The details
>> can vary, of course, but this describes the basic model.) Hence the signature
>> is somewhat akin to a capability token. [I thought I had explained this
>> processing option a number of times over the years, specifically citing the
>> Goodmail example.]
>
> That's a specific example of an ISP along the handling path.

Goodmail was not an ISP and it was not along the path.

      .................  Goodmail  ..............
      .                                         .
      V                                         V
   Client -> Mail -> Transfer -> Service -> Receiver -> Recipient

Goodmail interacted with the creator of the document and, separately, with the 
receiving mail service, as an adjunct "back office" service.  To repeat: /It was 
not in the direct handling path./

DKIM supports that mode of operation quite nicely and it is a particularly 
powerful operational mode, so it is worth keeping that "configuration" in mind 
explicitly.  Given how persistent this confusion seems to be it might even be 
worth more language, though I'm not coming up with a suggestion, offhand.

> The potential for
> misinterpretation of this is greater than the benefit of explaining this
> potential usage scenario, especially since "assessment" has a very specific
> definition in the DKIM context.

I think we've just seen a good example that indeed it is easily misunderstood. 
That begs explicit reference, not potentially confusing conflation.

> Would it be beneficial to rearrange the sections to avoid the forward reference?

Sounds like moving the current 2.9 to be after the current 2.11 will solve your 
concern.

>> That has not been correct for any version of rfc4871bis. The term Signing
>> Identity has no normative value and is now only used in the introductory text.
>>
> Nevertheless, suppose a message with From address <[email-masked]>
> was properly signed with i=marketing.example.com and d=example.com. What the

Your example has d= using a 'parent' domain, not a sub-domain.  Your following 
discussion refers to aspects of the spec that concern sub-domains and I am not 
understanding how the example is relevant to it. Yes, I see that i= has a 
subdomain but, again, I don't see how that relates to your comments.

With obvious trepidation, I am going to raise a concern:  On reviewing the text, 
I find, under the Section 3.5 text for i= includes:

      "The Signer MAY choose to use the same namespace for its AUIDs as its 
users' email addresses or MAY choose other means of representing its users. 
However, the signer SHOULD use the same AUID for each message intended to be 
evaluated as being within the same sphere of responsibility, if it wishes to 
offer receivers the option of using the AUID as a stable identifier that is 
finer grained than the SDID."

I suggest that the first sentence change MAY to "might" in order to make it 
non-normative.

I further suggest removing the second sentence "However...".  It is giving 
(normative) usage guidance for something that it has already made out of scope.

> text is telling us is that the mail system SHOULD take pains to ensure that
> example.com is visible to the user. This is counter to all of the text in the

The closest I can come to what you describe in Section 6.3 is:

      "If the SDID is not the same as the address in the From: header field, the 
mail system SHOULD take pains to ensure that the actual SDID is clear to the 
reader."

As always, anything DKIM says in the space of human factors varies between 
problematic and bad.  "clear to the reader" nicely falls within that range. I 
know something about user interface design and don't know how to satisfy this 
guidance, or what it's supposed benefit is.

Offhand, it appears to reflect the original misunderstanding that DKIM 
"validates" the message.

That said, I don't understand how making the SDID clear to the 'reader' is 
relevant to your concern about AUID.

> DKIM specification that permits keys for a subdomain to be managed in a parent

In what way is any of this counter (per your above assertion)?

> domain. If these is consensus to eliminate signing for subdomains, there is a

You've jumped to a specific conclusion that implies a significant, unstated 
logic sequence and I'm not yet understanding the premise, never mind the rest.

Please clarify.

> lot of other stuff that needs to be removed from the spec, including the i= tag
> itself, the "s" flag in the key record, the text in section 3.9, and the
> security consideration in section 8.13.
>
> The Update removed semantics associated with the local part of the AUID, and not
> the domain-part.

Whereas I think it made changes to the semantics for the entire value.

Please point to the current version's specification of AUID "semantics".

> If there is not consensus to remove subdomain signing, the wording described
> here makes it meaningless. This goes to the heart of why I have been arguing
> that the output of DKIM should be the AUID (or its default value, which is the
> SDID), and not the SDID itself.

I am not understanding how this language affects the use of AUID at all.

d/
-- 

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

---

From: "John Levine" <[email-masked]>
Date: 29 Mar 2011 15:07:14 -0000

>>> 1. "authors and their organizations" could be misinterpreted ...

I'm with Dave.  It looks clear ro me that it's a list of examples.

>(normative) usage guidance for something that it has already made out of scope.

I'd also take out the INFORMATIVE NOTE.  It's an opaque token, so a
signer can do anything with the mailbox part of that token that it
wants.  With a d=example.com, you could equally well use
i=[email-masked] or i=@bob.example.com.  They're different names, but
receivers can infer equally little from each of them.

>      "If the SDID is not the same as the address in the From: header
>field, the mail system SHOULD take pains to ensure that the actual
>SDID is clear to the reader."

Good lord, no.  My users don't see SDIDs or any other part of a DKIM
signature.  That goes in the same bit bucket with the advice to
display the signed and unsigned parts of the message in different
colors.

R's,
John

---

From: Jim Fenton <[email-masked]>
Date: Wed, 30 Mar 2011 20:49:38 -0700

On 3/29/11 4:53 AM, Dave CROCKER wrote:
> Jim,
>
> I found that I got seriously bogged down on some parts of your note, 
> as you and everyone else will surely see.  I am glad to try to set up 
> a phone call to get a better channel for discussing this.  Beyond the 
> obvious timezone challenges, this week, I've got quite a bit of 
> flexibility in time and am glad to find a slot where I can call you.
>
> significant. Your wording loses the distinction between author and 
> author's organization.
>
> Just to be clear:  A domain name is capable of being author-specific.  
> I recognize that it's not typical, but the construct of 'author' is so 
> fundamental in this game, it's worth acknowledging that it is (still) 
> permitted.

With the output of DKIM being the SDID, the identity associated with the 
signature is of course that of the domain.  But when my author-specific 
domain signs a message for me, it's the domain that does that -- it 
doesn't matter that it's an organization of one.  Putting "author" here 
just hints that authors might sign messages as well, and I don't think 
that's intended.  I suggest removing "author" to make that clear.

>>> providing
> Goodmail interacted with the creator of the document and, separately, 
> with the receiving mail service, as an adjunct "back office" service.  
> To repeat: /It was not in the direct handling path./
>
> DKIM supports that mode of operation quite nicely and it is a 
> particularly powerful operational mode, so it is worth keeping that 
> "configuration" in mind explicitly.  Given how persistent this 
> confusion seems to be it might even be worth more language, though I'm 
> not coming up with a suggestion, offhand.

This still seems to me to be too specialized a use case to list in the 
specification, but would look to WG consensus on which way to go here.

> I think we've just seen a good example that indeed it is easily 
> misunderstood. That begs explicit reference, not potentially confusing 
> conflation.

Can you offer alternate text that avoids the overloading of the word 
"assessment"?

>>> Signing
>> <[email-masked]>
> Your example has d= using a 'parent' domain, not a sub-domain.  Your 
> following discussion refers to aspects of the spec that concern 
> sub-domains and I am not understanding how the example is relevant to 
> it. Yes, I see that i= has a subdomain but, again, I don't see how 
> that relates to your comments.

Yes, d= is a parent domain, signing for a subdomain.

The point is that the choice of i= had determined whether something 
ought to be flagged to the recipient.  Now it doesn't.  That is a 
behavioral change that is potentially incompatible with the RFC 4871 
behavior.

>
> With obvious trepidation, I am going to raise a concern:  On reviewing 
> the text, I find, under the Section 3.5 text for i= includes:
>
>      "The Signer MAY choose to use the same namespace for its AUIDs as 
> its users' email addresses or MAY choose other means of representing 
> its users. However, the signer SHOULD use the same AUID for each 
> message intended to be evaluated as being within the same sphere of 
> responsibility, if it wishes to offer receivers the option of using 
> the AUID as a stable identifier that is finer grained than the SDID."
>
> I suggest that the first sentence change MAY to "might" in order to 
> make it non-normative.

I really don't think changing MAY to "might" here is going to make 
things any clearer for implementers.  Much the opposite.

>
> I further suggest removing the second sentence "However...".  It is 
> giving (normative) usage guidance for something that it has already 
> made out of scope.

It's only normative if the "if" clause of that sentence is satisfied, so 
I don't see a problem.

> As always, anything DKIM says in the space of human factors varies 
> between problematic and bad.  "clear to the reader" nicely falls 
> within that range. I know something about user interface design and 
> don't know how to satisfy this guidance, or what it's supposed benefit 
> is.
>
> That said, I don't understand how making the SDID clear to the 
> 'reader' is relevant to your concern about AUID.

I expected an objection on the grounds that this is a human factors 
issue.  This probably does belong in the deployment document if anywhere.

> You've jumped to a specific conclusion that implies a significant, 
> unstated logic sequence and I'm not yet understanding the premise, 
> never mind the rest.
>
> Please clarify.

Let's discuss over the phone or something.  I don't think I'm going to 
do any better in a typed description.

>> described

(radical idea alert)
The point is that if the AUID does not affect the result of the 
verification at all, why even have it?  IN RFC 4871, we had very 
carefully put together the specification so that a parent domain could 
sign on behalf of one of its subdomains, and have the same signature 
semantics as if the subdomain had signed it (including the signature 
being considered an Author Domain Signature in ADSP).  Over time, AUID 
has been watered down and caveated to the point that it is basically 
meaningless.

If AUID doesn't have any normative effect on DKIM verification, we could 
eliminate it altogether and make the specification considerably easier 
to understand and implement, provided there is WG consensus to do so.  
ADSP already ignores the AUID, and as far as I can tell the only 
described use of AUID is to perhaps provide some more fine-grained 
reputation support, which is where you have proposed changing MAY to 
"might".

I'm not really in favor of getting rid of the AUID, but I'm not in favor 
of keeping features in the spec that have no purpose either.

-Jim

---

From: "McDowell, Brett" <[email-masked]>
Date: Thu, 31 Mar 2011 04:32:44 -0600

> specification, but would look to WG consensus on which way to go here.

I agree.

---

From: "John Levine" <[email-masked]>
Date: 31 Mar 2011 13:53:03 -0000

>that's intended.  I suggest removing "author" to make that clear.

The author can be an organization.  For mail from ESPs, I'd say that
the author is almost always an organization.  Please leave the
language alone.

>specification, but would look to WG consensus on which way to go here.

I can easily see applications in universities, where the central IT
group often has only a tenuous hold over the departments who jealously
guard their autonomy, often well past any point of rationality.  A
department wouldn't dream of sending their mail through the servers
run by those bureaucratic morons in central IT, but would be OK with
a remote signer where the mail stays on their computers.

>behavioral change that is potentially incompatible with the RFC 4871 

"Flagged to the recipient" is UI design advice, which I think we've
agreed we're not doing.

>things any clearer for implementers.  Much the opposite.

Agree.  Let's leave it alone.

>verification at all, why even have it?

In my case, it's a comment that helps me figure out what happened when
someone sends back a message with a complaint.  I would be quite happy
to change i= to be a private comment for the benefit of the signer and
remove any syntactic restrictions on it.

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 31 Mar 2011 16:52:21 +0200

On 3/31/2011 5:49 AM, Jim Fenton wrote:
>> recognize that it's not typical, but the construct of 'author' is so
> domain signs a message for me, it's the domain that does that -- it doesn't
> matter that it's an organization of one.

This confuses the actor with the identifier for the actor.  The "domain" does
not do signing.  The actor does the signing.  They use the domain name as an
identifier.  The actor might be an author, identifying themself (themselves?) or 
the actor might be an organization.

In other words, the semantics and the activity are as I described.

> Putting "author" here just hints that authors might sign messages as well,
> and I don't think that's intended. I suggest removing "author" to make that
> clear.

It is not meant to "hint" at that.  It is meant to call it out explicitly.

There are configurations for using DKIM that are not in the main line of
thinking but are nonetheless entirely reasonable and legal to explore using and 
could be quite constructive to employ.

Text that introduces or otherwise describes a mechanism's capabilities should be
careful to give a good sense of the range, rather than directing everyone only
to the most common case, or rather the most common case that is expect.

Besides helping to educate readers, this reminds folks who later seek to modify
the spec that they need to be careful not to (unintentionally) impose
restrictions that eliminate these previously-legal scenarios.

Please note that this exchange is about non-normative, pedagogical text.

>> ................. Goodmail .............. . . V V Client -> Mail ->
>> Transfer -> Service -> Receiver -> Recipient
>>
>> Goodmail interacted with the creator of the document and, separately, with
>> the receiving mail service, as an adjunct "back office" service. To repeat:
>> /It was not in the direct handling path./
>>
>> powerful operational mode, so it is worth keeping that "configuration" in
>> mind explicitly. Given how persistent this confusion seems to be it might
>> even be worth more language, though I'm not coming up with a suggestion,
>> offhand.
>

Indeed, working group consensus controls wg choice.

>>> The potential for misinterpretation of this is greater than the benefit
>>> of explaining this potential usage scenario, especially since
>>> "assessment" has a very specific definition in the DKIM context.
>>

Sorry, no I can't.  I am not seeing the problem that you are, which makes me a 
poor choice for guessing how to satisfy your concern.

Again note that this is non-normative text.

>>>>> identity really corresponds to the AUID.
...
>>> i=marketing.example.com and d=example.com. What the
>>
>> following discussion refers to aspects of the spec that concern sub-domains
>> and I am not understanding how the example is relevant to it. Yes, I see
>> that i= has a subdomain but, again, I don't see how that relates to your
>> comments.
>

DKIM has no concept of "signing for a subdomain.  d= is d=.  It is what is used
to sign and verify.  The only semantics are that it is the identifier to be
delivered as payload and used for assessment.

While, yes, one might be able to observe various details about it and i=, there
is no standardized semantic about it and i= is not officially payload.

> The point is that the choice of i= had determined whether something ought to
> be flagged to the recipient. Now it doesn't. That is a behavioral change that
> is potentially incompatible with the RFC 4871 behavior.

The rule for i= is indeed that its domain must be the same as d= or may be a
subdomain is nice, but this doesn't wind up meaning much.  In particular, it 
means nothing at all for the recipient, because we never specified a meaning.

You are trying to have the specification document conform to semantics that we
chose not to provide, per the Update effort last year.

With respect to i=, there is no "flagged to the user" that is currently part of
the DKIM specification.  Personally, I hope we do not have to revisit this
issue, since the working group spent quite a bit of time and energy resolving it
when formulating the Update RFC.

>> With obvious trepidation, I am going to raise a concern: On reviewing the
>> text, I find, under the Section 3.5 text for i= includes:
>>
>> However, the signer SHOULD use the same AUID for each message intended to
>> be evaluated as being within the same sphere of responsibility, if it
>> wishes to offer receivers the option of using the AUID as a stable
>> identifier that is finer grained than the SDID."
>>
>> I suggest that the first sentence change MAY to "might" in order to make
>> it non-normative.
>
> I really don't think changing MAY to "might" here is going to make things
> any clearer for implementers. Much the opposite.

Again:  The current text is cast in normative language, where we did not approve 
normative meaning. The resolution with the Update effort was to have no 
normative text about AUID, other than the syntax aspect, in the i= definition.

Retaining normative language in this paragraph is in conflict with that decision.

> It's only normative if the "if" clause of that sentence is satisfied, so I
> don't see a problem.

+1.  Personally, I'd be delighted to have that text removed.

>> mail system SHOULD take pains to ensure that the actual SDID is clear to
>> the reader."
>>
>> problematic and bad. "clear to the reader" nicely falls within that range.
>> I know something about user interface design and don't know how to satisfy
>> this guidance, or what it's supposed benefit is.
...
> I expected an objection on the grounds that this is a human factors issue.

glad to be predictable...

>> unstated logic sequence and I'm not yet understanding the premise, never
>> mind the rest.
>>
>> Please clarify.
>
> Let's discuss over the phone or something. I don't think I'm going to do any
> better in a typed description.

as we shall do tonight/afternoon...

d/
-- 

   Dave Crocker