[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] 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: 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. > 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] 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: > > 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. 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://mip
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] 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. 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] Focusing on 4871bis
--On 22 October 2010 11:23:16 -0700 "Murray S. Kucherawy" wrote: >> This is what is in the pending -03 draft in section 6.1.2: >> >>> 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. > > I haven't heard anything but support for adding that. > > Nit: s/will/can/ More Nit: It should probably say either "will produce a response…that is unlikely", or "can produce a response…that is not". The former states that the problem will occur frequently, the latter says nothing about the frequency, but readers may infer that the problem will be infrequent. -- 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
