[ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-02
Hello, I commented on draft-ietf-dkim-rfc4871bis-01 previously ( http://mipassoc.org/pipermail/ietf-dkim/2010q4/014696.html ). draft-ietf-dkim-rfc4871bis-02 obsoletes RFC 4871. RFC 5672 updates RFC 4871. Why is the "RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update" document not being obsoleted by this document? In the Introduction Section: "DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message." Dave proposed a change to add a RFC 1034 reference in that sentence. DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message [RFC5322] by associating the domain name [RFC1034] with the message. I suggest adding a reference to RFC 5322 in there to make it clear what "message" is. As I mentioned previously, in Section 3.3: "In general, sha256 should always be used whenever possible." That text was in RFC 4871 too as part of the informative note. Could it be removed to avoid any dilution of the SHOULD in the "Signers MUST implement and SHOULD sign using rsa-sha256" sentence? In Section 3.3.3: "The practical constraint that large (e.g., 4096 bit) keys may not fit within a 512-byte DNS UDP response packet" Could a normative reference to RFC 1035 be added in that sentence? The practical constraint that large (e.g., 4096 bit) keys may not fit within a 512-byte DNS UDP response packet [RFC1035] I'll mention it again; in Section 3.5 for the d= tag: "Internationalized domain names MUST be encoded as described in [RFC3490]." And i= tag: "Internationalized domain names MUST be converted using the steps listed in Section 4 of [RFC3490] using the "ToASCII" function." Is there a reason why this working group requires that a document with an intended status of "Draft Standard" should have a normative reference to a RFC that has been obsoleted? In Section 5.3: "Similarly, a message that is not compliant with RFC5322, RFC2045 correct or interpret such content." I do not understand that sentence. "Therefore, a verifier SHOULD NOT validate a message that is not conformant." That sounds like good advice. According to draft-ietf-dkim-implementation-report-03, the interoperability and testing event was held in 2007. Was the above requirement tested during that event? If this working group wants to add such a requirement, I suggest setting the intended status of draft-ietf-dkim-rfc4871bis to "Proposed Standard". In Section 5.5: "Verifiers MUST be capable of verifying signatures even if one or more of the recommended header fields is not signed (with the exception of From, which must always be signed)" Is the last "must" a requirement? draft-ietf-dkim-rfc4871bis has an informative reference to RFC 5451. I note that the draft uses the "X-Authentication-Results" header field line. Regards, -sm ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-02
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of SM > Sent: Tuesday, October 19, 2010 2:19 PM > To: ietf-dkim@mipassoc.org > Subject: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-02 > > Hello, > > I commented on draft-ietf-dkim-rfc4871bis-01 previously ( > http://mipassoc.org/pipermail/ietf-dkim/2010q4/014696.html ). > > draft-ietf-dkim-rfc4871bis-02 obsoletes RFC 4871. RFC 5672 updates > RFC 4871. Why is the "RFC 4871 DomainKeys Identified Mail (DKIM) > Signatures -- Update" document not being obsoleted by this document? That sounds right to me. > In the Introduction Section: > >"DomainKeys Identified Mail (DKIM) permits a person, role, or > organization that owns the signing domain to claim some > responsibility for a message by associating the domain with the > message." > > Dave proposed a change to add a RFC 1034 reference in that sentence. > > DomainKeys Identified Mail (DKIM) permits a person, role, or > organization that owns the signing domain to claim some > responsibility for a message [RFC5322] by associating the domain > name [RFC1034] with the message. > > I suggest adding a reference to RFC 5322 in there to make it clear > what "message" is. I forget; does the email architecture document talk about the difference between a DNS domain and an ADMD? This was an issue during the IESG evaluation of Authentication-Results and I seem to recall it being a place to which readers could be referred to learn the difference. Maybe changing "domain" to "DNS domain" would be appropriate, and also changing the RFC1034 reference to point at RFC5598? > As I mentioned previously, in Section 3.3: > > "In general, sha256 should always be used whenever possible." > > That text was in RFC 4871 too as part of the informative note. Could > it be removed to avoid any dilution of the SHOULD in the "Signers > MUST implement and SHOULD sign using rsa-sha256" sentence? The OpenDKIM stats shows that SHA1 is still in very widespread use, both by domain counts and by aggregate message counts. Trying to force DS to talk only about SHA256 would mean alienating half or more of the current install base, and we felt that was probably a bad idea. > In Section 3.3.3: > > "The practical constraint that large (e.g., 4096 bit) keys may not >fit within a 512-byte DNS UDP response packet" > > Could a normative reference to RFC 1035 be added in that sentence? > >The practical constraint that large (e.g., 4096 bit) keys may not >fit within a 512-byte DNS UDP response packet [RFC1035] Seems reasonable to me, though I don't think it needs to be normative since that text is discussion rather than protocol specification. > I'll mention it again; in Section 3.5 for the d= tag: > > "Internationalized domain names MUST be encoded as described in > [RFC3490]." > > And i= tag: > > "Internationalized domain names MUST be converted using the steps > listed in Section 4 of [RFC3490] using the "ToASCII" function." > > Is there a reason why this working group requires that a document > with an intended status of "Draft Standard" should have a normative > reference to a RFC that has been obsoleted? I can't remember the disposition of this, but I think the problem is that we want to use ToASCII while no current (i.e. not obsolete) document contains a definition of it. I seem to recall one of the other co-authors looking into it and finding this was acceptable, but I don't recall. Dave, can you comment? > In Section 5.3: > >"Similarly, a message that is not compliant with RFC5322, RFC2045 > correct or interpret such content." > > I do not understand that sentence. XML error. Dave already posted what that was supposed to be. > "Therefore, a verifier SHOULD NOT validate a message that is > not conformant." > > That sounds like good advice. > > According to draft-ietf-dkim-implementation-report-03, the > interoperability and testing event was held in 2007. Was the above > requirement tested during that event? If this working group wants to > add such a requirement, I suggest setting the intended status of > draft-ietf-dkim-rfc4871bis to "Proposed Standard". I don't recall it being tested specifically. And I don't have a good sense about whether the addition of this normative requirement would require a recycle or not. I defer to those more experienced than me. > In Section 5.5: > >"Verifiers MUST
Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-02
>> Is there a reason why this working group requires that a document >> with an intended status of "Draft Standard" should have a normative >> reference to a RFC that has been obsoleted? > > I can't remember the disposition of this, but I think the problem is that we > want to use ToASCII while no current (i.e. not obsolete) document contains a > definition of it. I seem to recall one of the other co-authors looking into > it and finding this was acceptable, but I don't recall. Dave, can you > comment? I suggest the two places that refer to IDNS say Internationalized domain names MUST berepresented as A-labels as described in [RFC5891]. That's a current standard, and A-labels are what ToASCII was supposed to produce. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-02
> I suggest the two places that refer to IDNS say > >Internationalized domain names MUST berepresented as A-labels as >described in [RFC5891]. > > That's a current standard, and A-labels are what ToASCII was supposed to > produce. That's a technical change to the DKIM Signing specification. Plus, it 'fixes' a problem that has not yet been reported for DKIM. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-02
On 10/21/2010 1:48 PM, Murray S. Kucherawy wrote: >> draft-ietf-dkim-rfc4871bis-02 obsoletes RFC 4871. RFC 5672 updates RFC >> 4871. Why is the "RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- >> Update" document not being obsoleted by this document? > > That sounds right to me. +1 >> In the Introduction Section: >> >> "DomainKeys Identified Mail (DKIM) permits a person, role, or organization >> that owns the signing domain to claim some responsibility for a message by >> associating the domain with the message." >> >> Dave proposed a change to add a RFC 1034 reference in that sentence. >> >> DomainKeys Identified Mail (DKIM) permits a person, role, or organization >> that owns the signing domain to claim some responsibility for a message >> [RFC5322] by associating the domain name [RFC1034] with the message. >> >> I suggest adding a reference to RFC 5322 in there to make it clear what >> "message" is. > > I forget; does the email architecture document talk about the difference > between a DNS domain and an ADMD? This was an issue during the IESG Well, it /defines/ ADMD (eg, Section 2.3) and merely uses dns domain names (section 3.3). It does not compare or contrast the two uses of the word 'domain'. ADMD has a bit of extra verbiage to make it substantially different from DNS domain. It still has the word domain because folks seemed to want to use it, rather tenaciously. > evaluation of Authentication-Results and I seem to recall it being a place to > which readers could be referred to learn the difference. Maybe changing > "domain" to "DNS domain" would be appropriate, and also changing the RFC1034 > reference to point at RFC5598? Couldn't hurt. >> As I mentioned previously, in Section 3.3: >> >> "In general, sha256 should always be used whenever possible." >> >> That text was in RFC 4871 too as part of the informative note. Could it be >> removed to avoid any dilution of the SHOULD in the "Signers MUST implement >> and SHOULD sign using rsa-sha256" sentence? > > The OpenDKIM stats shows that SHA1 is still in very widespread use, After the latest round about SHA1, I believe where we landed is to keep the relevant text in the spec as is. No changes. >> "The practical constraint that large (e.g., 4096 bit) keys may not fit >> within a 512-byte DNS UDP response packet" >> >> Could a normative reference to RFC 1035 be added in that sentence? It's now in the pending -03 version. >> The practical constraint that large (e.g., 4096 bit) keys may not fit >> within a 512-byte DNS UDP response packet [RFC1035] > > Seems reasonable to me, though I don't think it needs to be normative since > that text is discussion rather than protocol specification. Sorry. I'm not understanding what text to add, or where. >> I'll mention it again; in Section 3.5 for the d= tag: >> >> "Internationalized domain names MUST be encoded as described in >> [RFC3490]." >> >> And i= tag: >> >> "Internationalized domain names MUST be converted using the steps listed in >> Section 4 of [RFC3490] using the "ToASCII" function." >> >> Is there a reason why this working group requires that a document with an >> intended status of "Draft Standard" should have a normative reference to a >> RFC that has been obsoleted? > > I can't remember the disposition of this, but I think the problem is that we > want to use ToASCII while no current (i.e. not obsolete) document contains a > definition of it. I seem to recall one of the other co-authors looking into > it and finding this was acceptable, but I don't recall. Dave, can you > comment? We've had no call to change that aspect of the specification. While the formal status of the cited document (that defines toAscii) might have changed, the algorithm has not been a problem for DKIM and still works, and the cited document is still accessible. My concern is that shifting the reference to the newer document also requires changing the DKIM technical specification and that that will require recycling at Proposed, for merely bureaucratic reasons rather than from any technical need. >> "Therefore, a verifier SHOULD NOT validate a message that is not >> conformant." >> >> That sounds like good advice. Given the mathematics of a signature, I believe the formal RFC 5322 conformance of the message is actually irrelevant to DKIM. It's highly relevant to other processing engines, but not DKIM. In other words, if a DKIM signature validates, it validates. That's the /only/ test or assurance that is needed. >> According to draft-ietf-dkim-implementation-report-03, the interoperability >> and testing event was held in 2007. Was the above requirement tested >> during that event? If this working group wants to add such a requirement, >> I suggest setting the intended status of draft-ietf-dkim-rfc4871bis to >> "Proposed Standard". > > I don't recall it being tested specifically. And I don't have a good sense > about whether the addition of this normative re
Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-02
RFC 3490 is obsolete, replaced by 5890 and 5891. When they rewrote it they made the language descriptive rather than prescriptive, and an A-label is the new name for what was the output of ToASCII. My understanding is that they actually changed the behavior of the 'subroutine'. Nothing in the switch to 5322 from 2822 changes any behaviors for DKIM. Of course it does. The message syntax in 5322 is ever so slightly different from 2822, so the set of valid messages over which DKIM is defined is slightly different, too. It didn't change very much, but 5890 didn't change very much either. It mostly tightened up rules for rejecting invalid input, got rid of dependencies on a particular version of Unicode, and fixed a few arcane bugs. The toAscii routine still works for us. Sort of. IDN2008 handles more recent versions of Unicode than IDN2003 does and allows some joiner characters that IDN2003 ignored, so ToAscii willl fail on some valid current IDNs. I see that on the IDNA list they're arguing about this exact issue for a revision of http cookies, so I guess that whatever they do, we can do. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly smime.p7s Description: S/MIME Cryptographic Signature ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-02
Hi Murray, At 13:48 21-10-10, Murray S. Kucherawy wrote: >That sounds right to me. It does not sound right to me. >I forget; does the email architecture document talk about the >difference between a DNS domain and an ADMD? This was an issue >during the IESG evaluation of Authentication-Results and I seem to >recall it being a place to which readers could be referred to learn >the difference. Maybe changing "domain" to "DNS domain" would be >appropriate, and also changing the RFC1034 reference to point at RFC5598? A proper comparison of the two requirea more than one sentence. I'll keep it short; ADMD is about administrative authority whereas a DNS domain is of a list of labels. The reference to RFC 1034 is a pointer for the reader to find out what is meant by "domain name". When we talk about domain names, as in DNS, we refer to specifications about DNS. If the question comes up in an discussion about email (within the IETF), consideration is given to whether it is about email delivery or about the domain name space and resource records; and the discussion is punted to the appropriate group. Changing the reference to RFC 5598 may cause problems in other parts of the draft. >The OpenDKIM stats shows that SHA1 is still in very widespread use, >both by domain counts and by aggregate message counts. Trying to >force DS to talk only about SHA256 would mean alienating half or >more of the current install base, and we felt that was probably a bad idea. Maybe I did not explain what I meant correctly. I am not arguing for the document to talk only about SHA256. I'll quote the text from Section 3.3: "DKIM supports multiple digital signature algorithms. Two algorithms are defined by this specification at this time: rsa-sha1 and rsa- sha256. Signers MUST implement and SHOULD sign using rsa-sha256." As you can see, there is a SHOULD for signing using rsa-sha256. Signing with rsa-sha1 is not forbidden. I am not in favor of alienating half or more of the current install base. >Seems reasonable to me, though I don't think it needs to be >normative since that text is discussion rather than protocol specification. That text is not normative. Having the reference as normative means "please read the following document to understand what is written in this document". >I can't remember the disposition of this, but I think the problem is >that we want to use ToASCII while no current (i.e. not obsolete) >document contains a definition of it. I seem to recall one of the >other co-authors looking into it and finding this was acceptable, >but I don't recall. Dave, can you comment? It would be highly unusual to use such a reference. I will most likely nit about that. >I don't recall it being tested specifically. And I don't have a >good sense about whether the addition of this normative requirement >would require a recycle or not. I defer to those more experienced than me. The addition of the normative requirement would complicate matters. I mentioned the recycle as it would keep matters simple. It would be premature to determine which status is the most appropriate. >No, I think it's simply an informative back-reference to another >specified requirement. Maybe changing "must always" to "always has >to" would clear that up. That's fine. Regards, -sm ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-02
On 10/21/2010 9:31 PM, SM wrote: >> I forget; does the email architecture document talk about the >> difference between a DNS domain and an ADMD? ... > A proper comparison of the two requirea more than one sentence. I'll > keep it short; ADMD is about administrative authority whereas a DNS > domain is of a list of labels. The reference to RFC 1034 is a > pointer for the reader to find out what is meant by "domain right. I think that clear references and careful use of terminology should suffice. The specification need not be a tutorial on the differences between two technologies or RFCs that it cites. Correct? >> Seems reasonable to me, though I don't think it needs to be >> normative since that text is discussion rather than protocol specification. > > That text is not normative. Having the reference as normative means > "please read the following document to understand what is written in > this document". I am confused. In a technical specification a normative reference provides material that is part of the technical detail. It's not for background or explanation. It is for /use/. >> I can't remember the disposition of this, but I think the problem is >> that we want to use ToASCII while no current (i.e. not obsolete) >> document contains a definition of it. I seem to recall one of the >> other co-authors looking into it and finding this was acceptable, >> but I don't recall. Dave, can you comment? > > It would be highly unusual to use such a reference. I will most > likely nit about that. Interestingly, the document that made it historical refers to it for more than a reference saying it has been replaced. That is, it makes a substantive comment on it. We need to be careful not to let odd formalities get in the way of basic pragmatics. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-02
> -Original Message- > From: SM [mailto:s...@resistor.net] > Sent: Thursday, October 21, 2010 9:31 PM > To: Murray S. Kucherawy > Cc: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-02 > > A proper comparison of the two requirea more than one sentence. I'll > keep it short; ADMD is about administrative authority whereas a DNS > domain is of a list of labels. The reference to RFC 1034 is a > pointer for the reader to find out what is meant by "domain > name". When we talk about domain names, as in DNS, we refer to > specifications about DNS. If the question comes up in an discussion > about email (within the IETF), consideration is given to whether it > is about email delivery or about the domain name space and resource > records; and the discussion is punted to the appropriate group. I understand your point, but what I'm saying is that the DNSDIR people, on reviewing RFC5451, were not satisfied with that line of reasoning, resulting in a DISCUSS from the OPS AD until I went back and indicated for every use of "domain" which thing I meant. I'm simply trying to avoid that. > Maybe I did not explain what I meant correctly. I am not arguing for > the document to talk only about SHA256. I'll quote the text from > Section 3.3: > >"DKIM supports multiple digital signature algorithms. Two algorithms > are defined by this specification at this time: rsa-sha1 and rsa- > sha256. Signers MUST implement and SHOULD sign using rsa-sha256." > > As you can see, there is a SHOULD for signing using > rsa-sha256. Signing with rsa-sha1 is not forbidden. I am not in > favor of alienating half or more of the current install base. Then I guess I don't understand the basis for the suggested change. The citation you made here doesn't seem to conflict with the "should use sha256 whenever possible" advice, since a normative SHOULD basically means "always, unless you have a very good reason not to do so". ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-02
Hi Dave, At 21:41 21-10-10, Dave CROCKER wrote: >right. I think that clear references and careful use of terminology >should suffice. The specification need not be a tutorial on the >differences between two technologies or RFCs that it cites. Correct? Yes. A specification is not a tutorial. >I am confused. In a technical specification a normative reference >provides material that is part of the technical detail. It's not >for background or explanation. It is for /use/. A normative reference provides material which the reader must read to understand the specification. In this case, it is a way to have a reference to STD 13 which covers domain name concepts and implementation. >We need to be careful not to let odd formalities get in the way of >basic pragmatics. I am fine with that as long as there is a good reason. Regards, -sm ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-02
Hi Murray, At 10:56 22-10-10, Murray S. Kucherawy wrote: >I understand your point, but what I'm saying is that the DNSDIR >people, on reviewing RFC5451, were not satisfied with that line of >reasoning, resulting in a DISCUSS from the OPS AD until I went back >and indicated for every use of "domain" which thing I meant. I'm >simply trying to avoid that. And that is what the suggested change is for as it has a reference to what "thing" the document is talking about. >Then I guess I don't understand the basis for the suggested >change. The citation you This is covered in John Levine's message. Regards, -sm ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-02
Like RFC 4871, draft-ietf-dkim-rfc4871bis-02 says 3.3.1. The rsa-sha1 Signing Algorithm The rsa-sha1 Signing Algorithm computes a message hash as described in Section 3.7 below using SHA-1 [FIPS-180-2-2002] as the hash-alg. That hash is then signed by the signer using the RSA algorithm (defined in PKCS#1 version 1.5 [RFC3447]) as the crypt-alg and the signer's private key. Given that RFC 3447 does not delve in PKCS#1 versions history more than needed, would it be clearer to mention "RSASSA-PKCS1-v1_5"? JM2P ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
