Re: [ietf-dkim] New Issue: The term identity in the overview
J D Falk wrote: > We should not let forward progress be halted by the possibility that > someone might establish an entirely-internal-to-them policy that some of > us might disagree with. s/might/will/ ... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] New white paper: Trust in Email Begins with Authentication
FYI: The Messaging Anti-Abuse Working Group (MAAWG) has just issued a white paper, titled: "Trust in Email Begins with Authentication" I was editor for the paper. From the press release for the paper: "Setting the stage for a better understanding of sender authentication as a technology to combat junk email... [the paper focuses] on the standardized mechanisms in general use today, Sender Policy Framework (SPF), Sender IDentification Framework (SenderID), and DomainKeys Identified Mail (DKIM). "[one-page] summary of the MAAWG paper provides an overview of how authentication can be used to protect email and is intended for general business managers. The main body provides more detail on SPF, SenderID, and DKIM mechanisms and is intended for technical readers familiar with basic Internet mail service." Note that the executive summary can be used standalone, for management and other non-technical introductions to the topic of authentication in aid of email anti-abuse. A copy of the paper is at: <http://www.maawg.org/about/publishedDocuments/MAAWG_Email_Authentication_Paper.pdf> The full press release for it is at: <http://www.maawg.org/news/maawg080401> d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree
Folks, This issue encompasses some others, but I believe it is more basic and therefore informs the others and therefore needs to be resolved separately: There is a basic difference between trying to protect a single domain name, versus trying to protect an entire sub-tree. 1. The DNS was not designed with sub-tree operators. The wildcard mechanism is a very narrowly-defined capability and is useless in the face of underscore-based naming, since the underscore node really defines an attribute of the domain name it is under, rather than defining a true "name". What this leaves us with is attempting to invent mechanisms that turn out to do only a partial job, at best. 2. Some of the sub-tree effort is for administrative convenience. Some is for expanded semantics. It's not clear that the specification is clear about this distinction. It is not clear that the specification is clear about the motivations that make it mandatory to add sub-tree mechanisms to the specification. 3. At least one of the sub-tree mechanisms is attempting to glean information from the absence of publisher action. Let me explain: I believe the desire with checking the A record is similar to the idea behind having ADSP in the first space. That is: a) DKIM is for declaring the presence of an accountable identity. If a signature is present, you know something. If it is absent, you know nothing extra. b) ADSP attempts to tell you something, in the absence of a signature. It does that by defining something else that must be present. If the ADSP record is present, you know something. If it is absent, you know nothing extra. c) Checking for the presence of an A record is intended to try tell you something in the absence of an explicit action by the domain owner. That's it's flaw: It is intuiting ADSP information from non-ADSP action. While there is nothing wrong with checking the A record, it's semantics have literally nothing (directly) to do with ADSP. All of the above is of course implies some specific actions, but for this note, my real goal is to get much more explicit discussion and consensus about the difference between protecting a single domain name, versus protecting a tree of names, and to get consensus about each of these as separable goals. 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] New Issue: protecting a domain name vs. protecting a domain tree
Barry Leiba wrote: > Eliot Lear said the following: >> By my recollection, >> this topic alone has been discussed at at least two - and possibly three >> - working group meetings. Please advise. > This topic has definitely been discussed a number of times. The focus of my note wason the contents of the specification, not on previous discussion. I'll repeat that distinction: The current draft does not deal with exact-name vs. sub-tree issues as an explicit point of distinction; it has bits of each scattered around. As such, the specification is, at best, confusing on the distinction, nevermind incomplete on the tree construct. But with respect to the working group's history of discussing this topic I'll first thank Eliot for citing the recently-closed Issue. It was quite instructive to go back and read the associated mailing list thread. I strongly encourage others also to do read that thread <http://mipassoc.org/pipermail/ietf-dkim/2006q4/006377.html> since I think it substantiates my concerns, rather than resolves them: 1. The cited thread shows a complete lack of anything one might call consensus. 2. The cited thread pretty much shows a complete lack of coherence. 3. I have no idea what the basis was for the chairs declaring the matter resolved. This is an inherent problem with closing items by fiat and without explanation. Bottom lines: a. There is a difference between having discussed something and having resolved it. b. The current draft is, at best, confusing about the distinction of exact vs. tree c. There is no technical means for doing a clean, efficient and thorough job of "protecting" a sub-tree, when using the DNS. It wasn't designed for that use and it doesn't handle it for scenarios such as DKIM needs. Consequently, it is not surprising that the current specification's component mechanisms for "protecting" a sub-tree are partial, at best. > The particular point in Dave's note that troubles me, and that I don't > think we have agreement on, is his third one: > >> 3. At least one of the sub-tree mechanisms is attempting to glean >> information >> from the absence of publisher action. Let me explain: > ... >>> c) Checking for the presence of an A record is intended to try >>> tell you >>> something in the absence of an explicit action by the domain owner. That's >>> it's >>> flaw: It is intuiting ADSP information from non-ADSP action. >>> >>> While there is nothing wrong with checking the A record, it's >>> semantics >>> have literally nothing (directly) to do with ADSP. > > I agree with that assessment, but more importantly, I think the working > group doesn't yet agree on whether he's right or not. Right about what? There is a factual assertion that an existing A record will have been created for reasons other than ADSP. That's a statement of fact, not opinion. A records are not created for any purpose having to do with ADSP. If someone disagrees with the statement of fact, they need to substantiate it. And, yes, if they force such an exercise, I'll substantiate my assertion of objective fact. Since the A record is not created for ADSP, how can its semantics have anything to do with ADSP? Again, this is in the realm of objective fact, not opinion or preference. So I'm unclear what the working group could disagree with. (I'm concerned that we are in the realm of operating on the basis that the working group could formulate a consensus that 2+2=5 and the fact that there is consensus would resolve the matter.) So, Barry, please clarify what you mean by "the working group doesn't yet agree on whether he's right or not." >So let's clear > this up with a focused discussion that gets one of the following results: > * We have consensus that ADSP should explicitly say that in the absence > of an ADSP record you have no information, and you treat the message as > you did before DKIM/ADSP existed. Any other processing might be > proposed as an extension, in another document. I believe I understand this choice. > * We have consensus that there IS a well-defined process that we > recommend following in the absence of an ADSP record, and that having > the ADSP document define this is within scope for the base document. I am pretty sure I do not understand this alternative, but I'm pretty sure it does not respond to the concerns I raised. 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] New Issue: protecting a domain name vs. protecting a domain tree
Eliot Lear wrote: > Dave, >> I'll repeat that distinction: The current draft does not deal with >> exact-name >> vs. sub-tree issues as an explicit point of distinction; it has bits of each >> scattered around. As such, the specification is, at best, confusing on the >> distinction, nevermind incomplete on the tree construct. > > Can you suggest wording? Let me nip this in the bud: No. I believe the entire effort to do more than deal with an exact-match names is a mistake and that all component details that attempt to expand the scope should be removed from the specification. So the "suggested wording" I would offer is to remove text from the specification, not add it. >> 1. The cited thread shows a complete lack of anything one might call >> consensus. > > That's because the consensus was formed at the meeting, as the minutes > and Jim's presentation shows. Be sure to look at those too. I seem to recall that decisions are not made at working group meetings. They are made on the mailing list. So I'd be curious for a citation on the mailing list where the consensus from the meeting was reviewed and confirmed. d/ ps. Yes, this is all painful. It is also a good lesson about why being careful with process is particularly important for topics that are complex and poorly understood. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree
Eliot Lear wrote: > As a matter of fact the way the issue was resolved was through Jim > Fenton's presentation at the last IETF, and not so much through online > discussion. OK. So I have now also reviewed: 1. Issue 1534 and its associated thread: <https://rt.psg.com/Ticket/Display.html?id=1534> 2. Minutes from Philadelphia 3. Jim Fenton's slides from Phili 4. The mailing list archive since Philadelphia What I find is absolutely nothing that deals with any of the points I raised. And by "deals with" I mean contains substance. Certainly the thread associated with 1534 shows no consensus and not much focus. Jim's slide have nothing on the topic, other than a listing of one of the two relevant Issues, and the Phili minutes do not make mention of this issue at all. And I find nothing in the mailing list archive that discusses it. Since it is not possible to prove a negative, I'm going to again have to ask that those asserting that this matter was discussed and resolved need to document it. And I mean point to concrete materials that confirm the claim, in both referenced Issues, that the matter was resolved. As for the very reasonable requests that I clarify how the issue I am raising is different from the two cited Issues, here's my best effort: 1. There has been no requirement stated, carefully discussed, and clearly resolved, that ADSP must deal with a sub-tree or anything other than a single domain name. What seems to have happened, for some, is a de facto assumption that it is requires. However it is not in the charter and it is not in the requirements. No mailing list discussion (and I will claim no face2face meeting) has discussed this requirement carefully and to resolution. 2. There is a difference between specifying component mechanisms, versus discussing concepts and approaches that motivate those mechanisms. The current specification contains no clear statement of what it is trying to do, with respect to covering implicit or subordinate (or superior) names. 3. The DNS does not permit covering multiple names competently, for uses such as ADSP is attempting. Any effort by ADSP to compensate for this deficiency must be, at best, partial and probably also experimental. Previous working group discussions in this area -- including those cited as Issue 1402 and Issue 1534 -- have at most mentioned the higher level issues of trying to covering more than a single domain name. However they have not discussed the conceptual distinction, nor have they discussed or resolved the requirement, nor have they resolved basic technical limitations. If someone needs more explanation that distinguishes this Issue that I am raising and what has come before, they need to provide some detail. > That's because the consensus was formed at the meeting, as the minutes > and Jim's presentation shows. Be sure to look at those too. Which of his slides shows 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] New Issue: protecting a domain name vs. protecting a domain tree
[EMAIL PROTECTED] wrote: > Like others I am guessing that you are referring to section 4.2.2 step 2. Yup. >Since the domain doesn't exist the administrator can't have > been expected to create a policy for it so error seems like the right answer > to me. That presumes the goal of protecting an entire sub-tree. Absent that goal, the goal is to cover domains that have ADSP records. Very different scope of effort. > Otherwise to create policies for all of my domains I would have to create > policies not just for all existing sub-domains of that domain (which I > personally would support) but all conceivable sub-domains of a domain (which > I don't think I would). Again, creating records for every conceivable name -- and no, I can't imagine any reasonable administrator attempting that -- is only an issue if there is a belief that ADSP can 'protect' all names in a sub-tree. 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] New Issue: protecting a domain name vs. protecting a domain tree
Eliot, I am trying to be careful and specific in the things I am posting, here, and you and others need to be the same. My goal is to get discussion going. Yours appears to be to stop it. Unfortunately, that has often been at the root of problems in this working group. Let me repeat the bottom line, once again: There is nothing in the mailing list archive that demonstrates working group rough consensus on the matter of extending ADSP's scope to include more than a single, exact-match name. The record *does* contain discussion about the problems with attempting this expanded scope. So please stop repeating broad references that turn out to be invalid or off the point. The substantiation for this assessment is in the remainder of this message... Eliot Lear wrote: > 1402 and 1534 were specifically mentioned and discussed in Philly in > Jim's presentation > <http://www3.ietf.org/proceedings/08mar/slides/dkim-0.pdf>. "1402 Duplicate of 1534Applicability of SSP to subdomains" The above text contains the only reference to either of the documents in Jim's slides. To the extent that it "proves" discussion took place, it is content free. And let's get very clear about something: I did not say there was no discussion. So your "proving" that discussion took place in Philadelphia is not the issue. >In fact, > between the two they've been discussed at multiple meetings.We know > this because the mechanism has changed over time and was presented as it > changed. Since I didn't claim otherwise, I'm not sure what your point is. In any event, it would be nice to see documentation of the details in such discussion and what it's conclusions were. But most importantly we need to see documentation of consensus on the mailing list. You do not address this fundamental IETF requirement. And by "address" I mean point to specific details that provide confirmation. Generic document references don't help, particularly when it turns out that they do not prove your point. You can continue to traipse through the minutes of previous > meetings (my own recollection and the minutes confirm > <http://www.ietf.org/proceedings/07mar/minutes/dkim.txt> that is that > the group spent time on this very issue in Prague). 1. For perhaps the third time: the minutes do not contains the strings 1402 or 1534. The only reference to "tree" is: "Discussion focuses on subdomains, wildcards, tree-walking." While, yes, it's entirely reasonable to take that as proof that something was said, it does not provide any content. In particular, it doesn't even describe the claimed conclusions. > You did not > object. My own recollection of the Prague discussion was that we > specifically considered the positives and negatives of tree walking as > well as a domain existence query, but perhaps the audio i lying around > if you want to go to more detail. Concerns about sub-tree details have been expressed repeatedly and broadly over the months. Whether I, in particular, voiced them in Philadelphia, seems to be a rule you are attempting to enforce as meaningful and I can't guess why. > Putting aside that procedural issue, the fundamental basis for your > concern is that there are two independent systems that have no basis for > interdependency. I'm pretty sure that what I said does not strictly map to your characterization of it. Were you attempting to engage in constructive dialogue, rather than shut this thread down, the question of its equivalence or difference strikes me as potentially useful for improving everyone's understanding of the issue. So it's a shame that you have chosen to take such an adversarial stance. >But your premise is false, and the issue is > specifically raised in the current -03 draft, here: Qouting an entire passage always feels comforting. However I do not see which bits of text are on point or how. To the extent that your own comment is meant to clarify this: > No A record required, as Frank and I mentioned earlier. my constantly referring to A record probably is, indeed, distracting. I'm happy to substitute all of my references to A with NXDOMAIN. I believe it does not change any of the technical, administrative or operational concerns I raised. > Perhaps I have missed some text that you are referring to. Could you > correct me? I don't understand what you are asking for. Text that says what? 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] New Issue: protecting a domain name vs. protecting a domain tree
I'm going to see whether we can actually have some constructive dialogue in this thread, by posting a message responding to a point that Eliot raised in a message that had a different focus: Dave Crocker wrote: > 3. At least one of the sub-tree mechanisms is attempting to glean > information > from the absence of publisher action. Let me explain: ... > > c) Checking for the presence of an A record is intended to try tell > you > something in the absence of an explicit action by the domain owner. That's > it's > flaw: It is intuiting ADSP information from non-ADSP action. > > While there is nothing wrong with checking the A record, it's semantics > have literally nothing (directly) to do with ADSP. (and, for completeness, please modify the above: s/ A / NXDOMAIN /.) Eliot said: >> the fundamental basis for your >> concern is that there are two independent systems that have no basis for >> interdependency. The semantics of a non-ADSP DNS record certainly were not intended to be relevant to ADSP. And I doubt anyone is going to claim that non-ADSP DNS records were created for the purose of ADSP use. Whether ADSP can reasonably extract some semantics is an entirely reasonable line of question. What we need to see is discussion and consensus that it can and does and that the benefits outweighs the costs. An nice example of a counter-argument is: Wietse Venema wrote: > The problem is that "valid email origin" is a subset of all the > names that resolve in the DNS. In other words, there are false > positives in the algorithm that continues when [any DNS] record > lookup succeeds. One interpretation of this point is that the presence of a DNS entry (that is, a 'failure' to get an NXDomain) might be meaningful, but the scope of its meaning is much broader than ADSP. Once again: A mechanism possibly worth pursuing, but outside of ADSP. 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] New Issue: protecting a domain name vs. protecting a domain tree
Stephen Farrell wrote: >> One interpretation of this point is that the presence of a DNS entry >> (that is, a 'failure' to get an NXDomain) might be meaningful, but the >> scope of its meaning is much broader than ADSP. > > I'm not following that. Can you give an example? Even if its partly > speculative, it'd help me understand your point. (And in this case, > I guess speculation as to future uses of DNS might be valid, since > the current absence of entries is what we're proposing to use.) DKIM and ADSP fit into a larger framework of filtering activities. I hope there is nothing controversial about that assertion. It means that there are many analyses and tests that are outside the scope of DKIM (and ADSP). Some filtering engines query for an NXDOMAIN today, independent of DKIM or ADSP. That's a pretty clear indication that its meaning and utility are not tied to ADSP. 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] New Issue: protecting a domain name vs. protecting a domain tree
Eric Allman wrote: > Dave, I'm not understanding how the algorithm can work if you omit step > 2 from section 4.2.2. > > Suppose that example.com wants to assert to the world that it signs all > messages. It will create an ADSP record for example.com with the > appropriate assertion. Without step 2, all an attacker has to do is to > craft a message purported to be from "[EMAIL PROTECTED]" Eric, Actually from your note, it looks to me that you understand just fine. It looks as if the question is covering a single-name vs. a sub-tree. Your note mostly takes sub-tree as an implicit given, but then states it explicitly at the end. The attack that you describe requires using some name other than the one that is listed. The single, specific name that is listed is, indeed, "protected". > If that's what you mean when you say "that presumes the goal of > protecting an entire sub-tree" then I'm all for protecting the entire > sub-tree. Anything less looks to me like it severely weakens the entire > point of ADSP. (Aside: Folks keep correcting my own use of the word "protect" for DKIM or ADSP and given the delicate balancing act that ADSP must walk, I think their concern is quite reasonable. So I'm trying to switch over to say "cover"...) You echo the word "goal". That certainly seems like the right starting point. Does the working group assert the goal of covering entire sub-trees? Note that this isn't in the working group charter, the requirements statement, or even explicitly stated in the specification. That does not make the goal inappropriate, but it does mean that it needs to be stated and confirmed explicitly. (And certainly the specification needs to state this explicitly and clearly.) But frankly that's the easy part. Because we then we have the small question of what are the technical requirements and details, for covering a sub-tree adequately, within the DNS, when using an underscore sub-naming scheme? Given that the DNS is not designed to permit this conveniently and, in fact, does not seem to me to be able to do it at all, we certainly need a complete and coherent technical description of how ADSP accomplishes complete coverage of a sub-tree. This would describe the approach being taken for covering a sub-tree, and the component mechanisms being used to achieve it -- Step 2 is but one of those components. It would also demonstrate what kind of attacks it protects against. I am not aware of any previous technology providing such sub-tree functionality, and so this ought to be subject to careful review by the DNS and Security folks. At that, I fear it will nonetheless warrant a status of "experimental". So in terms of a "goal" I'm probably in agreement that it would be dandy to do. But I think that my desiring that goal is pretty much irrelevant. The problem is that I believe there is no technical means of covering a subtree completely, except by case-analysis, which isn't covering a tree at all. I believe the Step 2 query only makes sense for ADSP in the context of covering an entire sub-tree, but that ADSP does not describe the larger framework into which Step 2 fits, for accomplishing that goal. 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] protecting domains that don't exist
John Levine wrote: > Huh? The DNS doesn't provide any way to do anything to an entire zone > other than AXFR. > > The only way to cover an entire zone with ADSP is to create an ADSP > tree parallel to all of the names in the zone, i.e. for every Just to press this point about the DNS: zones are not a semantic construct that is visible to users of the DNS. In other words, they do not exist as part of the name space, per se. They are strictly an administrative construct. 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] A funny thing happened at RSA...
Powers, Jot wrote: > We're moving to support DKIM and DK. Our mail appliance vendor didn't > support dual signing until recently, and given that our published agreements > we need to be able to do both. Jot, Within the DKIM community, I suspect there wasn't a question about Paypal's intent. I think the issue is that the larger IT community makes excessive distinction between DomainKeys vs. DKIM and feels that not (yet) supporting the latter is some sort of strategic statement. I took Murray's query as having more to do with finding a way to educate these folk that the difference is incremental rather than strategic. 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] A funny thing happened at RSA...
Tony Hansen wrote: > In some of my talks, I sometimes refer to DKIM as "DomainKeys Version > 2". This gets people thinking in the right frame of mind as to their > relationship. Not only are you correct, but strictly speaking, RFC 4871 documents DomainKeys, version *4*. The current version of DomainKeys is version 2. The private industry effort that created DKIM was, therefore, version 3. So the IETF published version represents the 4th round of specification and deployment. 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] A funny thing happened at RSA..
FWIW, having dkim.org and mipassoc.org do DKIM signing is in the queue. No schedule, though. d/ SM wrote: > At 11:19 11-04-2008, Powers, Jot wrote: >> >From [EMAIL PROTECTED] Fri Apr 11 10:54:13 2008 > > And a funny thing happened on this mailing list. This email came > through without a DomainKeys or DKIM signature. > > Should the receiving MTA pass the message to this passive user or > reject it? I'm ignoring any ADSP considerations. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] A funny thing happened at RSA...
Eric Allman wrote: > By the way, how many angels /can/ dance on the head of a pin, anyway? Apparently more than people who can appreciate relative (im)maturity of a technical effort and how it should affect work on it. 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] A funny thing happened at RSA...
Jim Fenton wrote: > He said that Yahoo! had blocked 50 million messages allegedly from > paypal.com as a result of the lack of a signature. Can Yahoo! or Paypal comment on whether the protection is for specific, names or whether it is by sub-tree? How does Yahoo! know the list of domain names to treat as belonging to paypal? With respect to sub-trees is that written into the bilateral agreement or is there a way of signaling it? 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] protecting domains that don't exist
Jim Fenton wrote: > Before we get all wrapped up in a discussion about zones again, let me > point out that the ADSP specification does not rely on zones at all, > which I think you will agree is the proper treatment. not in the current spec. right. i took this sequence as some bud-nipping. > Wildcards don't do the right things, which is one reason why ADSP > doesn't depend on them, either. not sure how wildcards figure into an exchange about zones, but since we are trying not to pursue zones, we probably don't have to worry about this point, either... 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] protecting domains that don't exist
Jim Fenton wrote: > Arvel Hathcock wrote: >> > So what's the point of importing it into ADSP? >> >> The point is so we can make certain that those who aren't currently >> employing the practice will do so and to make sure that the practice >> gets itself into a standards document from this body so that we don't >> have to guess whether it's being used or not. >> > > That's an excellent point: Indeed it is. It crystalized one of the very basic problems with our trying to add this mechanism. It's called feature creep. It is also entirely outside the scope of this working group. Really. It has nothing to do with DKIM and nothing to do with Author Domain *signing*. Really. A working group's protocol specification effort is supposed to be guided by more than a current feeling that it should tell folks what is good for them. 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] protecting domains that don't exist
John Levine wrote: >> As someone pointed out, you can interchange steps 1 and 2 in the >> specification, putting the existence check first. And then, of course, you >> can decide that the existence check is done outside ADSP. If the existence >> check is removed, I would advocate putting in language that says an >> existence >> check SHOULD be performed before doing ADSP. > > That seems reasonable. My objection (and I think also Dave's) is not that > it's a bad idea, but that it's not part of DKIM or ADSP. Just to get this on the record, yes, I think it's out of scope, but in the interest, I think it would be no worse than benign to have a non-normative statement, along the lines of: "In the absence of an ADSP record, attempted use of unregistered domain names can be detected by querying the DNS for the domain name and treating a returned NXDomain as an unauthorized use." This provides the desired education without confusing things with ADSP and without getting overly lofty about the wonderfulness of the mechanism. 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] protecting domains that don't exist
Sorry for being confused, but I now can't tell whether the focus is on an NXDomain for the _adsp. string that is queried for ADSP, or the name to which it is associated. These are separate queries. d/ Wietse Venema wrote: > Frank Ellermann: >> <[EMAIL PROTECTED]> wrote: >> >>> Would it be better if "error" were a specifically defined >>> result in addition to "unknown" / "all" / "discardable"? >> The fourth bullet in chapter 3.2 "ASP results" offers "the >> domain does not exist" after "unknown"/"all"/"discardable". >> >> I-D.kucherawy-sender-auth-header chapter 2.4.2 "ASP results" >> lists this as "nxdomain". IMHO good enough, or do you have >> something else in mind ? Let's s/ASP/ADSP/g + WGLC, s.v.p. > > Sounds reasonable. I expect many will implement NXDOMAIN as a > fourth ADSP lookup result in some way or another. > > This explains more easily than my earlier claim (an NXDOMAIN result > cannot correspond with one of "unknown" / "all" / "discardable"). > > Wietse > ___ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html > -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] protecting domains that don't exist
Jim, Jim Fenton wrote: > It isn't productive to dismiss DNS administrators who are resistant to > adding many ADSP records as "lazy", "hostile", and/or "incompetent". It > makes it sound like they aren't worthy of using ADSP. But they are, as > far as this protocol is concerned, our customers. Whatever one thinks of the tone used to express the issue, the objective fact is that the two-level mechanism specified in the current draft is attempting to define a new, two-level semantic on the DNS. As such, it is a paradigm change. One should make paradigm changes to long-standing infrastructure services only when there is clear and substantial benefit and very, very broad support for it. I keep waiting for proponents of this 'feature' to solicit technical review from independent DNS and security experts, for assessing the likely benefit as balanced against the likely cost. > The requirement to publish large numbers of ADSP records is a barrier to > its widespread adoption That's a view I do not recall seeing phrased quite that way before. It's nicely succinct and pragmatic. The only question is where is its basis and, again, the broad support for the assessment that substantiates it? For example, John has provided some counter-arguments suggesting that the actual, incremental effort to deal with a large number of parallel, related domains -- for this particular RR -- is not all that high, particularly in light of the core requirement for change to tools, needed to support even only one name and record. In addition, I haven't seen an analysis that explains who all these affected domain name owners are likely to be. In other words, to be a serious barrier to adoption, it must be a serious barrier and it must affect a significant portion of potential adopters. Where is the analysis that demonstrates this? Where is the groundswell of their calling for this feature? > broad coverage for domains. This can be addressed with tools, but the > requirement to add tooling to achieve good ADSP coverage is also a > deployment barrier. As John noted, there is already a requirement for modifying tools, in order to support ADSP. > Similar concerns led the WG to the use of TXT > records rather than a new RR. Not really. The infrastructure barrier to support of a new RR exists with both those who create the record as well as those access it. The barrier for ADSP is only with those who create the record. Very, very different dynamic. > There are a lot of DNS management tools > out there that would need to change in order to publish the necessary > ADSP records, and this would take considerable time. They already need to change, to support one record (for one domain.) How is there something fundamentally worse about having to support many? 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] protecting domains that don't exist
Al, Al Iverson wrote: > My > concern is that if I can't restrict or cause failures automatically > outside of a specific subdomain or host, it does me little good to > sign on signed.spamresource.com when a phisher can fake > signed2.spamresource.com and not automatically be failed by checking > sites. I believe there is no disagreement about whether the capability would be nice. This is all about the technical feasibility, given real-world DNS constraints. So let's take your underlying assumption: What, exactly, is the scenario that uses a faked domain name and is effective? We are probably going to find different assumptions about how things are processed. What do you believe happens after they slip past this ADSP filter, that makes this fake use damaging? 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] Are subdomains like parent domains?
John Levine wrote: >>> But I have to say, without any sort of domain blanket/coverage >>> option, it seems like something is really missing here. > > I'm seeing an implicit assumption that if someone has an opinion about > mail from foo.com, they will have a similar opinion of mail from > subdomains a.foo.com or a.b.foo.com, or a.b.c.foo.com. I've been > thinking about the mail I actually see, and I am having great > difficulty finding even a small set of real life scenarios where that > is true. Good timing. I had started thinking about the fact that DKIM's d= parameter allows differentiating among (sub) domain names. The premise is that these would have different reputations. The last thing one wants for that is a mechanism that groups them all together. 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] Are subdomains like parent domains?
Al Iverson wrote: > My underlying point is that I need to understand more about how > phishers, once locked out of use of bigbank.com due to DKIM+ADSP, can > best be persuaded to avoid use of account.info.bigbank.com, or any > other subdomain that they've thought of, that I haven't. Al, I think you have phrased a very useful question. But I also think it highlights a problem in how we've been pursuing things. In all likelihood, we can assume that phishers will, in fact, try to use sub-domains. I believe the real question is not the one you put forward but rather: How will it benefit phishers to use arbitrary sub-domains? How, exactly? 1. What is the scenario on the receive side that will make this beneficial? 2. What is the basis for believing that this scenario will, in fact, occur? So the question is about receive-side, not send-side. 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] protecting domains that don't exist
Jim Fenton wrote: > Dave Crocker wrote: >> I keep waiting for proponents of this 'feature' to solicit technical >> review from independent DNS and security experts, for assessing the >> likely benefit as balanced against the likely cost. > > I have been soliciting technical review from the DNS folks, literally, > for years, on this and prior iterations. I recall quite clearly a > lengthy discussion I had with Peter Koch at IETF 65 in Dallas just over Excellent. So it will not be difficult to document that formal review so that the rest of us can consider its careful documentation of the DNS community's assessment of the peculiar mechanisms defined in the working group draft. The point behind my probe for formal review was just that: formal review. Casual, private conversations might be a precursor, but they are not sufficient, particularly when seeking to modify the DNS's exact-match paradigm for queries. > two years ago. I have been less concerned with independent security > review, since we are in that area and I expect that will happen with the > specification as a whole, not just this aspect of it. Jim, waiting until we are done, to get buy-in from the rest of the security community is singularly ill-advised project management. It maximizes risk and minimizes benefit, particularly when there is very basic concern over the efficacy of what is being proposed. I realize that you are not the one with the concern, but you might have noticed that there are others in the working group who do not share your comfort? >>> The requirement to publish large numbers of ADSP records is a barrier >>> to its widespread adoption >> That's a view I do not recall seeing phrased quite that way before. >> It's nicely succinct and pragmatic. The only question is where is its >> basis and, again, the broad support for the assessment that >> substantiates it? >> >> For example, John has provided some counter-arguments suggesting that >> the actual, incremental effort to deal with a large number of >> parallel, related domains -- for this particular RR -- is not all that >> high, particularly in light of the core requirement for change to ... > I don't see an analysis for John's assertion either. When seeking to add something to a specification, the burden of establishing that it is necessary or, at least, beneficial, falls on those who are proponents. Additions create costs. In the case of Internet standards, the costs are large-scale and long-term. The costs need to be justified. Let me anticipate a counter-argument that might be put forward: The feature in question is already in the specification so the challenge is in establishing that it must be removed. The problem with this view is that there was never a clear consensus to add it. Really. I've asked for documentation to the contrary and it has not been forthcoming. >>> broad coverage for domains. This can be addressed with tools, but >>> the requirement to add tooling to achieve good ADSP coverage is also >>> a deployment barrier. >> As John noted, there is already a requirement for modifying tools, in >> order to support ADSP. > > Not DNS tools. The requirement to modify DNS tools to achieve broad > coverage would be an additional requirement. I don't understand your response. >>> Similar concerns led the WG to the use of TXT records rather than a >>> new RR. >> Not really. The infrastructure barrier to support of a new RR exists >> with both those who create the record as well as those access it. >> >> The barrier for ADSP is only with those who create the record. Very, >> very different dynamic. > > Agree that ADSP requires changes only on the publication side. I still > believe that this introduces a significant barrier. Having to make any changes to DNS administration is a barrier. Right. And your point is what, exactly? The current point was not whether there was any barrier at all, but rather it was about your attempt to equate the height of the barrier for a new RR with that of a new use for an existing one (TXT). My response was that they are massively different barriers. >>> There are a lot of DNS management tools out there that would need >>> to change in order to publish the necessary ADSP records, and this >>> would take considerable time. >> They already need to change, to support one record (for one domain.) >> How is there something fundamentally worse about having to support many? > > The tools don't need to change; the additional TXT record for ADSP can > just be published independently using existing tools. Jim, some DNS admin tools do n
[ietf-dkim] mipassoc.org is dkim signing
Folks, Thought it worth mentioning (touting): As of late Monday afternoon, mail coming from mipassoc.org, such as the ietf-dkim mailing list, is now carrying a DKIM signature. Eliot Lear has been helping my ISP (songbird) to get this running, using the milter module. Thanks, Eliot! (And thanks Murray...) 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] protecting domains that don't exist
Eliot Lear wrote: > > and that which legitimately not be signed. huh? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] end-users vs filtering engines
Folks, Arvel Hathcock wrote: >>> Assume, say, one million people who regularly receive valid emails >>> from their bank ([EMAIL PROTECTED]). If they received an email >>> from [EMAIL PROTECTED], how many of them would believe the >>> email is really from the bank? > > I assure you, lots. Through liberal use of sub-domains via email and > web sites end users have been trained to ignore the sub-domain part ... > MTA operators will be using/deploying ADSP. End-users are the intended > beneficiary (as is the case with _all_ filtering systems). The > motivation driving MTA operators to deploy ADSP is end-user protection. There is a difference between intending end-user benefit, versus intending end-user processing. We need to be quite clear about what entity is actually going to process the information ADSP is supplying. From your note, it isn't clear where you expect the processing to be done. If the goal is end-user processing of differential information about domain names in the From: field, then I urge us to shut the effort down now. Seriously. There is no empirical basis for believing that the "protection" of these ADSP features will be a) understandable by end-users, or b) hard for attackers to bypass. Absent strong and clear empirical basis, we have to rely on general precepts about humans factors, and these, I am afraid, do not support this effort. >> If it's for end users, my experience says that they are equally likely to >> be fooled by [EMAIL PROTECTED], which would suggest we've been >> wasting our time. > > I agree with the first part of what you've said but the second part does > not follow logically. One can not claim that because we fail to protect > a user completely we therefore aren't able to provide any protection at > all and have thus wasted our time. ADSP isn't attempting to solve the > accounts-bigbank.com problem. But it does solve the foo.bigbank.com > problem. This is wonderful news and a welcome step forward. Let's consider this some more: Users will not distinguish between [EMAIL PROTECTED] and [EMAIL PROTECTED] No matter how much you protect the use of one, you cannot protect against use of the other. So, cousin domains provide an utterly trivial path for bypassing the intended end-user protection. Standards are costly to develop, deploy and use. A global standard had better provide strategic benefit. That means persistentAs explained, this won't do that. Even if one believes that it "protects" the name space it seeks to protect, the ability to bypass that protection trivially means that there is no real end-user benefit. As a consequence, what you claim as protection really is not meaningful protection. Some of us in this working group have some background in human factors, usability, user-centered design, and the other topics (and buzzwords) of the human side of computer use. Most of us do not. As a working group, we have amply demonstrated a complete lack of skill in designing for end-user processing. So we need to stop trying. Filtering engines, on the other hand, are far more tractable as targets. As a group, we know a fair amount about them. They can be taught to map a particular domain name to a particular reputation and then apply that diligently. However as has been noted, filtering engines are more typically using precise strings, rather than name "root" strings. In any event, this basic confusion about intended use of ADSP is one of the several reasons there is no real consensus about it or its features. 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] end-users vs filtering engines
Al Iverson wrote: > I have to strongly with Arvel here. I strongly reject any thought > along the lines of "we shouldn't pursue methodology X because somebody > can bypass it with similar cousin domains." > > Addressing spoofing by way of cousin domains is necessary, but is a > whole separate discussion. It, like protection related to the > validation of legitimate domains, are both two small pieces of the > authentication and trust puzzle. > > Suggesting "forget it, because they can still get away with a > lookalike domain" seems to me like saying "forget about locking the > door; we shouldn't bother, beause it's not the only way a bad guy can > enter." Your last paragraph really gets at the core issue: Is there a sufficiently useful degree of benefit to warrant the (considerable) cost of development, deployment, and use? Is the benefit long-term? In the case of locking the door to one's house, it permanently keeps out casual intruders and it establishes intent to secure the house. So someone breaking down the door is clearly guilty of breaking and entering. These are real, long-term benefits. We have none of that clarity or even benefit, in the current case. A cousin domain is sufficiently trivial to use so as to make the intended protection against use of sub-domains meaningless. If the current mechanism really did raise the bar, that would be one thing, but it doesn't. If a reputation engine has an entry, for a name, it works. Locking subdomains or cousin domains is entirely irrelevant to that. So the question is what sort of mechanism is going to benefit from locking sub-domains, but not cousin domains? How is the benefit meaningful? 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] forward movement, please? (was RE: Are lookalike domains like parent domains?)
Arvel Hathcock wrote: > I propose that the side advocating removal of the NXDOMAIN check agree > to language which makes this step AT LEAST a SHOULD and preferably a MUST. Having the ADSP specification include normative text that calls for validating the From field domain name does two things: 1. Couples an entirely separate and more generally useful mechanism (checking domain name validity) to one that is considerably more limited (ADSP). 2. Modifies SMTP. (Yes, really.) Having non-normative text that describes it serves to promote the idea but not couple it with the fate of ADSP. 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] end-users vs filtering engines
Arvel Hathcock wrote: >> Is there a sufficiently useful degree of benefit to warrant the >> (considerable) cost of development, deployment, and use? > > What is this question in reference to? The notion of NXDOMAIN lookups or > ADSP in general? Arvel, Very sorry for being so cryptic. While I view the questions as applicable for any effort, in this case I meant them with respect to any 'protect the sub-tree' effort. That was why my following comments referred to cousin names. >> Is the benefit long-term? >> A cousin domain is sufficiently trivial to use so as to make the intended >> protection against use of sub-domains meaningless. > > That is just a restatement of the view which asserts that because ADSP > can't protect domains you don't control you therefore needn't bother > protecting those you do. My point is that the effective "protection" is zero. While perhaps it closes off some particular names, it does not close off the class of attack at all. It is one thing to have a mechanisms that makes it incrementally more difficult for an attacker to succeed. It is quite another to make it no harder at all. If all the attacker has to do is register a new name and use a string-replacement on their previous attack, we do not have any meaningful added protections. >> So the question is what sort of mechanism is going to benefit from >> locking sub-domains, but not cousin domains? How is the benefit >> meaningful? > > I don't understand the question but I suspect it's a variant of what's > already been asked and answered. Is there something new here? Asked, yes. Answered, I don't think so. 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] subdomain strawpoll
Stephen Farrell wrote: > Should we keep or remove text below? > > (from 4.2.2 of draft-ietf-dkim-ssp-03, but please be sure you > check the context before expressing an opinion) > > 3. _Try Parent Domain._ The host MUST query DNS for a TXT record for > the immediate parent domain, prefixed with "_asp._domainkey." If > the result of this query is anything other than a "NOERROR" > response with a valid ASP record, the algorithm terminates with a > result indicating that no ASP record was present. If the ASP "t" > tag exists in the response and any of the flags is "s" > (indicating it does not apply to a subdomain), the algorithm also > terminates without finding an ASP record. Otherwise, use that > record. Remove. It does not enhance security. It invents new DNS semantics and works poorly. It is strictly for the administrative convenience of a minority of domain owners. It adds permanent overhead to the protocol but will rarely provide any benefit. d/ ps. As Steve Atkins noted, it also does not work properly. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] subdomain strawpoll
Stephen Farrell wrote: > Please just answer "keep" or "remove" in this thread, and use a The word "remove" triggers a catch in the mailing list software that thinks the message might be list administration (like remove from mailing list.) I suggest folks instead say "delete". d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] "interoperability"???
Jim Fenton wrote: > Dave Crocker wrote: >> Having non-normative text that describes it serves to promote the idea >> but not couple it with the fate of ADSP. > > Having the ADSP result depend on non-normative language in this case > does not meet the bar of interoperability that we need to achieve. > Making it non-normative means that two spec-compliant implementations of > ADSP would return completely different results for non-existent domains. Sorry, but I can't let this one go by without asking: I completely do not understand the claim of non-"interoperability" here. Since the record(s) in question are not created with ADSP in mind, then the domain owner cannot be said to be participating in ADSP, with respect to this check. SO how is inter-operation hurt or hindered by this specification's making the check normative vs. non-normative? 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] end-users vs filtering engines
J D Falk wrote: > Wietse wrote: >> How would a receiver discover the top-level domain given example.com, >> example.ac.uk, example.org.au, etc.? > > The same way we do now: annoying, manually maintained case statements. This relies on a resource that is not specified in the document, is not publicly standardized, and changes. Not such a good thing. 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] "interoperability"???
Jim Fenton wrote: > Hinestly, I struggled a bit with whether to use the term > interoperability there. > > The point I'm trying to make is that the normative text should be > sufficient for different implementations to return the same result under > the same test conditions. If we were to have an ADSP "bake-off", one of > the test conditions might be to report the result when given a > non-existent domain. > > I think that this is a valid test case, and that implementations should > produce the same result. So your issue is with wanting to ensure that different implementations use the result of the test in the same way. Assuming I now do understand your point, I think my original question is fully answered. Thanks. However... I still find myself not understanding how any of this makes a difference to the real-world utility of ADSP. For example, let's say that a receiver chooses either not to do the NXDomain test or chooses to process the result differently than the document specificies. Exactly what terrible outcome does this produce? 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] Are lookalike domains like parent domains?
Arvel Hathcock wrote: >> There are two kinds of "not found" responses in the DNS: NXDOMAIN and >> NODATA. > > NXDOMAIN (RCODE=3) means the name does not exist in DNS. NODATA > (RCODE=0 + ANCOUNT=0) means the name is valid but no records of the > requested type were found. We're only interested in the first one. > > So, our side in the debate is not operating from a misunderstanding of > DNS as far as I can tell. I understand the reason for the test to be verifying that the From: field address is (probably) valid. That's an email semantic questions. Looking for domain existence, rather than domain use of an email-related DNS record, seems like a significantly less appropriate test, given the goal of the test. Why is it sufficient for the domain to have no RR relevant to email, just as long as it has some RR? 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] domain existence check
Steve Atkins wrote: > The reason for the existence check is simply to make it possible > for an ADSP user to specify consistent policy across all their > space in the DNS tree. A simple check for NXDOMAIN is > sufficient to fill that need. Any semantics beyond that are moving > beyond the reason that the check is needed. Each form of pre-test provides a narrow degree of enhanced protection across a domain tree. Note that no pre-test at all is necessary for 'protecting' a single domain name, since the presence or absence of the ADSP record does that entirely sufficiently. (Again, to the extent that one is seeking protection with sites that do not use ADSP, one is completely beyond the scope of this working group.) Narrow does not mean useless, but it does mean narrow, as in incomplete. This vigorous insistence on demanding a use of a particular mechanisms that nonetheless provides incomplete enforcement is quite odd, since its utility amongst the broader spectrum of abuse exploits is so small. 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] draft-levine-dkim-adsp-00
John Levine wrote: > The major changes since -02 are: The draft and an rfcdiff between ssp-03 and levine-dkim-adsp-00 are posted at: <http://dkim.org/ietf-dkim.htm#working> 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] draft-levine-dkim-adsp-00
apologies. it pointed to the wrong document. it's now fixed. d/ Arvel Hathcock wrote: > > That snip isn't in the draft I posted. Any chance you're looking at > > the wrong version? > > I'm looking at the thing Dave posted a link to: > > > The draft and an rfcdiff between ssp-03 and levine-dkim-adsp-00 are > > posted at: > > > > <http://dkim.org/ietf-dkim.htm#working> > > That link takes you to a page where there are other links to your -00 > draft and rfcdiff. Maybe that page isn't updated yet? > > Arvel > > > ___ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html > -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-levine-dkim-adsp-00
Al Iverson wrote: > Arvel suggested a straw poll regarding whether or not the NXDOMAIN > check should be removed or not. The phrasing of the query for a poll is a challenge, here. A specific query, only for "whether or not the NXDOMAIN check should be removed or not" is particularly limited. And the difference between ssp-03 and draft-levine-dkim-adsp is not as simple as 'removing" NXDOMAIN. What do you feel are the technical deficiencies of draft-levine-dkim-adsp? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] The challenge of an 'nxdomain' straw poll
Arvel Hathcock wrote: >> The phrasing of the query for a poll is a challenge, here. > > Nope. The question is on the removal of the NXDOMAIN step from the > working group draft. That's one question, yes, but there are more. While I'm not sure it captures the available choices, here's an attempt: There really are two sets of choices: Degree of requirement - 1. Make a domain 'validity' test mandatory. 2. Make a 'validity' test optional (SHOULD vs. MAY) 3. Remove a 'validity' test Type of 'validity' test --- 1. NXDomain 2. RFC2821bis I suspect there are more choices for type of test, but these are the two that are obvious. Unfortunately each of the listed choices has some problems. In addition there is the problem that the industry already conducts these tests, but in a variety of ways. Basically, the industry does not have a solid, de facto NXDomain standard. It has a small number of common choices, but 'common choices' is different from 'definitive, single choice'. If this working group insists on defining a single, definitive test, then it is running some risks with industry adoption, since we are attempting to constrain existing practice. The RFC2821bis test potentially has multiple queries, meaning higher overhead. But it is semantically deeper, with respect to validity for email-related use. It also seems likely that the more definitively the working group attempts to specify (standardize) this particular test, the more it will be subject to review by the larger Internet email technical community, for architectural impact. But, of course, that's just my own opinion. 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] draft-levine-dkim-adsp-00
Dave Crocker wrote: > apologies. it pointed to the wrong document. it's now fixed. Folks, I've added both inline and side-by-side versions of the rfcdiff output to the web page. 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] requirement for one ADSP record per DNS entry makes ADSP undeployable
Eliot Lear wrote: > The problem is when there are hundreds or thousands of hosts beneath > example.com. How many commercial DNS management systems can handle that > from a provisioning point of view? All. How else did they register those names and populate them with records? 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] requirement for one ADSP record per DNS entry is irrelevant
Eliot Lear wrote: > John Levine wrote: >> In any event, the tree walk is gone. We voted, your side lost. >> Enough already. > > We voted on a misconception you perpetuated. We never had a tree walk. > The "vote" leaves the protocol undeployable. Eliot, This is both ad hominem and disruptive. You are seeking review of an issue that has already been voted on, and you are doing it in the middle of the group's attempt to focus on a different and difficult topic. In order to permit forward progress, rather than endlessly revisiting resolved topics the typical working group normal rule about re-raising a topic that has already been closed formally is that something has changed. New insight, changed conditions, or the like. What has changed, Eliot? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] The purpose of an existence/validity check
name-based reputation exactly matches the data we have seen posted to the mailing list about actual reputation usage: Reputation data for IP Addresses covers ranges, yes. But the statements about domain name use say they are tied to a specific, complete name, not a string that is the root of a sub-tree. In terms of the affirmative, proactive model of DKIM and ADSP, seeking to protect unregistered names creates is, therefore, wasted overhead. An existence query might be worthwhile in terms of other concerns and models, but it has nothing to do with the scope of this working group. Worse, it sets entirely inaccurate expectations for DKIM and ADSP. OK... start shooting. d/ ps. The above does not deal with an important additional test: If there is to be a test, given that there is a range of established industry practice, how is this working group to define a particular standard that will appeal to the industry? -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] [Fwd: Re: What is the standard DNS "call back"?]
Folks, I did a query to a community of anti-abuse email receivers, asking about actual back-checks that they do. I am forwarding the responses I get, after getting the author's permission, to add to the source data the working group has. Here's the first, albeit for rfc2821.mailfrom, rather than rfc2822.from: Original Message Subject: Re: What is the standard DNS "call back"? Date: Wed, 28 May 2008 16:57:02 -0400 From: Victor Duchovni <[EMAIL PROTECTED]> On Wed, May 28, 2008 at 01:39:37PM -0700, Dave Crocker wrote: > Victor Duchovni wrote: > >We reject mail with an invalid envelope sender domain. All further > >decisions > >are based on the reputation of client IP. > > What objective tests are performed to determine whether the envelope sender > domain is valid? The domain must have at least one MX host with with at least one "A" (some day "") record, or if no MX hosts are present, the domain itself must have a valid "A" (or "") record. This boils down to there being at least one network address to which one would attempt a TCP port 25 connection were one inclined to send a message to the domain in question. This is an *existence* test, not an *authenticity of origin* test. We do not perform SPF checks, do not publish SPF records, and do not expect to perform DKIM SSP tests. Our use of DKIM will be entirely for whitelisting. We may at some point allow some external DKIM signers to bypass some of our content filters. This will have nothing to do with rfc822.From. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Consensus check: Domain Existence Check
Jeff Macdonald wrote: > I too like the wording in draft-levine-dkim-adsp-00, but I'm not sure if > that means a modify or remove. draft-levine-dkim-adsp-00 doesn't list > steps like the current -03 draft does. How is that its section 4.3 does not qualify as listing steps? 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] portable reputation
John Levine wrote: >> One thing we hear a lot about in other contexts is reputation >> portability. If paypal were to create a new service, it would want >> to borrow from its reputation. ... > Reputation portability is indeed important, but I don't see why one > would want to implement it by default fuzzy domain matching, with all > the phish vulnerabilities that opens up, particularly when DKIM > already provides straightforward workable ways to do it. Eliot, Typical discussions about reputation portability have been based on use of IP Addresses. The need for portability is due to being forced to use different IP Addresses. Using domain names as identifiers changes the entire game. For one thing, it permits the reputation to be based on a far more stable identifier. To whatever extent we want reputations to be able to be "portable" we need to make sure it does not conflict with desires to keep them separate. 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] Consensus check: Domain Existence Check
>b. Modify Replace with the text from draft-levine-adsp-00 /d ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] ISSUE: Modify ADSP Lookup Procedure
Modify ADSP Domain Existence procedure. Use draft-levine-dkim-adsp-00, Section 4.3. ADSP Lookup Procedure as input to discussions. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] ISSUE: fix ADSP's xml2rfc 'code'
SSP-03 has a number of xml2rfc errors. These should be fixed, per draft-levine-dkim-adsp-00. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] ISSUE: Streamline Abstract
An Abstract is circulated as the primary document summary. As such, it should contain text that concisely explains the scope of the problem covered by the document and the nature of the solution defined in the document. The draft Abstract should be revised, per draft-levine-dkim-adsp-00: > OLD: > > DomainKeys Identified Mail (DKIM) defines a domain-level > authentication framework for email using public-key cryptography and > key server technology to permit verification of the source and > contents of messages by either Mail Transport Agents (MTAs) or Mail > User Agents (MUAs). The primary DKIM protocol is described in > [RFC4871]. This document describes the records that authors' domains > can use to advertise their practices for signing their outgoing mail, > and how other hosts can access those records. > > NEW: > > DomainKeys Identified Mail (DKIM) defines a domain-level > authentication framework for email to permit verification of the > source and contents of messages. This document specifies an adjunct > mechanism to aid in assessing messages that do not contain a DKIM > signature for the domain used in the author's address. It defines a > record that can advertise whether they sign their outgoing mail, and > how other hosts can access those records. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] ISSUE: Revise wildcard discussion
The ADSP discussion of wildcard needs to be clarified, per draft-levine-dkim-adsp-00: > Section 6.3., paragraph 1: > OLD: > > Wildcards within a domain publishing ASP records, including but not > limited to wildcard MX records, pose a particular problem. While > referencing the immediate parent domain allows the discovery of an > ASP record corresponding to an unintended immediate-child subdomain, > wildcard records apply at multiple levels. For example, if there is > a wildcard MX record for "example.com", the domain > "foo.bar.example.com" can receive mail through the named mail > exchanger. Conversely, the existence of the record makes it > impossible to tell whether "foo.bar.example.com" is a legitimate name > since a query for that name will not return an "NXDOMAIN" error. For > that reason, ASP coverage for subdomains of domains containing a > wildcard record is incomplete. > > NON-NORMATIVE NOTE: Complete ASP coverage of domains containing (or > where any parent contains) wildcards generally cannot be provided by > standard DNS servers. > > NEW: > > If a domain has valid wildcard MX, A, or records, then any > subdomain that does not otherwise exist according to [RFC4592] is a > valid mail domain. It is possible to add a wildcard TXT record > alongside a wildcard MX that will provide suitable ADSP records for > any domain chosen by an attacker, since if the wildcard synthesizes > chosen-name.example.com IN MX, it will then also synthesize > _adsp._domainkey.chosen-name.example.com IN TXT. However multiple > wildcard TXT records produce an undefined ADSP result, which means > you cannot also publish both ADSP records and records for any other > TXT-using protocol (such as SPF) for a wildcard domain. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] ISSUE: Modify tagging text
Remove the 't' tag. Remove the Flags Registry section. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] ISSUE: various minor documentation enhancements
ssp-03 should make the following minor enhancements, per draft-levine-dkim-adsp-00: Add keywords, to improve Internet search results > OLD: > email, e-mail, rfc2822, rfc 2822, rfc822, rfc 822, rfc2821, rfc >2821, rfc821, rfc 821, rfc4871, rfc 4871, DKIM, domain keys, ASP, >architecture, mta, user, delivery, smtp, submission, Internet, > mailfrom, >author, return address > > NEW: > > email, e-mail, rfc2822, rfc 2822, rfc822, rfc 822, rfc2821, rfc >2821, rfc821, rfc 821, rfc4871, rfc 4871, DKIM, domain keys, > domainkeys, >ADSP, ADSP, SSP, architecture, mta, user, delivery, smtp, submission, >email, e-mail, smtp, Internet, mailfrom, mail from, author, return >address, sender signing, signing practices Convert ASP references to ADSP Replace relevant references to "Author" to be "Author Domain", and similar changes. Revise text of last bullet in Results list: > Section 3., paragraph 13: > OLD: > > o The domain does not exist. > > NEW: > > o The domain is not a valid mail domain. > Move Lookup Procedure up one document level. Remove all specification details pertaining to sub-domains. Remove definitions not used in the document -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: Streamline Abstract
SM wrote: > I suggest adding "valid". > > The assessment applies for messages that do not contain a valid DKIM > signature for the domain used in the author's address. It defines a record > that can advertise whether outgoing mail for the domain is signed and how > other hosts can access those records. yes. good catch. thanks. 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] ISSUE 1574: fix ADSP's xml2rfc 'code'
Dave Crocker wrote:
> SSP-03 has a number of xml2rfc errors.
>
> These should be fixed, per draft-levine-dkim-adsp-00.
Entirely predictably, I now cannot find the serious "errors" in the ssp-03
draft, although they were hounding me when trying to produce txt and/or pdf
versions in order to make some comparison. No idea what the problem was with
the version of the document that I was using.
However since I have to post this followup anyhow, I'll suggest that changes
to the xml worth making are:
As appropriate:
->
==
->
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] ISSUE 1578: various minor documentation enhancements
Dave Crocker wrote: > Remove definitions not used in the document It appears that the only one needing to be removed is "selector". 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] ISSUE 1573: Modify ADSP Lookup Procedure
Dave Crocker wrote: > Modify ADSP Domain Existence procedure. > > Use draft-levine-dkim-adsp-00, Section 4.3. ADSP Lookup Procedure as input to > discussions. Per the Levine draft, this also entails addition of: ADSP as defined in this document is bound to DNS. For this reason, ADSP is applicable only to Author Domains with appropriate DNS records (see Note below). The handling of other Author Domains is outside the scope of this document. However, attackers may use such domain names in a deliberate attempt to sidestep an organization's ADSP policy statements. It is up to the ADSP verifier implementation to return an appropriate error result for Author Domains outside the scope of ADSP. The results from DNS queries that are intended to validate a domain name unavoidably approximate the set of Author Domains that can appear in legitimate email. For example, a DNS A record could belong to a device that does not even have an email implementation. It is up to the verifier to decide what degree of approximation is acceptable. to the Section 3. Operation Overview. 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] Discussion of Consensus check: Domain Existence Check
John Levine wrote: >>>> * levine-adsp-00 provides a superset of methods for *how* to >>>> determine if the domain exists: the NXDOMAIN test and the "check MX & >>>> A/" method from SMTP. It leaves it up to the implementation to >>>> choose the algorithm that works best for it. > > What I should have said was that recipients MUST do the NXDOMAIN check > and SHOULD do the more comprehensive 2821 check. It's SHOULD since it > is my impression that many MTAs do it anyway, so there's no incremental > cost. In the interest of accuracy: I have been probing some email receive-side folk, about their call-back or verification steps like this that they conduct. Generally, the range of tests is of these types. Unfortunately, it is rarely based on the rfc2822.From field. It is, instead, typically based on rfc2821.mailfrom. So we need to be careful about assuming that any of these tests are likely to be "free". In fact, one bit of feedback I got was explicit about these additional tests as costing too much. They had tried and found they added too much delay. FWIW. 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] I-D.kucherawy-dkim-reporting
Murray S. Kucherawy wrote: > ADSP isn't a published draft yet. When it publishes, I'll update. It's Monday. Monday is perfect for nit-picking, since it's potential for ruining an entire week is the best: One should not say "published" for a draft, but if one were to say it, in fact an ADSP draft is indeed published. But it has not been declared a working group document. However the working group consensus has already been declared for the term "ADSP" so citing it in another document could go either way. That's almost three nits, and I only started out intending one. No need to thank me. 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] I-D.kucherawy-dkim-reporting
(just to make sure the importance level of this thread is entirely clear: I said "nits".) Murray S. Kucherawy wrote: > Dave Crocker wrote: > >> One should not say "published" for a draft, but if one were to say it, >> in fact an ADSP draft is indeed published. >> >> But it has not been declared a working group document. > > I'm missing the distinction between "published" and "posted" (the latter > being the one you'd probably prefer) in this context, but sure. Think of it like the difference between death and murder. To the corpse, not much, to those who remain, it sure feels different. Yes, a document is issued. The world gets to see it. But it's status in the world really does have meaningful differences, depending on the label that is assigned. In the world of formal utterances, the word "publish" is a term of art. There is some history of being quite sensitive about that term, in the IETF, and particularly with respect of Internet Drafts, given there explicitly transitory nature. By the way. Did I mention that this was a nit? > Then allow me to rephrase: > > When the working group publishes something that replaces "ASP" with > "ADSP", I'll update my drafts accordingly. You really haven't been watching how this working group operates, since we have no training for anyone formulating criteria that make sense. >> That's almost three nits, and I only started out intending one. >> >> No need to thank me. > > You guys are awesome. I separately post my wire account information. 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] Not an issue: multiple From headers
John Levine wrote: > My theory is that DKIM only applies to valid 2822 messages, and it's not a > substitute for a sanity check for all the screwy things one can send in a > non-conformant message. +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] Not an issue: multiple From headers
Murray S. Kucherawy wrote: > +1, and I would go even further to say that we should have an errata item > against RFC4871 which says we should add that DKIM presumes a properly-formed > RFC2822-style message, and that its application to other messages produces > undefined results. Let's think about this for a moment. While it's unlikely that such an erratum would do any damage, I'm bothered by the implication that the DKIM spec is somehow deficient in this regard. Certainly the spec does not have an explicit and simple statement that it operates on RFC 2822-compliant messages. Certainly a number of wrinkles in the spec would have been smoothed out by its containing a more explicit input/output section. But the idea that anyone would think that a signing mechanism designed to operate on RFC 2822 messages would somehow be expected to operate successfully on non-conformant messages really bothers me. In particular, the idea that any changes to the spec, about this, would count as an erratum seem, ummm, erroneous. Besides that, I think that one could argue that, at the least: > 5.3 Normalize the Message to Prevent Transport Conversions ... > If the message is submitted to the signer with any local encoding that will > be modified before transmission, that modification to canonical [RFC2822] > form MUST be done before signing. In Carries the rather strong implication that DKIM only works on compliant messages. 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] Issue 1553: note on figure in overview draft
Stephen Farrell wrote: > Issue description: https://rt.psg.com/Ticket/Display.html?id=1553 > > I'm not sure that we converged totally on this, but the thread [1] > does have proposed changes, so I guess we have to wait until > the next rev of the overview, at which point we can hopefully Looking at what I think is the next version (under revision) it does seem to have the new diagram that was proposed at the end of that thread. So, no, the item probably should not be closed until the revision is issued, reviewed and the diagram approved. But that's probably going to be a formality. 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] Issue 1561: Development & Deployment guide improperly uses normative language
Just to make sure I understand: The decision is to remove all hints of being normative? (Per the recent exchange on the IETF mailing list, this won't hinge on case.) d/ Stephen Farrell wrote: > Issue description: https://rt.psg.com/Ticket/Display.html?id=1561 > > Thread: http://mipassoc.org/pipermail/ietf-dkim/2008q1/009790.html > > From the thread people seem to support the thrust of the comment, i.e. > to reduce/eliminate 2119 language where possible and definitely > avoid it (regardless of case) where its not needed. > > Suggest we leave this open for now to let the editors concentrate > on the overview and process the deployment draft issue subsequently. > > S. > > ___ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html > -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Issue 1561: Development & Deployment guide improperly uses normative language
Stephen Farrell wrote: > Not sure it was so strong. I'd interpret the list consensus as > being to remove all normative statements where possible with > some people (but maybe not a consensus) saying that that should > get rid of them all. > > If there's something that the editors feel should be normative > in the deployment guide then I guess we'll need to deal with > that based on the next rev, but that should be easier if we > get rid of unnecessary 2119 language. I'm going to be picky about this guidance, only because I know it will bite us in the ass later, if there is any issue, so I'd rather get this settled before we do serious revising: The -Overview is scheduled to be Informational. It can't have normative text and be a working group document at Informational, IMO. In any event, having it contain stray normative text -- absent a very clear mandate for very specific areas to specify -- invites confusion rather than clarity. And... my current reading of the draft under revision is that it has no normative text. My personal expectation is that it will stay that way... 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] Issue 1561: Development & Deployment guide improperly uses normative language
Stephen Farrell wrote: > I agree. But this issue relates to the deployment guide, not the > overview. If we also have a similar consensus about the deployment > guide, then I think that makes sense but I don't remember us > closing out on that yet (we did specifically for the overview). ahh. missed the different venue. and I think there has been almost no discussion about the deployment doc? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] New version -- draft-ietf-dkim-overview-10
Folks, New version of the Service Overview has been posted to Internet Drafts. Various formats and diffs are at: <http://dkim.org/ietf-dkim.htm#overview> This draft is intended to close all open 'issues' concerning the Overview. (All issues that have the word 'overview' in the subject.) Every issue was reviewed and considered carefully. If you see a change that was not made or not made to your satisfaction, and you wish to pursue the matter further, please do raise it with the working group. /d -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] ADSP pretty & diffs
FOlks, I just discovered that while the html and pdf versions of ssp-04 had been posted to the DKIM site, the ietf-dkim page did not cite them and the diffs from -03 hadn't been generated and posted. These are now available at: <http://dkim.org/ietf-dkim.htm#adsp> 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 and mailing list
Byung-Hee HWANG wrote: > hi, my name is byunghee from South Korea. long time ago, i've heard > about dkim over the internet. that gives me a confidence; somebody trust > that my email is not a spam. however, my some client do not like this > dkim because dkim bring some problems on mailing list. well, do you > discuss with above the problems? and now, is there any way to solve? > actually, yes, i love dkim's basic philosophy ;; Byung-Hee, Welcome to the DKIM world. This mailing list has a focus on writing new technical details related to DKIM. There are some other mailing lists for discussions about using existing specifications. Please take a look at: <http://dkim.org/#deployment> I think, perhaps, the best list for your concerns is: <http://mipassoc.org/mailman/listinfo/dkim-ops> 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] Progressing ADSP (Was: Re: New Version Notification for draft-ietf-dkim-ssp-06 (fwd))
Stephen Farrell wrote: > It might be no harm if folks who do think ADSP should > go ahead would respond to this saying so. +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] Progressing ADSP (Was: Re: New Version Notification for draft-ietf-dkim-ssp-06 (fwd))
SM wrote: > "In all cases, new values are assigned only for values that have been >documented in a published RFC" > > RFCs are generally published. That word could be dropped from the sentence. You are technically correct. However, the term "draft RFC" is relatively common. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Adding a 'consultants' page to dkim.org
Folks, G'day. I am periodically getting a request for detailed assistance with DKIM software development or deployment and operations details. These are not things I personally do, so I'm adding a web page to point at. It needs entries... As with the other dkim pages, listings are not endorsements. Entries are added as provided and as is. It is intended merely as a place to guide specialized research. Please send me entries to add of yourself or anyone else you think should be listed. (A suggestion to list someone else is not cited, so you don't need to worry about being credited/blamed for the suggestion. Again, this isn't about "recommendations".) The proposed format of an entry is: Consultant or Company name: Type of services: Email: Phone: Geographic coverage: Should I have other information on the form? Thanks? 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] [Interop] Adding a 'consultants' page to dkim.org
Daniel Taharlev wrote: > Would you folks use a DKIM wiki? I some times find it to be a better method > than forums. Let me know and I can set one up. I think of a wiki as being best for joint development of a document rather than for discussion. The idea, here, was for discussion which might or might not result in a snippet of text that has community consensus. Do others see this differently? 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] [Interop] Adding a 'consultants' page to dkim.org
Olivier MJ Crepin-Leblond wrote: > Hello Dave, > > What you might wish to do is to create a DKIM user group email list & ask > people to post their questions on there. > Let the community answer operational/implementation questions - there are > always good samaritains around. My reaction is similar, but a bit different. The benefit of "water cooler" consulting is enormous and typically skims quite a lot of common and simple problems off the top. This leaves the work of hired consultants to problems of more substance. Hence, the consulting styles overlaps nicely. I'll add a dkim-users mailing list to the dkim.org mix shortly. At this point, the real question is how to help someone coming to the web page to figure out what mailing lists to use and how... 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] [Interop] Adding a 'consultants' page to dkim.org
Murray S. Kucherawy wrote: > On Mon, 29 Sep 2008, Dotzero wrote: >> It would be nice to be able to refer them to a consultants list through >> dkim.org. > > I'm leaning toward objecting to that idea. I'm concerned that listing > consultants on dkim.org could be construed as some kind of endorsement of > those listed. I think the concern is entirely valid. But rather than take the concern as a reason to prohibit any listing, I think the challenge is to protect against that unfortunate complication. In other words, I think the potential benefit warrants finding a balance. The other line of rationale is that the page has already crossed the line, with: Software and Services Deployment <http://dkim.org/deploy> So really -- to use one of my favorite cliche's -- we are just haggling about price... 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] Adding a 'consultants' page to dkim.org
Jim Fenton wrote: > If you mean a wiki that isn't openly editable, then it's just a convenient > tool for creating the consultants' webpages. Dave might choose to use wiki > software to maintain this, or not. Oh. Interesting idea. Hadn't thought of it. In terms of the 'work' of building the list, it sounds reasonable. However I think it inherently requires having editability be open, which has the downside you observe. So I could easily imagine folks signing up for a discussion list and having a wiki open to subscribers. Maybe for the DKIM FAQ? But probably not for a simple listing of consultants? (hmmm. Unless there is an associated discussion list they would sign up for, beforehand?) 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] [Interop] Adding a 'consultants' page to dkim.org
Murray S. Kucherawy wrote: > The link off the main page is entitled "Organizations Providing > Software, Hardware or Services". The word "Services" (at least to me) > includes consulting. So do we want to include consulting services in > this list, or make a separate list and (hopefully) adjust the title of > the first? Mumble. Fair question but probably instead calls for changing the existing 'services' term. The intent for that existing page is about "products". "Services" means online services, as in service providers. I think something like "region" is a good indication that the "consulting' entries have a basic difference. (And in case I didn't mumble loud enough: Foo!) Murray S. Kucherawy wrote: > [Is this really appropriate for ietf-dkim?] I couldn't decide on exactly the right venue, which is why I chose 2. The Interop list is great, but I thought it too limited a distribution for discussing this larger question. > On Mon, 29 Sep 2008, Dotzero wrote: > It of course also brings up the question of reputation. If we end up > listing a bunch of consultants whose work leaves something to be desired, > dkim.org won't be considered a good source of such information... I view this as more a matter of percentages. No list is perfect. Is this list still a good idea if 10% of the listings are for consultants who perform poorly? I would think so? What about 50%? 75? 90? I don't know where the cut-off is. Basically, my thought is to create the list, let it get populated, let it get used, and see how useful folks feel it is. At some point, I fully expect a sense of rough consensus, one way or the other. > Talk about eating our own dog food! Well, it's true that this might be a dog of an idea... 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] [Interop] Adding a 'consultants' page to dkim.org
Folks, Olivier MJ Crepin-Leblond wrote: > What you might wish to do is to create a DKIM user group email list & ask > people to post their questions on there. I'd like to clarify the role of a new 'users' list from the DKIM lists that already exist. The existing ones are: Standardization Development Testing Operations So who is the "use" one for and what will they discuss? For example, how should it differ from discussion on the Operations one? In general, we ought to clarify the roles of each of these lists. Comments? d/ ps. I've added a listing of the lists under the <http://dkim.org#introduction> section -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] [Interop] Adding a 'consultants' page to dkim.org
Murray S. Kucherawy wrote: > On Tue, 30 Sep 2008, Dave CROCKER wrote: >> I'd like to clarify the role of a new 'users' list from the DKIM lists >> that already exist. The existing ones are: >> >>Standardization > > I'm guessing that's ietf-dkim. yes. (sorry I didn't provide the pointers.) > >>Development >> >>Testing > > I assume this is dkim-dev and dkim-testers. yes. > I think these two overlap > enough that they should be merged. It's for people who are developing, or > have developed, DKIM applications so that they can benefit from the > experience of others and arrange for interoperability testing. These are independently managed lists. Merging is possible, of course, but we should get some pretty strong consensus to do that, I think. >>Operations > > Not sure which this one is (dkim-ops?). yes. > I'd say this is the general list > for questions about deployment and operations. This is where I believe > questions about reputation and multiple signatures should be discussed, > except where those coversations relate directly to standardization or > development/testing. Ewww. "reputation"? No, I hope not. For the moment, we are only talking about the mechanics of creating and interpreting DKIM signatures. I would *very* strongly hope that discussion about the use of domain names for making quality assessments (reputation) would be on an entirely different list. (And, yes, we might need to create one.) Anyhow, is the ops list where the water-cooler self-help consulting should take place? > Are there other potential discussions that wouldn't be covered by these > which warrant having their own venues? That's my question, yes. 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] [Interop] Adding a 'consultants' page to dkim.org
Folks, A consultants' page is now available at: <http://dkim.org/deploy/consult.htm> with a pointer from the dkim.org home page. Please circulate this notice and especially suggest anyone offering services send me a completed template form. 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] [Interop] Adding a 'consultants' page to dkim.org
SM wrote: > There is a line between operations and user help. Questions about > specific software/hardware should be taken on the mailing lists set > up for that purpose. This list could be used for high level > questions about deployment and operations. If there is too much > "noise" because of user level questions, people may stop paying > attention to the list and it won't fulfill its purpose anymore. While what you say makes sense, in terms of general distinctions, I do not understand how it applies for DKIM. "Users" for DKIM are operations folk, not consumer-styled end users. So: Who, exactly, are the people who would be on the "operations" list and what would they talk about, versus who would be the people on the users list and what would they talk about? How are the people on these two lists different? It increasingly seems to be that we need one (or two) lists for developers and one for operations (classic OA&M). I don't have any preference about this; it's merely all that I am seeing. The choice for developers seems to be between programmers trying to decipher specifications, versus testers running interoperability or conformance scenarios. Comments? Thanks! 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] [Interop] Adding a 'consultants' page to dkim.org
Murray S. Kucherawy wrote: > On Tue, 30 Sep 2008, Dave CROCKER wrote: >>> I'd say this is the general list for questions about deployment and >>> operations. This is where I believe questions about reputation and >>> multiple signatures should be discussed, except where those coversations >>> relate directly to standardization or development/testing. >> >> Ewww. "reputation"? No, I hope not. For the moment, we are only >> talking about the mechanics of creating and interpreting DKIM >> signatures. > > I'm referring mainly to general public questions about "How do I tie this > to reputation?" Not our industry debates; those go on MAAWG or IETF lists > as they have been. Ahhh. An open, public forum for discussion about domain name-based reputation? Such a topic has to begin with an authenticated name and then has to figure out what to do with it that is useful. (What should the name of the list be? Nothing mnemonic and apropirate occurs to me.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] [Fwd: I-D Action:draft-hoffman-dac-vbr-04.txt]
The draft doesn't specify a discussion venue. I believe the plan is to request Informational RFC status. With respect to the IETF, is there a better place for discussion than the DKIM list? d/ Original Message Subject: I-D Action:draft-hoffman-dac-vbr-04.txt Date: Thu, 9 Oct 2008 08:45:01 -0700 (PDT) From: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Vouch By Reference Author(s) : P. Hoffman, et al. Filename: draft-hoffman-dac-vbr-04.txt Pages : 12 Date: 2008-10-09 This document describes the Vouch By Reference (VBR) protocol. VBR is a protocol for adding third-party certification to email. It permits independent third parties to certify the owner of a domain name that is associated with received mail. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hoffman-dac-vbr-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] [Fwd: I-D Action:draft-hoffman-dac-vbr-04.txt]
Tony Hansen wrote: > Would there be enough interest in the topic to have a BOF next month? That tends to imply a desire for a working group. I thought the goal for this was to pursue it as an independent submission. I was only seeking an email venue to allow (presumably) basic discussion and clarification. 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] Possible exploit of DKIM
SM wrote: > If DKIM was tied to the outbound's MTA IP address, it would face the > same problems as SPF when it comes to forwarding. For those who have been around DKIM for awhile, this thread will no doubt look quite familiar. If someone will writeup a thorough response to this oft-expressed concern, I'll post it in the DKIM FAQ. (I suggest running it past the list, to get some agreement on the details.) 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] Who runs testing.dkim.org ?
Jim Fenton. d/ John L wrote: > It's a mail server that checks DKIM signatures, but it has an annoying bug > that someone could probably fix in two minutes if I knew who the right > someone was to ask. Any hints? > > Regards, > John Levine, [EMAIL PROTECTED], Primary Perpetrator of "The Internet for > Dummies", > Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor > "More Wiener schnitzel, please", said Tom, revealingly. > ___ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html > -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] [Fwd: Last Call: draft-kucherawy-sender-auth-header (Message Header Field for Indicating Message Authentication Status) to Proposed Standard]
Folks, It would be helpful to have responses to this formal IETF Last Call, posted to to the IESG and stating your basis for having an opinion about this draft, what your opinion is, with respect to its history, its utility, and its appropriateness for standardization. The IESG prefers to have a reading of active community support for a draft, and especially one that is an independent submission, before declaring it a standard. d/ Original Message Subject: Last Call: draft-kucherawy-sender-auth-header (Message Header Field for Indicating Message Authentication Status) to Proposed Standard Date: Tue, 4 Nov 2008 11:02:00 -0800 (PST) From: The IESG <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: IETF-Announce <[EMAIL PROTECTED]> The IESG has received a request from an individual submitter to consider the following document: - 'Message Header Field for Indicating Message Authentication Status ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [EMAIL PROTECTED] mailing lists by 2008-12-02. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-17.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12283&rfc_flag=0 ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/ietf-announce -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Next steps for draft-ietf-dkim-ssp
MH Michael Hammer (5304) wrote: > Wouldn't the better (correct) way to state this be: > > It's when the signing domain (d=) and signature matches the From: > address domain. That change in language should help, yes. The distinction between 'email address' and 'email domain name' is often lost. Language to emphasize the distinction is probably a good idea for the document. The fact that i= is defined to identify a user, rather than a mailbox, and that the difference is not clear to folks, but that it can be quite large, is also proving to be a consistent point of confusion. For example it can (and sometimes does) contain non-mailbox information. This is what John was observing a few notes back. I'm not sure there is an opportunity to clarify it, in this doc, but it might be worth considering. I'm sufficiently not sure that I don't even have language to suggest. Sorry. Perhaps some text that notes that i= MAY match the From: address but that it is not required to, even when i= is in the syntax of an email address? 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] [Fwd: I-D Action:draft-hoffman-dac-vbr-04.txt]
Jim Fenton wrote: > Well, it is explicitly out of scope for the working group, and if Jim, the wg is winding down. I believe the only pending work is the Deployment document. It is common to have wg mailing lists persist beyond the life and scope of the wg charter, to discuss work done by the wg, of course, but also for discussing related activities. > ASRG lists, perhaps? That's a research group. This is about a specification intending standardization. We've just seen that an RG list isn't a very good venue for standards discussions. Were the DKIM wg in the midst of active development, no I would not suggest it as a venue for reviewing VBR. Given the relatively quiescent state of the list, I don't think we need to worry that much about scope or focus confusion. 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] [Fwd: I-D Action:draft-hoffman-dac-vbr-04.txt]
wow. sorry. i missed that i was reply to an october note. roseanna dana is now saying 'nevermind'... d/ Jim Fenton wrote: > Well, it is explicitly out of scope for the working group, and if > discussion on VBR is conducted here it might tend to confuse people into > thinking that we don't understand that. > > ASRG lists, perhaps? > > -Jim > > Dave CROCKER wrote: >> The draft doesn't specify a discussion venue. I believe the plan is to >> request >> Informational RFC status. >> >> With respect to the IETF, is there a better place for discussion than the >> DKIM list? >> >> d/ >> >> Original Message >> Subject: I-D Action:draft-hoffman-dac-vbr-04.txt >> Date: Thu, 9 Oct 2008 08:45:01 -0700 (PDT) >> From: internet-dra...@ietf.org >> Reply-To: internet-dra...@ietf.org >> To: i-d-annou...@ietf.org >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : Vouch By Reference >> Author(s) : P. Hoffman, et al. >> Filename: draft-hoffman-dac-vbr-04.txt >> Pages : 12 >> Date: 2008-10-09 >> >> This document describes the Vouch By Reference (VBR) protocol. VBR >> is a protocol for adding third-party certification to email. It >> permits independent third parties to certify the owner of a domain >> name that is associated with received mail. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-hoffman-dac-vbr-04.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> >> > ___ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html > -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Next steps for draft-ietf-dkim-ssp
Stephen Farrell wrote: > I don't believe this discussion is necessary in order to progress the ADSP > draft, which, for better or worse, is where the WG's rough consensus ended > up. Stephen, Happily, a community learns things about specifications as time progresses. Sometimes that learning uncovers problems and the problems get resolved. For example, that's was RFC Errata are for. In the current case, this is a rather fundamental and persistent confusion in the community about DKIM's "output". The Signing specification states: > 1. Introduction > > DomainKeys Identified Mail (DKIM) defines a mechanism ... > permitting a signing domain to claim > responsibility ... > Message recipients can ... confirm that the > message was attested to by a party in possession of the private key for the > signing domain. and > 1.1 Signing Identity > > DKIM separates the question of the identity of the signer of the message from > the purported author of the message. In particular, a signature includes the > identity of the signer. Verifiers can use the signing information to decide > how they want to process the message. The signing identity is included as > part of the signature header field This language declares that the result of a DKIM verification is an identifier that declares some responsibility. The question, now, is which string represents that identifier? The fact that there are serious, knowledgeable folk who declare it is the d= tag and other, equally serious and knowledgeable folk who declare that it is the i= tag, and that there are substantial numbers of each means that we have a real and basic problem: The community does not currently have consensus about where to find the one value that is DKIM's output! This is not something that can get resolved by fiat, Steve, such as saying that a prior decision by the working group resolves the matter. And it is not something that gets resolved by one or another person pointing to some other language in the Signing spec and declaring that it provides the one true answer. If the real world has competing interpretations of the spec, then the spec will not be used in a consistent matter. And it's difficult to find a more serious problem with a specification, since it means that the core semantic has ambiguous interpretation. What we are seeing, now, is that work on ADSP is (again) surfacing this basic confusion. Approving ADSP, in the absence of resolving this basic confusion about what value to use, merely entrenches the confusion further. It doesn't actually resolve it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] draft Errata on RFC 4871
Folks, Howdy. I've just submitted an Internet Draft with text for the working group to consider. A group of us have been working on it. It clarifies and resolves the roles and relationship of the d= and i= tag. An html version of the I-D is at: <http://dkim.org/specs/draft-ietf-dkim-rfc4871-errata-00.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] draft Errata on RFC 4871
Stephen Farrell wrote: > Separately, is the best route from here to do a 4871bis > (assuming the 5378 mess gets sorted), that incorporates > all agreed errata to date? If not, then what? Stephen, The intent for this effort was to issue it as an Errata entry, per <http://www.rfc-editor.org/errata.php>. The changes are narrow and few. We really don't need to generate a brand new RFC just for this. Or at least, not yet, IMO. 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] draft Errata on RFC 4871
Eliot Lear wrote: > Please say more because this is not at all clear to me. Why are more > TLAs (or in this case FLAs) there? Also, you've defined another term: > Identity Assessor. Why? There is real and substantial confusion in the community about these two tag values. Confusion that affects interoperability. (I tend to use the cliche' about watches: if you have one, you know what time it is; if you have two, you are never quite sure.) I regularly hear someone explain their particular, reasonable and sophisticated intent behind using one or another of the two values, as if there is some magic by which the organization running the other side of the DKIM exchange is going to a) be motivated, and b) be knowledgeable enough, to incorporate that intent into their use of DKIM. In fact, the other participant has no way of knowing about that intent, and scaling limits make it impossible to incorporate all the different intents. What is missing is the thing that has always been at the core of successful Internet protocol interoperability: a small, common, core of semantics. The DKIM community disagrees about which of the two values is that common, core, semantic output. Creating distinctive names for the two makes a reference that uses one of them unambiguous; clarifying the role and relationship of each makes the meaning of each unambiguous. That's goodness. It's also essential for interoperability. > Finally, I'll add one more comment, and then I'll withdraw. There are a > lot of errata filed for 4741. This is a good indication that it's > probably time for another version, and I would view this as good news > because it demonstrates a lot of work has occurred, Good point. So I'll suggest that we considered this proposed Errata as an Errata entry, first and by itself, and *then* pursue generating a revised dkimbase RFC. That way we focus on the proposed Errata narrowly, and reach consensus on it, before expanding the scope to an entirely new RFC. Tony's suggestion that we pursue Draft status at the same time makes sense to me. I had forgotten there were all those other errata. d/ ps. I can't find any documentation that says anything about Errata scope other than it covers 'errors'. Beyond that legalistic point, the proposed change is, in fact, quite narrow and it merely fixes the technical ambiguity about the output that the document says is its primary goal. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft Errata on RFC 4871
Michael Adkins wrote: > A question regarding the notes in 10 and 11: > > Would it make more sense to suggest that the mail system make the UAID > clear to the reader if its the identity whose reputation was used to > deliver the message, and make the SDID clear to the reader otherwise? Simple question: why? Complex question: What is the empirical basis for believing that any user interface design recommendations that we make will have any utility to the end-user? Experience with usability design demonstrates a key constant: it is almost impossible to ensure user interface utility in the absence of empirical data. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] RFC4871bis
but, ummm..., this really would be a functional enhancement, and so it ought to be discussed as part of the broader RFC revision effort, and certainly under a different thread, such as the Subject I'm using here... d/ Tony Hansen wrote: > A side conversation with several people generated these two areas of > interest to a verifier about the i= identifiers being generated by a signer: > > 1) Are the values stable? That is, will the same value be used by the > signer each time a message is signed on behalf of a particular > user/agent? Examples of stable values are > emailaddr...@domain.example.com (such as AUIDs that use the same > namespace as their users' email addresses), > user10234...@domain.example.com (such as AUIDs based on the users' > internal user IDs), and abcdefgh123456...@domain.example.com (such as > AUIDs based on a hash of the user name). Examples of unstable values > would be ones that incorporate additional information within the i= > value that is time varying, but is still able to be mapped to a single > user's/agent's identity. > > 2) For stable values, is the namespace the same as the users' email > addresses? That is, is the stable value the same as the user's email > address? > > One suggestion made was to use key record t= value to communicate this > information. > > Tony Hansen > t...@att.com > > Michael Adkins wrote: >> I think there will be cases where a signer chooses to make their UAID >> semantics known to assessors specifically for assessment purposes. How >> the signer might communicate that to the assessors is out of scope for >> the moment I think. I would assume that, for starters, the signers would >> approach individual assessors/mailbox providers. If it proved useful and >> was worth doing on a larger scale, then we could figure out a way to >> make the signer's preference automatically known to assessors. >> >> >> Siegel, Ellen wrote: >>> >>>> A question regarding the notes in 10 and 11: >>>> >>>> Would it make more sense to suggest that the mail system make the UAID >>>> clear to the reader if its the identity whose reputation was used to >>>> deliver the message, and make the SDID clear to the reader otherwise? >>>> ___ >>>> >>> [> ] >>> Given that the semantics of the UAID are inherently opaque, how >>> would you suggest that the mail system make the assessment? I like >>> the concept, but don't see how it can be implemented given the >>> defined syntax/semantics. > ___ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html > -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
