Re: [ietf-dkim] How MUAs render mail
--On 21 October 2010 12:20:33 -0700 Dave CROCKER d...@dcrocker.net wrote: On 10/19/2010 3:11 AM, Ian Eiloart wrote: It's that, in order to get the marking, she can't spoof a trusted person's sender address. DKIM makes no statement about the validity of a sender address. d/ I guess I should have said Author address. In practice, if I look at mail with yahoo.com author addresses for example, I find that with DKIM yahoo.com signatures, they're about a million times less likely to be forged than without those signatures. That's not to say that yahoo.com forbid forgery, but they may find that their mail stream reputation improves if they take measures to prevent forgery. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] IDNA
I caught up on the back and forth on IDNA. The incompatibilities between IDN2003 and IDN2008 are limited to the encoding of two uncommon characters, which the IDNA group think is not a big deal, hence their decision not to change the xn-- prefix. Really, we should change the references to the current standard. I'm inclined to agree, but let me get a reading from the IESG on whether this will affect the standards-track status, and how they would handle the obsolete reference if we didn't make the change. Barry, as chair ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Focusing on 4871bis
We seem to be bush-whacking again, rather than staying on the trail. I don't mind (actually I like) some level of general discussion, but the chairs would like to focus on our immediate goal for now, so I'm asking folks to refrain, for the moment, from discussion that isn't directly addressing the text of 4871bis. That includes discussion of MUA issues. We can go back to talking about that later, but 4871bis is not the place for that, either from a protocol point of view or from a procedural one. We have reviews from Jim, SM, and John that the editors are working on responding to (John's is new enough that I haven't digested it all yet, and I'm sure the editors haven't either). We also have three significant issues that we need to make sure we have resolved satisfactorily: 1. How to handle a key record with empty g= and absent v= (section 6.1.2, list item 6). Proposed change: Remove g= altogether, along with all references to it. Surveys of what's out there show vanishingly few cases that use g= with any value other than * or empty, so this can be removed as an unused feature. 2. Advice about wildcards in TXT records. Proposed change: Add a note in section 6.1.2 warning about the effect of wildcard TXT records on finding DKIM key records. 3. The issue of multiple occurrences of header fields that may only occur once. Proposed change: Add text to section 5.3 recommending that verifiers check that the message complies with specs, and that they not validate a non-compliant message. Add a new section 8.14 to the Security Considerations, explaining the attacks that can be done using this exposure. We ask the editors to consider the latest batches of comments, respond to them as necessary, produce an -03 version, and post it when they have it ready. We ask all participants to speak up specifically about the three issues above, and let us know whether or not the proposed change is acceptable. The editors can post the specific text they're using, if we have anything to discuss about them. I believe we have agreement on the text for number 2, so we should be set on that one. I haven't seen a definitive poll about removing g= (number 1), but I *think* we have consensus on that. Text for number 3 is still being worked on. Please start new threads for these discussions, rather than responding directly to this one, and let's keep the threads for the three items above separate. And, again, we particularly ask all participants to refrain from other discussions that are not specifically about text for 4871bis, so we can get that document done. Thanks, everyone. Barry, as chair ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
On Thu, 21 Oct 2010 16:17:18 +0100, Alessandro Vesely ves...@tana.it wrote: DKIM-Signature: d=Big-IPS.com; h=from; (supposedly)... From accou...@big-bank.com From some...@big-ips.com Subject: Audit notification body of text saying anything In my hypothesis, a verifier would discard the 2nd From accou...@big-bank.com, at least for hashing purposes. If they were both signed, PERMFAIL would result from a mismatch in the header-hash. If Big-Bank had been added after signing, verifiers are already authorized to delete that field from the message, according to the current PS. Isn't that enough? I am am not clear what you are suggesting here. Please clarify. Do you actually want to pass on to the recipient a message that was different (i.e. lacked a header) from what came in. If so -1. Or if you are saying that the varifier should hash the first From: (contrary to 4871 with requires it to hash the second), thus triggering a PERMFAIL, then you are indeed getting the right answer, but by some very weird means. Further thwarts can be specified in some ADSPbis, eventually. In particular: DKIM-Signature: d=Big-IPS.com; h=from; ... From: some...@big-ips.com, accou...@big-bank.com Subject: Audit notification ... (missing Sender) Isn't that already required to have signatures from each, according to 4871? -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: ...@clerew.man.ac.uk snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Focusing on 4871bis
Synchronization check... I'm not looking to discuss resolution of these items, but merely verify the current status of the items within the working group. On 10/22/2010 8:28 AM, Barry Leiba wrote: 1. How to handle a key record with empty g= and absent v= (section I thought we had wg consensus to drop g=. 2. Advice about wildcards in TXT records. Proposed change: Add a note in section 6.1.2 warning about the effect of wildcard TXT records on finding DKIM key records. This is what is in the pending -03 draft in section 6.1.2: t hangText=NOTE: The use of wildcard TXT records in the DNS will produce a response to a DKIM query that is unlikely to be valid DKIM key record. This problem applies to many other types of queries, and client software that processes DNS responses needs to take this problem into account./t 3. The issue of multiple occurrences of header fields that may only occur once. Proposed change: Add text to section 5.3 recommending that verifiers check that the message complies with specs, and that they not validate a non-compliant message. Add a new section 8.14 to the Security Considerations, explaining the attacks that can be done using this exposure. Those are two different changes. My own sense is that each has some controversy, with the first being pretty substantial and with the first having some significant counter-proposals. 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] layer violations, was detecting header mutations after signing
On 22/Oct/10 18:06, Charles Lindsey wrote: On Thu, 21 Oct 2010 16:17:18 +0100, Alessandro Veselyves...@tana.it wrote: DKIM-Signature: d=Big-IPS.com; h=from; (supposedly)... From accou...@big-bank.com From some...@big-ips.com Subject: Audit notification body of text saying anything In my hypothesis, a verifier would discard the 2nd From accou...@big-bank.com, at least for hashing purposes. If they were both signed, PERMFAIL would result from a mismatch in the header-hash. If Big-Bank had been added after signing, verifiers are already authorized to delete that field from the message, according to the current PS. Isn't that enough? I am am not clear what you are suggesting here. Please clarify. Do you actually want to pass on to the recipient a message that was different (i.e. lacked a header) from what came in. If so -1. That's one possibility. What I have in mind is an MTA filter, not a MUA extension. The same program may be authorized to silently drop whole messages to honor discardable policies, so I don't think it is a desecration to drop a spoofed header field when it finds one. I'd never mandate such behavior, though. It may be made available as an option when users will solicit it, if ever. Or if you are saying that the verifier should hash the first From: (contrary to 4871 with requires it to hash the second), thus triggering a PERMFAIL, then you are indeed getting the right answer, but by some very weird means. I mean first, second in a bottom-up sense. Since the verifier knows there can only be a single From, it hashes empty strings for any further one. Of course, if the verification fails, there is no way to try and discern signed fields... DKIM-Signature: d=Big-IPS.com; h=from; ... From: some...@big-ips.com, accou...@big-bank.com Subject: Audit notification ... (missing Sender) Isn't that already required to have signatures from each, according to 4871? No, the signature isn't tied to the domain in the From field(s). ___ 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] Focusing on 4871bis
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Dave CROCKER Sent: Friday, October 22, 2010 9:11 AM To: IETF DKIM WG Subject: Re: [ietf-dkim] Focusing on 4871bis Synchronization check... I'm not looking to discuss resolution of these items, but merely verify the current status of the items within the working group. On 10/22/2010 8:28 AM, Barry Leiba wrote: 1. How to handle a key record with empty g= and absent v= (section I thought we had wg consensus to drop g=. That is also my understanding. 2. Advice about wildcards in TXT records. Proposed change: Add a note in section 6.1.2 warning about the effect of wildcard TXT records on finding DKIM key records. This is what is in the pending -03 draft in section 6.1.2: t hangText=NOTE: The use of wildcard TXT records in the DNS will produce a response to a DKIM query that is unlikely to be valid DKIM key record. This problem applies to many other types of queries, and client software that processes DNS responses needs to take this problem into account./t I haven't heard anything but support for adding that. Nit: s/will/can/ 3. The issue of multiple occurrences of header fields that may only occur once. Proposed change: Add text to section 5.3 recommending that verifiers check that the message complies with specs, and that they not validate a non-compliant message. Add a new section 8.14 to the Security Considerations, explaining the attacks that can be done using this exposure. Those are two different changes. My own sense is that each has some controversy, with the first being pretty substantial and with the first having some significant counter-proposals. Yes, that's my understanding as well. (I think you meant first... second instead of first... first.) I'll start a counterproposal to Jim's text in a separate thread. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Focusing on 4871bis
Based on the discussions, and the recent entry to produce a counter proposal I would like to ask if we can trying to avoid putting this document through another cycle of review vs doing the job right with the correct technical information. For example, IDEALLY per your itemize list: 1) g= I owe you some data here. I don't know either way other than I have not seen (or focused on) any particular importance in the API we are using. 2) TXT Records This requires a code adjustment for DKIM DNS clients to parse for the v=DKIM1. This is required for SPF so any implementation that supports SPF and wishes to add DKIM will not be at a terrible lost with this adjustment. 3) Section 5.4 I think Jim's text makes the technical adjustments. But personally, I still believe there needs to be an 5322.From exception paragraph following the section 5.4 last header rule stipulated in the section. I think the choice has to been made on giving this to Team A to get the job done tomorrow, or giving this to Team B to get the job done right even though it may take longer. I personally do not see why the rush is trumping the need to do this right. All this began with a post I made providing Field Experience input regarding how a major MTA had already change how it implemented 4871 with an additional requirement for a single 5322.From and later finding out why they did this, leading to the security loophole discovery issue. This MTA's C/C++ open source API is not locked down to a particular vendor SMTP software and probably represents many other MTAs DKIM implementations, including ours. I just feel we are wasting time with semantics, as important as that may be IETF wise, but I'm afraid it seems to attempt to minimize the importance of having a straight forward technical correction description which may include code change requirements. Thanks for listening. -- Hector Santos, CTO http://www.santronics.com Barry Leiba wrote: We seem to be bush-whacking again, rather than staying on the trail. I don't mind (actually I like) some level of general discussion, but the chairs would like to focus on our immediate goal for now, so I'm asking folks to refrain, for the moment, from discussion that isn't directly addressing the text of 4871bis. That includes discussion of MUA issues. We can go back to talking about that later, but 4871bis is not the place for that, either from a protocol point of view or from a procedural one. We have reviews from Jim, SM, and John that the editors are working on responding to (John's is new enough that I haven't digested it all yet, and I'm sure the editors haven't either). We also have three significant issues that we need to make sure we have resolved satisfactorily: 1. How to handle a key record with empty g= and absent v= (section 6.1.2, list item 6). Proposed change: Remove g= altogether, along with all references to it. Surveys of what's out there show vanishingly few cases that use g= with any value other than * or empty, so this can be removed as an unused feature. 2. Advice about wildcards in TXT records. Proposed change: Add a note in section 6.1.2 warning about the effect of wildcard TXT records on finding DKIM key records. 3. The issue of multiple occurrences of header fields that may only occur once. Proposed change: Add text to section 5.3 recommending that verifiers check that the message complies with specs, and that they not validate a non-compliant message. Add a new section 8.14 to the Security Considerations, explaining the attacks that can be done using this exposure. We ask the editors to consider the latest batches of comments, respond to them as necessary, produce an -03 version, and post it when they have it ready. We ask all participants to speak up specifically about the three issues above, and let us know whether or not the proposed change is acceptable. The editors can post the specific text they're using, if we have anything to discuss about them. I believe we have agreement on the text for number 2, so we should be set on that one. I haven't seen a definitive poll about removing g= (number 1), but I *think* we have consensus on that. Text for number 3 is still being worked on. Please start new threads for these discussions, rather than responding directly to this one, and let's keep the threads for the three items above separate. And, again, we particularly ask all participants to refrain from other discussions that are not specifically about text for 4871bis, so we can get that document done. Thanks, everyone. Barry, as chair ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Multiple occurrences of header fields
On item number 3. I object that the verifier needs to be doing anything other that verifying that the signed headers and other parts match the signature. Its out of scope to have dkim scurrying about enforcing other RFC's compliance. A policy change would be a better solution. Adding a section to the Security considerations is fine. This should be fixed by Policy On Oct 22, 2010, at 11:28 AM, Barry Leiba wrote: We seem to be bush-whacking again, rather than staying on the trail. I don't mind (actually I like) some level of general discussion, but the chairs would like to focus on our immediate goal for now, so I'm asking folks to refrain, for the moment, from discussion that isn't directly addressing the text of 4871bis. That includes discussion of MUA issues. We can go back to talking about that later, but 4871bis is not the place for that, either from a protocol point of view or from a procedural one. We have reviews from Jim, SM, and John that the editors are working on responding to (John's is new enough that I haven't digested it all yet, and I'm sure the editors haven't either). We also have three significant issues that we need to make sure we have resolved satisfactorily: 1. How to handle a key record with empty g= and absent v= (section 6.1.2, list item 6). Proposed change: Remove g= altogether, along with all references to it. Surveys of what's out there show vanishingly few cases that use g= with any value other than * or empty, so this can be removed as an unused feature. 2. Advice about wildcards in TXT records. Proposed change: Add a note in section 6.1.2 warning about the effect of wildcard TXT records on finding DKIM key records. 3. The issue of multiple occurrences of header fields that may only occur once. Proposed change: Add text to section 5.3 recommending that verifiers check that the message complies with specs, and that they not validate a non-compliant message. Add a new section 8.14 to the Security Considerations, explaining the attacks that can be done using this exposure. We ask the editors to consider the latest batches of comments, respond to them as necessary, produce an -03 version, and post it when they have it ready. We ask all participants to speak up specifically about the three issues above, and let us know whether or not the proposed change is acceptable. The editors can post the specific text they're using, if we have anything to discuss about them. I believe we have agreement on the text for number 2, so we should be set on that one. I haven't seen a definitive poll about removing g= (number 1), but I *think* we have consensus on that. Text for number 3 is still being worked on. Please start new threads for these discussions, rather than responding directly to this one, and let's keep the threads for the three items above separate. And, again, we particularly ask all participants to refrain from other discussions that are not specifically about text for 4871bis, so we can get that document done. Thanks, everyone. Barry, as chair ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Focusing on 4871bis
On Oct 22, 2010, at 8:28 AM, Barry Leiba wrote: 1. How to handle a key record with empty g= and absent v= (section 6.1.2, list item 6). Proposed change: Remove g= altogether, along with all references to it. Surveys of what's out there show vanishingly few cases that use g= with any value other than * or empty, so this can be removed as an unused feature. This seems like a good change. 2. Advice about wildcards in TXT records. Proposed change: Add a note in section 6.1.2 warning about the effect of wildcard TXT records on finding DKIM key records. Reasonable. 3. The issue of multiple occurrences of header fields that may only occur once. Proposed change: Add text to section 5.3 recommending that verifiers check that the message complies with specs, and that they not validate a non-compliant message. I'd object fairly strongly to this, for several reasons. A DKIM verifier shouldn't be doing anything other than the cryptography needed to confirm the signature. Also, there's a lot of non-5322 compliant mail out there that's perfectly harmless and wanted. There's also a lot of unwanted or harmful mail out there that violates 5322. DKIM signatures allow receivers to track reputation and distinguish between those two groups. Crippling DKIM so that it can't be used to identify the sender for these categories of email seems perverse. Add a new section 8.14 to the Security Considerations, explaining the attacks that can be done using this exposure. This seems like a good thing to add. Cheers, Steve ___ 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] Focusing on 4871bis
hangText=NOTE: The use of wildcard TXT records in the DNS will produce a response to a DKIM query that is unlikely to be valid DKIM key record. This problem applies to many other types of queries, and client software that processes DNS responses needs to take this problem into account./t I realize that 4871 is already too long, but this is too simplistic. Wildcards within the _domainkey subtree can do reasonable things, e.g., this revokes any unknown key: *._domainkey.example.com. TXT v=DKIM1; p=; n=revoked _adsp._domainkey.example.com. TXT DKIM=unknown ;; override wildcard I agree wildcards higher up the tree are unlikely to produce useful results. 3. The issue of multiple occurrences of header fields that may only occur once. Proposed change: Add text to section 5.3 recommending that verifiers check that the message complies with specs, and that they not validate a non-compliant message. Add a new section 8.14 to the Security Considerations, explaining the attacks that can be done using this exposure. Those are two different changes. My own sense is that each has some controversy, with the first being pretty substantial and with the first having some significant counter-proposals. My preference is still that verifiers reject messages that are likely to display misleadingly in MUAs, e.g., multiple copies of headers that MUAs render one of. This is a rathole if you consider all the junk a bad guy can do in HTML body parts, but at if you insist that the entire body is signed, you can at least say that the garbage the user sees is same garbage that was signed. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Focusing on 4871bis
Those are two different changes. My own sense is that each has some controversy, with the first being pretty substantial and with the first having some significant counter-proposals. My preference is still that verifiers reject messages that are likely to display misleadingly in MUAs, e.g., multiple copies of headers that MUAs render one of. This is a rathole if you consider all the junk a bad guy can do in HTML body parts, but at if you insist that the entire body is signed, you can at least say that the garbage the user sees is same garbage that was signed. That matches my position - such messages should not verify. Though I would generalize the display and MUA part to not verify messages that could mislead subsequence consumers (where a program is a consumer too!) I agree that there is a distinct difference between goop that is part of the signed message and goop that is not. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Commments and clarifications to 4871bis-02
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of John R. Levine Sent: Thursday, October 21, 2010 9:40 PM To: ietf-dkim@mipassoc.org Subject: [ietf-dkim] Commments and clarifications to 4871bis-02 Overall: in several places such as the informative note at the top of page 18, the language says that the verifer produces an edited version of the message. We either should say that the edited message is part of the verifier's output, probably in section 2.2, or delete the editing language. I'd suggest the latter. Based on a pure API perspective, I agree. The verifier's output is a yea/nay about each signature along with possibly some hooks to ask about what the signatures looked like. It doesn't output an altered form of the message. However, I'd be fine with sticking this into Section 8 or an appendix discussing implementation choices. Page 11, informative operations note at the end of section 3.1: Either change to Signers SHOULD NOT reuse a selector with a new key or delete it. Can you say SHOULD NOT in something informative? If you can't, then I'd make this into a regular paragraph instead of an informative note, and apply the SHOULD NOT language. If you can, your change is fine with me. Page 11, informative implementation note at the bottom of the page: Delete it. If we want to support EAI, we should support EAI, but this language just encourages code that won't interoperate. I don't see anything on page 11 about EAI, nor any informative notes. Page 13: section 3.3: should it also say Verifiers MUST implement both sha1 and sha256? It says so on page 20 in a= and page 30 in h=, but I think this is a better place to put it. Works for me. Page 13, informative note at the bottom of the page: Delete. I realize that people still use sha1, so we should document it, but is there any reason to encourage it. I defer here to the security community. I don't think they're as hard on SHA1 as they are on MD5, for example. Page 14, sec 3.3.3, first paragraph. I don't understand what this pp is telling me to do. In the second sentence, what does for long-lived keys mean? A week? A decade? And what's the life of the key? The time from when it's published in the DNS until it's deleted? The time that signers use it, regardless of time in the DNS? Suggest trimming this down to say signers MUST use at least 1024 bits, verifiers MUST handle 512 to 2048 bits, and leave it at that. If we think a 512 bit signature is no good, we should say so. My first inclination is to preserve the sentiment and refer to a policy of frequent key rotation, but that still isn't very specific. Thus, my second inclination is to agree. Page 17, informative implementation note at the top: Delete message editing language or remove text that appears after the specified content length, perhaps based on other criteria Agree. (Though I see that on page 18) Page 17, second informative informative implementation note in the middle: suggest deleting the whole thing. It's a recipe for disaster which has not (I hope) ever been implemented. At least not on purpose. Yep. I'm split between leaving this for an appendix of wacky DKIM ideas or just leaving it to obsolete history. Page 20, informative note under v=: Delete. Has a version number ever increased other than arithmetically? I imagine it was meant as sequentially, but I agree that no adverb there is really needed. Page 22, discussion of d=: Internationalized domain names MUST be represented as A-labels as described in [RFC5891] Page 23, discussion of i=: Internationalized domain names MUST be represented as A-labels as described in [RFC5891] Yes and yes. Page 24. first pp: delete or MAY choose other means of representing its users. An AUID need have no relationship to any user. Some of my AUIDs refer to web scripts and mailing lists. Actually I think that whole sentence is redundant to the earlier text of the paragraph. Page 24, informative note: suggest deleting, again because AUID need have no relation to any user. Or perhaps rewrite as: INFORMATIVE NOTE: The Local-part of the i= tag is optional. It can include the domain part without the Local-part of the identity. Since there are a lot of reasons one might wish to leave out the local-part (don't know, don't want to say, don't feel like it), I'm fine with being this simplistic. Maybe what you have, but tack onto the end if the signer is unable or unwilling to specify a value there? Page 24, informative discussion: delete everything after the second sentence, since it doesn't help robustness or interoperability I could live with it being out, but I like it in there if only to document our deliberations so others later won't have spend the energy to go down the same path. Page 25,
Re: [ietf-dkim] Commments and clarifications to 4871bis-02
Page 11, informative implementation note at the bottom of the page: Delete it. If we want to support EAI, we should support EAI, but this language just encourages code that won't interoperate. I don't see anything on page 11 about EAI, nor any informative notes. Oops, that's page 12, the note about UTF-8 at the bottom. Page 17, informative implementation note at the top: Delete message editing language or remove text that appears after the specified content length, perhaps based on other criteria Agree. (Though I see that on page 18) Right, it's p.18. (It was pretty late, one number starts to look a lot like another.) Page 24. first pp: delete or MAY choose other means of representing its users. An AUID need have no relationship to any user. Some of my AUIDs refer to web scripts and mailing lists. Actually I think that whole sentence is redundant to the earlier text of the paragraph. OK with me. Page 24, informative note: suggest deleting, again because AUID need have no relation to any user. Or perhaps rewrite as: INFORMATIVE NOTE: The Local-part of the i= tag is optional. It can include the domain part without the Local-part of the identity. Since there are a lot of reasons one might wish to leave out the local-part (don't know, don't want to say, don't feel like it), I'm fine with being this simplistic. Maybe what you have, but tack onto the end if the signer is unable or unwilling to specify a value there? Sure. Page 24, informative discussion: delete everything after the second sentence, since it doesn't help robustness or interoperability I could live with it being out, but I like it in there if only to document our deliberations so others later won't have spend the energy to go down the same path. Hmmn. Do we want to say DKIM doesn't identify individual users so don't try to make it do that? If so, it's probably better to put somewhere closer to the top. Page 27, x= first informative note: delete, doesn't help robustness or interoperability. (Neither does x= but that's a lost battle.) I'm not even sure I understand that remark. Can someone remind us of what it's trying to say? We had long arguments in which some people argued that one could keep bad guys from replaying messages by making the x= time short enough. Page 28, z= last pp: it says that header fields SHOULD be converted as described in MIME Part Three [RFC2047]. That document describes encoding of specific character sets such as ISO-8859-1. What character set is it supposed to use? Interesting. I suppose it should be just basic DKIM-quoted-printable conversion, meaning this whole paragraph can go except perhaps to indicate that even eight-bit data can be thus represented. This is one of those places where I don't know how much we can change without the IESG deciding to recycle. Just saying to use QP isn't adequate, since then you couldn't tell whether =BD is the 1/2 symbol in 8859-1, the oe ligature in 8859-15, or those three characters. My inclination is just to take it out, since at this point the 5322 rules say that any non-ASCII should already be MIME-encoded in the headers that z= copies so there shouldn't be anything to downcode. Page 29, sec 3.6.1, first pp: delete, since it doesn't help robustness or interoperability. I had to think about this one for a while. Would it even be appropriate to describe this as the DNS Text Representation, rather than just Text Representation? We might do it a different way in HTTP without XML, for example. There was a bunch of quite hypothetical discussion of other ways to represent and serve keys, none of which ever amounted to anything. That's why I'd rather wait until there actually are other kinds of keys before describing what they are. Page 29, description of v=, last sentence: compare that to the note on page 20 that I suggested deleting. Not sure what you're saying here; did you want that last sentence out? It's saying that if, 1.0 != 1, so much for increasing arithmetically. This language is fine. (My preferred order is 5, 2, 8, 9, 4, 7, 6, 3, 1, 0, which is of course alphabetical order in French.) Top of page 36, first sentence. If we leave in the message editing stuff, change to Hence, DKIM's mandatory output to a receive-side Identity Assessor is a single domain name and a possibly edited version of the message that has been verified. I don't like the edited version stuff. I'd prefer it to be positioned as an explicit indication of what fields and portion of the body were signed. If we agree that's an explicit output, that'd be a rather large change to the spec. My DKIM verifier Mail::DKIM just says yes or no, perhaps with a note about whether failure was DNS related or one of the hashes not matching. Page 36, informative discussion: delete it, since as far as I can tell what it says is we don't know what if anything an AUID will be used
Re: [ietf-dkim] the usual misunderstanding about what DKIM promises
DKIM makes no statement about the validity of a sender address. d/ I guess I should have said Author address. DKIM makes no statement about the validity of an Author address. In practice, if I look at mail with yahoo.com author addresses for example, I find that with DKIM yahoo.com signatures, they're about a million times less likely to be forged than without those signatures. That's not to say that yahoo.com forbid forgery, but they may find that their mail stream reputation improves if they take measures to prevent forgery. Sure. Yahoo goes to some effort to verify that its mail users control the addresses they use, by sending a test message with a URL the user has to click. But that's a characteristic of what Yahoo does which you could tie to a d=yahoo.com signature, not of DKIM in general. I make no attempt at all to control my users' From: lines, since I know them all and don't expect them to misbehave. I do put in trace info to tell who sent what, but you can't tell that from my DKIM signatures, either. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] the usual misunderstanding about what DKIM promises
John Levine wrote: DKIM makes no statement about the validity of a sender address. d/ I guess I should have said Author address. DKIM makes no statement about the validity of an Author address. I keep reading this but there is no technical merit to show there is any truth to it, and in fact the only thing that is probably the strongest validity is the Author Address. No matter how many times it is stated and repeated, it will never be true. If one wants this to be true, then remove the required binding the Author Address, A.K.A 5322.From. I will go on to suggest that this ongoing design confusion of trying to water it down with unrestricted resigners is what got this WG all bogged down in trying to teach the world that the From really means nothing but only the signer does. It even reduces the incentive for adopters to invest in Domain DKIM Signing because they really have no power over controlling who can take control of their own messages or those that purports to be from them. They have really little payoff. My point is it really hasn't help DKIM to continue to water down the validity of the author address. If it wasn't a required binding, then there begins some truth to the statement. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Commments and clarifications to 4871bis-02
On Friday, October 22, 2010 09:38:47 pm John Levine wrote: This is one of those places where I don't know how much we can change without the IESG deciding to recycle. I think we should decide what's best for the long term health of the protocol and then let the IESG worry about recycling or not. Getting it right is more important than advancing up the standards ladder. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Commments and clarifications to 4871bis-02
At 21:39 21-10-10, John R. Levine wrote: Overall: in several places such as the informative note at the top of page 18, the language says that the verifer produces an edited version of the message. We either should say that the edited message is part of the verifier's output, probably in section 2.2, or delete the editing language. I'd suggest the latter. I suggest the latter. Page 11, informative operations note at the end of section 3.1: Either change to Signers SHOULD NOT reuse a selector with a new key or delete it. As it is informative, it is better to avoid the SHOULD NOT. Page 11, informative implementation note at the bottom of the page: Delete it. If we want to support EAI, we should support EAI, but this language just encourages code that won't interoperate. That depends on the text in Section 3.5 on which I commented previously. Page 13: section 3.3: should it also say Verifiers MUST implement both sha1 and sha256? It says so on page 20 in a= and page 30 in h=, but I think this is a better place to put it. Yes. Page 13, informative note at the bottom of the page: Delete. I realize that people still use sha1, so we should document it, but is there any reason to encourage it. Yes. Page 14, sec 3.3.3, first paragraph. I don't understand what this pp is telling me to do. In the second sentence, what does for long-lived keys mean? A week? A decade? And what's the life of the key? The time from when it's published in the DNS until it's deleted? The time that signers use it, regardless of time in the DNS? Suggest trimming this down to say signers MUST use at least 1024 bits, verifiers MUST handle 512 to 2048 bits, and leave it at that. If we think a 512 bit signature is no good, we should say so. The long-lived keys is related to the time it takes to succumb to an attack. I would say that the validity is as long as the keys can be used to verify a message. Page 20, informative note under v=: Delete. Has a version number ever increased other than arithmetically? I suggest keeping this as version numbering is always a problem. Page 24. first pp: delete or MAY choose other means of representing its users. An AUID need have no relationship to any user. Some of my AUIDs refer to web scripts and mailing lists. Page 24, informative note: suggest deleting, again because AUID need have no relation to any user. Or perhaps rewrite as: I suggest not touching those two to avoid rehashing previous discussions. Page 24, informative discussion: delete everything after the second sentence, since it doesn't help robustness or interoperability See above. Page 25, informative implementation warning: remove language at the end of the paragraph suggesting that the verifier can remove text from the body. Yes. Page 29, description of v=, last sentence: compare that to the note on page 20 that I suggested deleting. I suggest keeping it. Page 45, second pp of section 6: shouldn't this refer to RFC5451 rather than just a verification header ? My previous comment about this was ignored. At 17:39 22-10-10, Murray S. Kucherawy wrote: Can you say SHOULD NOT in something informative? No. Page 27, x= first informative note: delete, doesn't help robustness or interoperability. (Neither does x= but that's a lost battle.) I'm not even sure I understand that remark. Can someone remind us of what it's trying to say? x= should not be considered as a way to mitigate replay attacks. Verifiers SHOULD treat invalid signatures as though they were not present in the message. Verifiers SHOULD ignore invalid signatures ... I think the idea is that RFC5451 is one example of an annotation system, so a verification header field such as the one described in RFC5451 would probably be fine. You argued for standardization of the header field. Regards, -sm ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
