Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-03
Dave CROCKER 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? 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] draft-ietf-dkim-rfc4871bis-03: issues with 'z= Copied header fields'
Section 3.5. of draft-ietf-dkim-rfc4871bis-03 describes the 'z' tag. I have two comments on this tag. issue #1. When dealing with an implementation, I realized that the specification text has nothing to say on the *order* of header fields in the 'z' tag. It does say that any header fields may be included, and that this list has no direct correlation with a list of signed header fields, i.e. the 'z' may include more, or less or different header fields than the 'h' list. As this tag mainly serves troubleshooting and statistics purposes, the unspecified order may not be a serious issue. It is also not common to include multiple occurrences of header fields, but that may just as well be useful, e.g. Resent-*, Received, X-* fields. It would be beneficial if the rfc would at least recommend one order. It may seem obvious that a top-down order comes naturally, but considering that a signing algorithm walks through multiple occurrences of header fields bottom-up, the top-down order may no longer appear so natural. issue #2: The text for the 'z' tag includes the following: Header fields with characters requiring conversion (perhaps from legacy MTAs that are not [RFC5322] compliant) SHOULD be converted as described in MIME Part Three [RFC2047]. I find this confusing. If the purpose of this paragraph is to remind us that a mail message header section must not be malformed, i.e. must adhere to the 7bit ascii, etc., then I don't think this text belongs here. A mail header section should be sanitized / converted to QP or whatever is needed before signing, so there is no issue for rfc4871 or its 'z' tag here. If however the above paragraph is to be understood that, despite knowing that a mail header section contains improper characters, the DKIM signer should QP encode them on its own for the purpose of forming the 'z' tag, knowing that the actual mail header will not be sanitized, then I find it clearly wrong. The purpose of the 'z' tag is to convey the actual text of header fields as presented to a signing algorithm. Passing a sanitized form to 'z' and unsanitized to the signer goes against the purpose of the 'z' tag. In short, I think the paragraph should just be removed. Mark ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] draft-ietf-dkim-rfc4871bis-03: issue with 'k= Key type'
Section 3.6.1. states: k= Key type (plain-text; OPTIONAL, default is rsa). Signers and verifiers MUST support the rsa key type. The rsa key type indicates that an ASN.1 DER-encoded [ITU-X660-1997] RSAPublicKey [RFC3447] (see Sections Section 3.1 and A.1.1) is being used in the p= tag. (Note: the p= tag further encodes the value using the base64 algorithm.) Unrecognized key types MUST be ignored. I believe the Unrecognized key types MUST be ignored is incorrect, or at least can be misunderstood. It is not the key *type* (the value of a 'k' tag) that is to be ignored (which would just mean that a 'k' tag is useless as any value means 'rsa') - but the complete public key (record) with a key type (implied or explicit) not matching the sig-a-tag-k from an 'a' tag of a signature must be ignored. Mark ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-rfc4871bis-03: issues with 'z= Copied header fields'
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Mark Martinec Sent: Friday, March 11, 2011 10:09 AM To: IETF DKIM WG Subject: [ietf-dkim] draft-ietf-dkim-rfc4871bis-03: issues with 'z= Copied header fields' [...] It would be beneficial if the rfc would at least recommend one order. It may seem obvious that a top-down order comes naturally, but considering that a signing algorithm walks through multiple occurrences of header fields bottom-up, the top-down order may no longer appear so natural. [as participant, not co-editor] I tend to agree, since this way one could definitively detect header field re-ordering. Even though, via the h= semantics, DKIM is fairly resilient to re-ordering, it might be helpful during diagnostic work to be able to detect for certain that it has occurred. [...] In short, I think the paragraph should just be removed. Agree here too. -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-rfc4871bis-03: issues with 'z= Copied header fields'
It would be beneficial if the rfc would at least recommend one order. ... I tend to agree, ... In short, I think the paragraph should just be removed. Agree here too. On the theory that quick exchange might represent the beginnings of consensus, I'll anticipate our doing a change. That prompts asking what the revised wording should be? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
