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

From: Jim Fenton <[email-masked]>
Date: Fri, 04 Mar 2011 17:02:56 -0800

My comments on the -03 draft:

1. Introduction: The opening paragraph has lost the sense that the 
signer has to be authorized by the domain owner to apply a signature on 
behalf of that domain.  While the previous draft was a bit too 
restrictive (implied that the signer had to actually be the domain 
owner) this version is too loose.  For the opening sentence I suggest 
something like, "DomainKeys Identified Mail (DKIM) permits a person, 
role, or organization to claim some responsibility for a message by 
associating a domain name [RFC1034] for which they are authorized with 
the message [RFC5322]."

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]

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?

Section 3.7, Computing the Message Hashes: "ABNF of the algorithm" does 
not make sense; ABNF is a syntax specification, it does not specify 
algorithms (and this isn't ABNF, either).

Section 5.3 paragraph 2: remove comma after RFC 2047 (happy National 
Grammar Day!)

Section 6.1.2 Note: The first sentence is describing behavior of a 
number of queries, and should be plural, i.e., "The use of wildcard TXT 
records in the DNS will produce responses to DKIM queries that are 
likely not to be valid DKIM key records."

6.3 paragraph 5 has changed "signing identity" to SDID. The signing 
identity really corresponds to the AUID. As currently worded, the mail 
system is advised to take pains to ensure that the SDID is displayed for 
a message signed on behalf of a subdomain; this isn't necessary. Given 
the WG's past consensus to ignore the local part of the AUID, I suggest 
the following wording for the last sentence of the paragraph: "If the 
domain of the AUID is not the same as domain of the address in the From: 
header field, the mail system SHOULD take pains to ensure that the 
actual AUID domain is clear to the reader." [same as last call comment 
on -02; the point is that if the AUID references a subdomain of the 
SDID, it should still match]

8.14: Remove extraneous > in last paragraph.

(not sure where)  g= resolution:  As Murray pointed out 
(http://mipassoc.org/pipermail/ietf-dkim/2010q4/015030.html), we need to 
make the appropriate adjustments to the registries making g= obsolete, 
and an informative appendix cautioning signers not to put empty g= 
values in their key records because of the legacy behavior of many 
verifiers.

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

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 07 Mar 2011 16:16:49 +0100

> associating a domain name [RFC1034] for which they are authorized with 

+1, although it may be more readable swapping the nouns around "with",
that is

 DomainKeys Identified Mail (DKIM) permits a person, role, or
 organization to claim some responsibility for a message by
 associating the message [RFC5322] with a domain name [RFC1034]
 for which they are authorized to do so.

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 10 Mar 2011 17:06:31 -0800

On 3/4/2011 5:02 PM, Jim Fenton wrote:
> 1. Introduction: The opening paragraph has lost the sense that the signer has
> to be authorized by the domain owner to apply a signature on behalf of that
> domain.  While the previous draft was a bit too restrictive (implied that the
> signer had to actually be the domain owner) this version is too loose.  For
> the opening sentence I suggest something like, "DomainKeys Identified Mail
> (DKIM) permits a person, role, or organization to claim some responsibility
> for a message by associating a domain name [RFC1034] for which they are
> authorized with the message [RFC5322]."

I believe the 'authorization' issue is implied by the 'validation' sentence in 
that paragraph.  However as long as it does not make the opening sentence overly 
long or convoluted, it cant hurt to call this point out explictly.

So...

          <t>DomainKeys Identified Mail (DKIM) permits a person, role, or
             organization to claim some responsibility for a message by
             associating a domain name <xref
                target="RFC1034"/> with the message <xref
                target="RFC5322"/>, which they are authorized to use. This can
             be an author's organization, an operational relay or one of their
             agents. Assertion of responsibility is validated through a
             cryptographic signature and querying the signer's domain directly
             to retrieve the appropriate public key. Message transit from
             author to recipient is through relays that typically make no
             substantive change to the message content and thus preserve the
             DKIM signature. A message can contain multiple signatures, from
             the same or different organizations involved with the message. </t>

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

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.

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

> dkim-quoted-printable defined?

field-name is defined in Section 2.10

DKIM-Quoted-Printable is defined in Section 2.11

> Section 3.7, Computing the Message Hashes: "ABNF of the algorithm" does not
> make sense; ABNF is a syntax specification, it does not specify algorithms
> (and this isn't ABNF, either).

How about:

                <preamble>More formally, pseudo-code for the signature
                          algorithm is:</preamble>

> Section 5.3 paragraph 2: remove comma after RFC 2047 (happy National Grammar
> Day!)

ack

> Section 6.1.2 Note: The first sentence is describing behavior of a number of
> queries, and should be plural, i.e., "The use of wildcard TXT records in the
> DNS will produce responses to DKIM queries that are likely not to be valid
> DKIM key records."

One of several problems with that Note is, again, the use of plural where 
singular works better. The original text also is overly broad and, 
consequentially, ambiguous. So:

                      <t
                         hangText="NOTE:"> The use of a wildcard TXT record
                         that covers a queried DKIM domain name will produce a
                         response to a DKIM query that is unlikely to be valid
                         DKIM key record. This problem is not specific to DKIM
                         and applies to many other types of queries. Client
                         software that processes DNS responses needs to take
                         this problem into account.</t>

But note that the final sentence is meaningless, since it provides no guidance 
about what it means to "take this problem into account".  And the answer isn't 
obvious.  For example, I have no idea what a DKIM implementer should do to 
satisfy this caution.

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

> As currently worded, the mail system is
> advised to take pains to ensure that the SDID is displayed for a message
> signed on behalf of a subdomain; this isn't necessary. Given the WG's past
> consensus to ignore the local part of the AUID, I suggest the following
> wording for the last sentence of the paragraph: "If the domain of the AUID is
> not the same as domain of the address in the From: header field, the mail
> system SHOULD take pains to ensure that the actual AUID domain is clear to
> the reader." [same as last call comment on -02; the point is that if the AUID
> references a subdomain of the SDID, it should still match]

I do not understand the basis for providing any results/policy guidance 
concerning use of AUID.

> 8.14: Remove extraneous>  in last paragraph.

ack.  (but it someone beat you to the punch on that one, since it is already 
gone from the xml.)

> (http://mipassoc.org/pipermail/ietf-dkim/2010q4/015030.html), we need to make
> the appropriate adjustments to the registries making g= obsolete, and an
> informative appendix cautioning signers not to put empty g= values in their
> key records because of the legacy behavior of many verifiers.

yeah, but I have to confess the way to handle this isn't obvious to me.

does anyone have guidance for this?

d/
-- 

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

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 10 Mar 2011 17:28:57 -0800

On 3/10/2011 5:26 PM, John R. Levine wrote:
> Not only is it confusing, it's wrong. Wildcard records work just fine when the
> wildcard is below the _domainkey label, e.g. *.foo._domainkey.example. They work
> less fine in other cases.

The modified text I offered is intended to handle several coverage problems with 
the original text, including the one you cite.  Are you suggesting that it does 
not succeed?  If so, what text do you instead suggest?

d/
-- 

   Dave Crocker

---

From: "John R. Levine" <[email-masked]>
Date: 10 Mar 2011 20:42:33 -0500

> The modified text I offered is intended to handle several coverage problems 
> with the original text, including the one you cite.  Are you suggesting that 
> it does not succeed?  If so, what text do you instead suggest?

The problem really isn't wildcards, it's that people can put garbage in 
the DNS.  So I'd suggest simplifying it to something like this:

<t hangText="NOTE:">The TXT records retrieved from the DNS might not be 
syntactically valid DKIM keys, and client code SHOULD be prepared to
discard invalid records.</t>

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "John R. Levine" <[email-masked]>
Date: 10 Mar 2011 20:26:30 -0500

> obvious.  For example, I have no idea what a DKIM implementer should do to

Not only is it confusing, it's wrong.  Wildcard records work just fine 
when the wildcard is below the _domainkey label, e.g. 
*.foo._domainkey.example.  They work less fine in other cases.

The advice is presumably that clients should be prepared to receive and 
ignore a TXT key record that isn't syntactically valid, but that's just 
good defensive programming with or without wildcards.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Fri, 11 Mar 2011 07:18:23 -0500

> not succeed?  If so, what text do you instead suggest?

Dave,

I believe the text needs to include guidelines not just for DKIM
clients but for DNS software manager authors or administrators.  This
issue started (by me) because a ISP vendor (one of the largest) that
did not offer a clear way in their web based "DNS Manager" for their
customers to add explicit DKIM TXT records and the method offered
lumped TXT records subdomains with wild cards.    As a result, the
order was such that SPF records were returned as well.

So its not just about the DKIM clients being aware of multiple TXT
segments. The spec audience will probably include HOSTING sites people
that will look into how DKIM records is implemented and offered to
this customers.

I think text as simple as follows should be considered (note, I am
just providing a starter, not saying these are the exact words)

     DNS hosting administrator and developers should offer the ability
     to add DKIM records that will not conflict with another other DNS
     (TXT?) query protocols and is not part of the wild card results.

PS: As I recall, the issue for the customer was resolved with the
vendor after the support incident was raised beyond the normal help
desk level.  Keeping the same interface, a new undocumented input
format syntax was provided for adding the TXT subdomain record that
was not part of the wild card results.

-- 
HLS

---

From: Mark Martinec <[email-masked]>
Date: Wed, 16 Mar 2011 18:02:29 +0100

Section:
  7.4.  _domainkey DNS TXT Record Tag Specifications

contains an extra copy of the following table from a section 7.3.
To be removed:

>    The initial entries in the body registry comprise:
> 
>                        +---------+-----------------+
>                        |   TYPE  | REFERENCE       |
>                        +---------+-----------------+
>                        |  simple | (this document) |
>                        | relaxed | (this document) |
>                        +---------+-----------------+
> 
>           DKIM-Signature Body Canonicalization Algorithm Registry
>                               Initial Values

Mark