Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
My apologies for the delay in this; I meant to send this early this week, after getting back in town, but... then I didn't get to it. The chairs appreciate the view that the errata draft makes a lot of changes. Nevertheless, the view that those changes are too great... is quite a minority view. The only concrete objection we've seen in this latest round is about the UAID term, and that appears to be resolved by making it AUID. Beyond that, I've seen no clear objections and no alternative text proposed. Rough consensus appears to be with the errata draft, with the AUID change made to it. So there it is. We have time on the agenda next week for discussion of this, and I think that item will be brief. We have consensus on this text -- and yes, I note that it's given only grudgingly by some. I expect to spend the face-to-face time in getting agreement on the mechanism to proceed (RFC vs non-IESG-approved errata), and in discussing where ADSP is and how to proceed on that. Barry -- Barry Leiba, DKIM working group chair (barryle...@computer.org) http://internetmessagingtechnology.org/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
DKIM Chair wrote: My apologies for the delay in this; I meant to send this early this week, after getting back in town, but... then I didn't get to it. The chairs appreciate the view that the errata draft makes a lot of changes. Nevertheless, the view that those changes are too great... is quite a minority view. The only concrete objection we've seen in this latest round is about the UAID term, and that appears to be resolved by making it AUID. Beyond that, I've seen no clear objections and no alternative text proposed. Rough consensus appears to be with the errata draft, with the AUID change made to it. So there it is. Um, the reason I didn't say anything is because of how the question was phrased. Rather like: would you prefer your poison on the rocks, or straight up?. As I've said many times, the non-Crocker-inserted parts of the errata are not controversial. Nuking his parts in the entirety would be by far the most expeditious and would easily fit within the errata framework. Only having the choice of a poison pill or nothing just plain sucks. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
DKIM Chair wrote: My apologies for the delay in this; I meant to send this early this week, after getting back in town, but... then I didn't get to it. The chairs appreciate the view that the errata draft makes a lot of changes. Nevertheless, the view that those changes are too great... is quite a minority view. The only concrete objection we've seen in this latest round is about the UAID term, and that appears to be resolved by making it AUID. The question of whether the errata draft's changes are too great relates to whether it can be processed using the errata process or whether it requires IETF rough consensus. However, in http://mipassoc.org/pipermail/ietf-dkim/2009q1/011421.html , Pasi ruled that it requires IETF rough consensus because it might differ from the intended consensus when RFC 4871 was approved. So isn't the question of the size of the changes moot? Beyond that, I've seen no clear objections and no alternative text proposed. Rough consensus appears to be with the errata draft, with the AUID change made to it. So there it is. I still owe the list a more extensive set of comments, which I had promised in a few days. I will send those today. We have time on the agenda next week for discussion of this, and I think that item will be brief. We have consensus on this text -- and yes, I note that it's given only grudgingly by some. I expect to spend the face-to-face time in getting agreement on the mechanism to proceed (RFC vs non-IESG-approved errata), and in discussing where ADSP is and how to proceed on that. Based on Pasi's comments, I had thought we were going the RFC route. -Jim ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
OK, now I'm confused. Can someone define IETF rough consensus? The errata had a 2/3 majority after the last round of discussion... does the IETF ever get a better consensus than that? Pasi's point is that what you're quoting is from the DKIM working group only, and, at that, only from some 20 participants or so. There are a lot more people who participate in the IETF, and the normal process of review by the IESG and IETF last call provides the opportunity for many more people to review and comment on the document. Barry ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
From: ietf-dkim-boun...@mipassoc.org [ietf-dkim-boun...@mipassoc.org] On Behalf Of Jim Fenton [fen...@cisco.com] Sent: Friday, March 20, 2009 10:56 AM To: DKIM Chair Cc: DKIM Mailing List Subject: Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata The question of whether the errata draft's changes are too great relates to whether it can be processed using the errata process or whether it requires IETF rough consensus. However, in http://mipassoc.org/pipermail/ietf-dkim/2009q1/011421.html , Pasi ruled that it requires IETF rough consensus because it might differ from the intended consensus when RFC 4871 was approved. So isn't the question of the size of the changes moot? OK, now I'm confused. Can someone define IETF rough consensus? The errata had a 2/3 majority after the last round of discussion... does the IETF ever get a better consensus than that? Based on Pasi's comments, I had thought we were going the RFC route. Given the likely time frame for an updated RFC (-bis or otherwise), I'd like to make really sure that's the only option. Letting the Errata go through as errata and then following up with the -bis seemed like the best option to me... something gets out quickly, and then the more complete update follows. I'm hoping we can have some discussion around this next week. Ellen ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
DKIM Chair wrote: Beyond that, I've seen no clear objections and no alternative text proposed. Rough consensus appears to be with the errata draft, with the AUID change made to it. So there it is. I've placed a revised draft errata at: http://dkim.org/#sign which associates it directly to the original signing spec, RFC 4871. It does the string replacement for AUID and it has a NOTE indicating working group approval. I expect to spend the face-to-face time in getting agreement on the mechanism to proceed (RFC vs non-IESG-approved errata), Right. non-IESG-approved is important phrasing. Folks might realize that anyone can post anything they want under the errata mechanism. The issue with IESG approval affects the status label that is associated with that entry. Anything other than Rejected is likely to serve our purposes, until the change is folded into RFC4871bis. On the matter of whether to issue the Errata under Errata or defer its release further, we should consider how long the delay is likely to be, especially given the unspecified scope of RFC4871bis. Some folks assume that the scope is trivially small, but a bis effort that is seeking Draft status can -- and, IMO, should -- carefuly review the specification and remove what has proven extraneous. 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] Moving to consensus on draft-ietf-dkim-rfc4871-errata
Siegel, Ellen wrote: OK, now I'm confused. Can someone define IETF rough consensus? The errata had a 2/3 majority after the last round of discussion... does the IETF ever get a better consensus than that? There's a difference between IETF rough consensus versus Working Group rough consensus. The vote we just took measures the latter. To evaluate IETF consensus requires an IETF-wide Last Call and an IESG assessment of the results. Based on Pasi's comments, I had thought we were going the RFC route. Well, he has a preference for /only/ going that route, but he can't actually veto our issuing the Errata under the Errata mechanism. Anyone can post anything they want under the Errata mechanism. Some pretty silly stuff has gotten posted, over the years. What Pasi /can/ do and has done is offer his assessment of the likely IESG decision about the /status/ that would be assigned to the Errata. In particular, he has a reading of the IESG rules for Errata which says that anything that is controversial cannot be approved. Unfortunately, I think his interpretation of the relevant rule's text is reasonable, based on the latest explanation he provided. I think it's a bad rule and should be changed, but dealing with that is different from debating his interpretation. In other words, I think he's providing a reasonable interpretation of a bad rule and that, for now, we have to live with it. The alternative labels available to our Errata, if issued through the Errata mechanism, are rejected and hold. In my view, hold, with text in the Errata that states there is working group consensus, is sufficient. Not ideal, but sufficient. It provides an official publication channel sooner, rather than later. Given wg approval, we aren't likely to see the label rejected get assigned... Given the likely time frame for an updated RFC (-bis or otherwise), I'd like to make really sure that's the only option. Letting the Errata go through as errata and then following up with the -bis seemed like the best option to me... something gets out quickly, and then the more complete update follows. +1 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] Moving to consensus on draft-ietf-dkim-rfc4871-errata
On Mar 19, 2009, at 11:22 PM, DKIM Chair wrote: The chairs appreciate the view that the errata draft makes a lot of changes. Nevertheless, the view that those changes are too great... is quite a minority view. The only concrete objection we've seen in this latest round is about the UAID term, and that appears to be resolved by making it AUID. Beyond that, I've seen no clear objections and no alternative text proposed. Rough consensus appears to be with the errata draft, with the AUID change made to it. So there it is. There have been suggested changes to the text that was made previously. There did not seem to be a reason to repeat the same objections and proposed changes when there did not appear to be agreement on going forward with portions of the errata that change prior definitions. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
On Mar 20, 2009, at 9:55 AM, Barry Leiba wrote: Pasi's point is that what you're quoting is from the DKIM working group only, and, at that, only from some 20 participants or so. There are a lot more people who participate in the IETF, and the normal process of review by the IESG and IETF last call provides the opportunity for many more people to review and comment on the document. The concern seemed more related to making definitional changes to an an RFC within an errata. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] RFC4871bis: considering some guidelines to the effort
Folks, What is the scope of problems DKIM should try to protect against? A DKIM signature means that whoever controls the DNS entry for the SDID is taking some responsibility for the message. A random bad actor, out there in the wilds of the Internet, cannot use that SDID. This is the core benefit of DKIM. Then there is the question of controlling different employees, within the organization that owns the SDID. Perhaps I'm authorized to do signing, but the janitor in my organization isn't. Should a receiver that is validating a signature be asked to take on the burden of enforcing access rules within the signing organization? Protecting against outside attacks is inherent in DKIM's goal. Protecting against attacks or misbehaviors from within the domain owner's own organization strikes me as an inappropriate shifting of enforcement burden onto the recipient. If the working group agrees, then we have an opportunity to simplify DKIM. Similarly, there are some features that aren't getting used, and that are not showing any signs of getting used. Dropping them also permits making DKIM substantially simpler. 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] Moving to consensus on draft-ietf-dkim-rfc4871-errata
At 09:41 20-03-2009, Siegel, Ellen wrote: OK, now I'm confused. Can someone define IETF rough consensus? The errata had a 2/3 majority after the last round of discussion... does the IETF ever get a better consensus than that? The Standards Process requires that a proposed standard be reviewed by the IETF community to establish whether it has the consensus. This Working Group, for example, is only a subset of the IETF community. The Working Group can be used to to determine whether it is worth asking the IETF community to review a proposal. However, it cannot act as a substitute for the IETF community. There isn't a formal definition of IETF rough consensus. From the Tao: a simple version is that it means that strongly held objections must be debated until most people are satisfied that these objections are wrong Regards, -sm ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
Dave CROCKER wrote: Based on Pasi's comments, I had thought we were going the RFC route. Well, he has a preference for /only/ going that route, but he can't actually veto our issuing the Errata under the Errata mechanism. Anyone can post anything they want under the Errata mechanism. Some pretty silly stuff has gotten posted, over the years. I believe that what Dave is suggesting is an end run around the IESG. In which case, I suggest that the working group insist on s/our/my/g; above so that it has similar status. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
Thanks, all, for the clarification. I read too quickly and missed the semantic distinction between IETF consensus was and IETF working group consensus. Ellen -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of SM Sent: Friday, March 20, 2009 2:39 PM To: DKIM Mailing List Subject: Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871- errata At 09:41 20-03-2009, Siegel, Ellen wrote: OK, now I'm confused. Can someone define IETF rough consensus? The errata had a 2/3 majority after the last round of discussion... does the IETF ever get a better consensus than that? The Standards Process requires that a proposed standard be reviewed by the IETF community to establish whether it has the consensus. This Working Group, for example, is only a subset of the IETF community. The Working Group can be used to to determine whether it is worth asking the IETF community to review a proposal. However, it cannot act as a substitute for the IETF community. There isn't a formal definition of IETF rough consensus. From the Tao: a simple version is that it means that strongly held objections must be debated until most people are satisfied that these objections are wrong Regards, -sm ___ 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] Moving to consensus on draft-ietf-dkim-rfc4871-errata
Mike says... Dave CROCKER wrote: Based on Pasi's comments, I had thought we were going the RFC route. Well, he has a preference for /only/ going that route, but he can't actually veto our issuing the Errata under the Errata mechanism. Anyone can post anything they want under the Errata mechanism. Some pretty silly stuff has gotten posted, over the years. I believe that what Dave is suggesting is an end run around the IESG. In which case, I suggest that the working group insist on s/our/my/g; above so that it has similar status. Mike, I take what you're saying to mean that you don't think the working group is behind an end run around the IESG, and that the errata should not be saying that it is. What path we take to publish the errata beyond the ID that it is now, and whether the WG is behind publishing it without Pasi's (or the IESG's) approval, are things we'll be discussing in San Francisco and on the mailing list. I hope that when we leave SF we'll have most of the answer to these, which answer we'll confirm on the mailing list. I think we need the high-bandwidth discussion, with Pasi in the room and responding, to get this point resolved in a way that doesn't leave everyone waving scimitars at everyone else. We need to be discussing things productively as we go into final processing of ADSP and into 4871bis and Draft Standard consideration. (I'm going to try to get a conference call set up and use Skype and a microphone to allow remote participants to talk. I know we've failed at that before, but I want to try again.) So while I'm on the cooperation and productivity bit To everyone: Please say what you mean calmly and clearly, so there's less chance of misunderstanding or the taking of offense where none was meant. And please don't mean offense, either, of course. Digs, snarkiness, and passive-aggressiveness won't keep us moving forward. Barry -- Barry Leiba, DKIM working group chair (barryle...@computer.org) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
Barry Leiba wrote: Mike says... Dave CROCKER wrote: Based on Pasi's comments, I had thought we were going the RFC route. Well, he has a preference for /only/ going that route, but he can't actually veto our issuing the Errata under the Errata mechanism. Anyone can post anything they want under the Errata mechanism. Some pretty silly stuff has gotten posted, over the years. I believe that what Dave is suggesting is an end run around the IESG. In which case, I suggest that the working group insist on s/our/my/g; above so that it has similar status. Mike, I take what you're saying to mean that you don't think the working group is behind an end run around the IESG, and that the errata should not be saying that it is. Close. I'm saying that it toes the line of completely inappropriate for a _working group_ to consider an end run around the IESG, and that we ought not consider that as an option for the working group. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
Barry Leiba wrote: So while I'm on the cooperation and productivity bit To everyone: Please say what you mean calmly and clearly, so there's less chance of misunderstanding or the taking of offense where none was meant. And please don't mean offense, either, of course. Digs, snarkiness, and passive-aggressiveness won't keep us moving forward. Barry, what prompted this? 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] Moving to consensus on draft-ietf-dkim-rfc4871-errata
On March 10, 2009, I wrote: DKIM Chair wrote: To those who voted against draft-ietf-dkim-rfc4871-errata: given, now, that we will be using draft-ietf-dkim-rfc4871-errata to move forward, and the other choices are off the table, can you accept draft-ietf-dkim-rfc4871-errata as written? If not, will you post specific changes, in OLD/NEW format, that would make it acceptable to you? Acceptable changes must keep the sense of the draft-ietf-dkim-rfc4871-errata document with regard to the new terminology. I can do that, but it will probably take a few days. Here are the rest of my comments on the draft. My comments are based on draft-ietf-dkim-rfc4871-errata-02 with the additional change from UAID to AUID. Perhaps user or agent should also change to agent or user but I'm neutral on that. 0. Change the title to RFC 4871 Update if it is not being processed using the errata process per Pasi's comments. = 1. Introduction. The introduction, particularly paragraphs 2 and 3, assert that the payload (the output of DKIM verification) is only a validated signing domain. The output of DKIM verification is considerably more than that: there are a great many values, such as the list of signed header fields, that may be useful to an assessor and that must be made available to the assessor if the verifier is to be as interoperable with as many assessors as possible. Furthermore, not requiring a verifier to output unknown tag/values makes DKIM non-extensible: What's the point of adding new tag/value definitions if all the verifier is going to output is the SDID? RFC 4871 somewhat narrowly defines a protocol between the signer and verifier. It does not define the semantics of everything that DKIM might convey; that was left for the overview and/or operations documents. To say that RFC 4871 has the potential for non-interoperable interpretations of how DKIM operates is to criticize the specification for something that is out of its scope. Suggested change: Replace everything beginning with paragraph 2 of the introduction with the following (and delete the remainder of the introduction): NEW: Hence, DKIM has a signer that applies a signature to a message, a verifier that confirms the signature, and DKIM interfaces with an assessor what consumes the validated signing information. This document attempts to clarify the meaning of identifier fields appearing in the DKIM signature to arrive at a more consistent use of these fields by verifiers. = 6. SDID definition I am confused by the definition of the SDID as opaque. This makes it sound like it's a pseudonym for the actual signing domain. The fact that it's possible to look up information about the SDID using DNS doesn't seem opaque to me. OLD: A single, opaque value that is the mandatory payload output of DKIM NEW: A single value that is a mandatory payload output of DKIM = 7. AUID definition Portions of the AUID are opaque, but not the whole thing because it has to have a specified relationship with the SDID. I would also clarify that there is always an AUID, even if it isn't explicitly specified in the signature and takes its default value. OLD: A single, opaque value that identifies the user or agent on behalf of whom the SDID has taken responsibility. It is specified in Section 3.5. NEW: A single value that identifies that agent or user on behalf of which the SDID has taken responsibility. The AUID has the syntax of an email address, although the local-part and any subdomain of the SDID which is used are opaque values which may not actually exist nor have any relationship with other identifiers in the message. It is specified in Section 3.5. The AUID takes the default value specified if it is not explicitly present in the signature. = 8. Identity Assessor The term is imprecise: it is not assessing an identity but a message. Suggest replacing this name with just assessor as is used in the Introduction. = 9. d= tag definition The corrected text removes the required relationship between the SDID and the AUID, which is perhaps repetitive of information in the i= tag definition, but which we felt important to repeat in the original document for emphasis. The narrative about conventions and semantics does not belong in the normative text describing the tag, and I'm not clear what it's trying to say in any case. The text also repeats much of the wording in the definition of SDID about claiming responsibility and such. NEW: The SDID of the signing entity (plain-text; REQUIRED). This is the domain that will be quieried for the public key. The SDID MUST be the same as or a parent of the domain in the AUID (the i= value, as described below) and MUST meet the requirements for parent domain signing described in Section 3.8. When presented with a signature that does not meet these requirement, verifiers MUST consider the signature invalid. = 10. i= tag definition paragraph 2,
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
So while I'm on the cooperation and productivity bit To everyone: Please say what you mean calmly and clearly, so there's less chance of misunderstanding or the taking of offense where none was meant. And please don't mean offense, either, of course. Digs, snarkiness, and passive-aggressiveness won't keep us moving forward. Barry, what prompted this? Nothing terribly special... mostly two points: 1. The way Mike made his point left lots of room for people to take it in different ways, and I wanted to remind folks to be clear. 2. Over time, various participants have angered various others, often leading to offline (and sometimes online) complaints. I just wanted to use the opportunity to remind everyone that snark doesn't help, even if it momentarily makes one feel good. The reminder wasn't addressed specifically. Barry ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
On Fri, 20 Mar 2009 16:42:30 -0400 Barry Leiba barryle...@computer.org wrote: Mike says... Dave CROCKER wrote: Based on Pasi's comments, I had thought we were going the RFC route. Well, he has a preference for /only/ going that route, but he can't actually veto our issuing the Errata under the Errata mechanism. Anyone can post anything they want under the Errata mechanism. Some pretty silly stuff has gotten posted, over the years. I believe that what Dave is suggesting is an end run around the IESG. In which case, I suggest that the working group insist on s/our/my/g; above so that it has similar status. Mike, I take what you're saying to mean that you don't think the working group is behind an end run around the IESG, and that the errata should not be saying that it is. What path we take to publish the errata beyond the ID that it is now, and whether the WG is behind publishing it without Pasi's (or the IESG's) approval, are things we'll be discussing in San Francisco and on the mailing list. I hope that when we leave SF we'll have most of the answer to these, which answer we'll confirm on the mailing list. I think we need the high-bandwidth discussion, with Pasi in the room and responding, to get this point resolved in a way that doesn't leave everyone waving scimitars at everyone else. We need to be discussing things productively as we go into final processing of ADSP and into 4871bis and Draft Standard consideration. (I'm going to try to get a conference call set up and use Skype and a microphone to allow remote participants to talk. I know we've failed at that before, but I want to try again.) So while I'm on the cooperation and productivity bit To everyone: Please say what you mean calmly and clearly, so there's less chance of misunderstanding or the taking of offense where none was meant. And please don't mean offense, either, of course. Digs, snarkiness, and passive-aggressiveness won't keep us moving forward. Then in the spirit of plain speaking: I do think that the current draft attempts to alter IETF consensus via the erata process in a way that is inappropriate. While I think that Mike's objection was formulated in a way that unfortunately strucutred around personality, I agree that the content to which he was referring should be dropped from an eratum and addressed when the RFC is revised. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
The output of DKIM verification is considerably more than that: there are a great many values, such as the list of signed header fields, that may be useful to an assessor and that must be made available to the assessor if the verifier is to be as interoperable with as many assessors as possible. We seem to have a fairly basic disconnect here. As far as I'm concerned, an assessor has better things to worry about than the internal details of the signature. Trying to reverse engineer or guess what the signer had in mind would be a hopeless swamp even if it were desirable. Sure, it's possible to put on a worthless signature that leaves out crucial headers, but signers who do so won't get a very good reputation so the problem should be self-limiting. There's no existing installed base of inept signers we have to work around, and it would be a poor idea do anything that would allow crummy signatures to appear to work. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
John Levine wrote: The output of DKIM verification is considerably more than that: there are a great many values, such as the list of signed header fields, that may be useful to an assessor and that must be made available to the assessor if the verifier is to be as interoperable with as many assessors as possible. We seem to have a fairly basic disconnect here. As far as I'm concerned, an assessor has better things to worry about than the internal details of the signature. Trying to reverse engineer or guess what the signer had in mind would be a hopeless swamp even if it were desirable. Sure, it's possible to put on a worthless signature that leaves out crucial headers, but signers who do so won't get a very good reputation so the problem should be self-limiting. There's no existing installed base of inept signers we have to work around, and it would be a poor idea do anything that would allow crummy signatures to appear to work. If assessors can't be bothered, then how will reputation systems know the difference? You really can't have it both ways. In any case, this is a false dilemma; it's not just crummy signatures at issue. And what you call a hopeless swamp, I call RFC 4871. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
We seem to have a fairly basic disconnect here. As far as I'm concerned, an assessor has better things to worry about than the internal details of the signature. Trying to reverse engineer or guess what the signer had in mind would be a hopeless swamp even if it were desirable. ... If assessors can't be bothered, then how will reputation systems know the difference? Sorry, but I have no idea what the antecedent to this question is supposed to be. The difference between what and what? Assessors know whether a message is signed, and if it has valid signature(s), the domain(s) that signed them. All that other stuff in the signature is implementation details. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
John R. Levine wrote: We seem to have a fairly basic disconnect here. As far as I'm concerned, an assessor has better things to worry about than the internal details of the signature. Trying to reverse engineer or guess what the signer had in mind would be a hopeless swamp even if it were desirable. ... If assessors can't be bothered, then how will reputation systems know the difference? Sorry, but I have no idea what the antecedent to this question is supposed to be. The difference between what and what? You wrote: Sure, it's possible to put on a worthless signature that leaves out crucial headers, but signers who do so won't get a very good reputation so the problem should be self-limiting. There's no existing installed base of inept signers we have to work around, and it would be a poor idea do anything that would allow crummy signatures to appear to work. If assessors can't be bothered to assess the supposedly self-limiting implementation details, then reputation systems can not take them into account. By definition. Assessors know whether a message is signed, and if it has valid signature(s), the domain(s) that signed them. All that other stuff in the signature is implementation details. RFC 4871 gives no precise definition of what an assessor can use to make whatever decisions it wants to draw from the message *and* the signature(s). That you have a particular use case in mind that doesn't care about implementation details does not and should not imply that that is the only valid use of DKIM information. That is why the errata is so wrong headed. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
If assessors can't be bothered to assess the supposedly self-limiting implementation details, then reputation systems can not take them into account. By definition. Right. That's a feature. It's not my job to work around or even identify crappy signatures. If there's junk in your signed mailstream, I'm not likely to accept your mail, regardless of how it got there. I have no interest whatsoever in trying to pick apart signatures and guessing which ones are particularly gnarly and which ones are sort of froody. They're either valid or they aren't, per 4871. RFC 4871 gives no precise definition of what an assessor can use to make whatever decisions it wants to draw from the message *and* the signature(s). Right. That's why we're clarifying it. R's, John PS: So if if I'm wrong and assessors are going to use implementation details, how do you expect them to use the fact that this message has a signed Cleverness header? Please be specific. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
On 3/20/09, Michael Thomas m...@mtcc.com wrote: John R. Levine wrote: Assessors know whether a message is signed, and if it has valid signature(s), the domain(s) that signed them. All that other stuff in the signature is implementation details. RFC 4871 gives no precise definition of what an assessor can use to make whatever decisions it wants to draw from the message *and* the signature(s). That you have a particular use case in mind that doesn't care about implementation details does not and should not imply that that is the only valid use of DKIM information. That is why the errata is so wrong headed. +1 -- hls ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] DKIM diagrams
Steve, Nice evening. Thanks for coming over. The DKIM-related diagrams that you might find relevant: 1. DKIM Service Architecture http://dkim.org/specs/draft-ietf-dkim-overview-10.html#DKIMSvc 2. Figure 1, Actors in a Trust Sequence using DKIM, in: http://dkim.org/specs/draft-ietf-dkim-deployment-03.html 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] DKIM diagrams
wow. no idea how the note got vectored to the wg list. sorry. d/ Dave CROCKER wrote: Steve, Nice evening. Thanks for coming over. The DKIM-related diagrams that you might find relevant: 1. DKIM Service Architecture http://dkim.org/specs/draft-ietf-dkim-overview-10.html#DKIMSvc 2. Figure 1, Actors in a Trust Sequence using DKIM, in: http://dkim.org/specs/draft-ietf-dkim-deployment-03.html 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] Moving to consensus on draft-ietf-dkim-rfc4871-errata
John Levine wrote: The output of DKIM verification is considerably more than that: there are a great many values, such as the list of signed header fields, that may be useful to an assessor and that must be made available to the assessor if the verifier is to be as interoperable with as many assessors as possible. We seem to have a fairly basic disconnect here. As far as I'm concerned, an assessor has better things to worry about than the internal details of the signature. Trying to reverse engineer or guess what the signer had in mind would be a hopeless swamp even if it were desirable. On the other hand, we definitely don't have enough information about assessors to know what information they need. Saying that the SDID is the only thing they can depend on getting from the verifier is too constraining. Sure, it's possible to put on a worthless signature that leaves out crucial headers, but signers who do so won't get a very good reputation so the problem should be self-limiting. There's no existing installed base of inept signers we have to work around, and it would be a poor idea do anything that would allow crummy signatures to appear to work. The worthless signature may not have been so worthless if one of the header fields in question wasn't present at the time of signing, but was added later. There have been proposals to convey some information relating to assessment (for example, Jon Callas's suggestion at http://mipassoc.org/pipermail/ietf-dkim/2009q1/011104.html ) by putting it in a separate header field and signing it. Are you suggesting that whether that header field is signed or not is irrelevant to the assessor? -Jim ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
