[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 adomain tree
Dave Crocker wrote: I believe the desire with checking the A record is similar to the idea behind having ADSP in the first space. I don't understand this, the I-D does not talk about A records. 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. If that's about step 2 in chapter 4.2.2 of I-D.ietf-dkim-ssp-03, that verifies the existence of the author domain by any query, recommending MX for this purpose. If the author domain doesn't exist the result is error. It is one of the four results in chapter 3.2 (no ADSP, all, discardable, nxdomain). While there is nothing wrong with checking the A record, it's semantics have literally nothing (directly) to do with ADSP. If the author domain does not exist it cannot receive mail, as there is no A, no , and no MX, among others. That check is not directly related to ADSP, it generally makes sense, maybe it should be done as first step. Is that the new issue here ? Related: Apparently the I-D does not mention domain literals. I think it should say something, domain literal isn't nxdomain. Frank ___ 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
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? 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 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. This having been said, the chair's have spoken and I won't delve further into why I think that issue should remain resolved. 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. 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. Eliot ___ 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
Since the Chairs have ruled that this warrants yet further discussion... Dave Crocker wrote: 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. Two comments: (1) It's worth being careful about the word protect; the draft doesn't use it (except once, in a somewhat different context) and we should be careful about setting an expectation that publication of ADSP confers protection. There is benefit to the publisher that may be viewed as protection that comes from the use of ADSP information by verifiers, but it is indirect and only to the extent that ADSP records are retrieved and used. (2) ADSP does not publish information about entire subtrees, only about domains and labels within an immediate domain. 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. Underscore-based names have no special standing within DNS (such as definition of attributes), other than the fact that they are illegal as hostnames but are legal for some other purposes. DNS wildcards are indeed useless in the face of name prefixes, which is why ADSP does not depend on nor use them. The mechanism described in the draft may be viewed as doing a partial job but we still need to consider whether what it does is useful. I believe it is. 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. Again, I reject the premise that this a sub-tree mechanism. What are the expanded semantics to which you refer? 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. ADSP is not checking the A record, as others have pointed out. -Jim ___ 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
On Apr 7, 2008, at 8:33 AM, Eliot Lear wrote: Barry: 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. As Frank points out, that's not what the draft says. The draft says that you can pick *any* record. The purpose is simply to determine whether the domain exists. The argument is semantically different, particularly when you discuss this in terms of the recommended query, an MX record. The worst you can say is that there is an interdependency between the deployment of MX records and ADSP records in the very same domain. The only reason you have to do the query is because of the additional labels applied. If you want to get away from this you need to use a new RR. This could be generalized as a domain spoofing issue. Before SMTP receivers expend resources validating signatures, a check of the originating domain's validity eliminates the expenditures of validating signatures for domains that otherwise are determined invalid through the lack of inbound SMTP servers. Protecting resources is not a trivial matter, as DKIM demands more of receivers. Querying any record may not be conclusive. When either network providers or domains themselves inject synthesized wildcard records, sub-domains unrelated to valid message email addresses will appear to exist. To prevent this situation from being exploited, specific checks for MX or A resource records indicate at least possible support of SMTP servers by the domain. The recommendation in issue 1547 simplifies this test. Without MX resource records being found, receivers could conclude ADSP records below the '_adsp.' prefix do not exist either. While DKIM is not limited to SMTP, the purpose for ADSP seems related to the spoofing of SMTP message sources. After all, methods of message exchange involving prior arrangements are unlikely benefited by ADSP. As such, ADSP should stipulate this limitation as this would better ensure proper use. It seems some aspect of this concern appears to have been closed in issue 1551. The tracking note only indicates 'resolved' by the Philly meeting consensus. There is nothing within the minutes indicating what discussion took place or what aspect of this issue had been resolved or rejected. While MUA related protocols may be used in conjunction with SMTP, the public exchange of messages using SMTP is where ADSP offers benefit. If messages from sources other than those initially from SMTP are to be covered by ADSP, is there a list of these initial non-SMTP message sources? Such a list could permit a review of ADSP's impact on these different protocols. The introduction and even details related SMTP error codes seem to indicate ADSP is a mechanism intended to operate in conjunction with messages initially exchanged by SMTP, and then secondarily through MUA related protocols. What problem would be created by making a statement that ADSP is intended to benefit messages initially exchanged using SMTP? -Doug ___ 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
-Original Message- From: [EMAIL PROTECTED] on behalf of Barry Leiba Sent: Mon 4/7/2008 9:58 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree 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. And Stephen and I have discussed Dave's note from today, and think it's appropriate to continue the discussion a bit. We need to keep it focused and come to a clear conclusion -- the problem is that we don't think we really have agreement on this question. 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. 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. * 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. Yes, this discussion is in scope for now. Let's keep the discussion on track, and resolve this quickly. Barry, as DKIM working group chair ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html Barry, slight modification * 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. We need to stop there as the rest of the sentence could include checking the credit score of a domain's owner as an DKIM/ADSP extension which may have value for an implementation but not a consensus document describing the value of a policy/practice. thanks, Bill Oxley ___ 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
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 [any DNS] 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. To clarify a perhaps overlooked point: the existence of [any DNS] record for the Originator domain does NOT imply that it is a valid email origin. If the record is absent, then we know nothing that the absence of the ADSP record for that domain didn't already tell us. Any suggestion to the contrary is probably a mistake. While there is nothing wrong with checking [any DNS] record, it's semantics have literally nothing (directly) to do with ADSP. Wietse ___ 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 (#1534)
Dave Crocker wrote: it is not in the requirements JFTR: http://tools.ietf.org/html/rfc5016#section-4.2 Deployment Consideration 2: Subdomain Coverage | Thus, it would be advantageous for SSP to not | only cover a given domain, but all subdomains | of that domain as well. I'm unhappy with some points in RFC 5016, and I still have enough of all sub-domain issues after the efforts in 2004, but the topic is mentioned in RFC 5016. /JFTR Which of his slides shows this? I see no #1534 in the nine IETF 71 PDF pages, and no 1534 in the jabber log. #1543 was discussed. Frank ___ 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
Date: Sun, 6 Apr 2008 23:06:25 -0700 From: [EMAIL PROTECTED] To: ietf-dkim@mipassoc.org Subject: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree 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. Dave, Like others I am guessing that you are referring to section 4.2.2 step 2. In that step it explicitly says that you can check for any record you want and the semantics of the returned record itself are basically irrelevant only the existence of some response other than NXDOMAIN matters. In the case of an NXDOMAIN I didn't read that section as intuiting any policy. It just says to return an error which I read as something different than, return some specific result. 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. 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). Robert _ Pack up or back up–use SkyDrive to transfer files or keep extra copies. Learn how. hthttp://www.windowslive.com/skydrive/overview.html?ocid=TXT_TAGLM_WL_Refresh_skydrive_packup_042008___ 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
Siegel, Ellen wrote: Jim, in your presentation to the ESPC you brought up the fact that one reason to encourage sub-domains to publish 'unknown' ADSP records was so that they wouldn't inadvertently inherit an ADSP record from a parent domain. As long as such inheritance is possible, i.e. that a subdomain can automatically inherit from a parent domain, it must be true that we're discussing subtrees. There is an important difference. The subtree of example.com includes everything ending in .example.com such as a.example.com, b.example.com, and even f.e.d.c.b.a.example.com. ADSP does not cover the subtree; it covers only labels in the immediate example.com domain. If we retain that capability, inadvertent or not, in the spec, I think we need to call it out explicitly and discuss how to counter it. There are two ways to counter that capability: either the subdomain publishes an ADSP record, or the parent domain publishes its ADSP record with the t=s flag as described in section 4.2.1 (or, conceivably, both). Another possibility, I suppose, is to apply an Author Signature to the message which makes ADSP irrelevant as long as it isn't broken. However, I agree with Dave that it may be cleaner to just exclude the possibility of inheritance rather than try to deal with the fallout. It's not cleaner for a domain that wishes to publish ADSP and has thousands of hostnames in the same domain now faces the prospect of publishing thousands of ADSP records, and doesn't have tools to automate this process. My comment at ESPC was that I believe it would be a Best Practice for Coalition members to routinely publish, or have published, explicit ADSP records for domains that they send from. -Jim ___ 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
Wietse Venema wrote: 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 [any DNS] 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. To clarify a perhaps overlooked point: the existence of [any DNS] record for the Originator domain does NOT imply that it is a valid email origin. If the record is absent, then we know nothing that the absence of the ADSP record for that domain didn't already tell us. Any suggestion to the contrary is probably a mistake. ADSP is doing the converse of that: it takes the non-existence of [any DNS] record for the Author Domain as an implication that it is NOT a valid email origin, or more accurately reports if that is the reason there isn't an ADSP record for that domain. -Jim ___ 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
On Apr 7, 2008, at 2:01 PM, Jim Fenton wrote: Siegel, Ellen wrote: As long as such inheritance is possible, i.e. that a subdomain can automatically inherit from a parent domain, it must be true that we're discussing subtrees. There is an important difference. The subtree of example.com includes everything ending in .example.com such as a.example.com, b.example.com, and even f.e.d.c.b.a.example.com. ADSP does not cover the subtree; it covers only labels in the immediate example.com domain. When the policy record below _adsp.example.com contains a parameter that precludes validity for sub-domains below example.com, then it must be expected this is being used. If we retain that capability, inadvertent or not, in the spec, I think we need to call it out explicitly and discuss how to counter it. There are two ways to counter that capability: either the subdomain publishes an ADSP record, or the parent domain publishes its ADSP record with the t=s flag as described in section 4.2.1 (or, conceivably, both). Another possibility, I suppose, is to apply an Author Signature to the message which makes ADSP irrelevant as long as it isn't broken. Sub-domain coverage concerns _how_ policy records are discovered when _not_ published within sub-domains containing email-address with either none or invalid signatures. However, I agree with Dave that it may be cleaner to just exclude the possibility of inheritance rather than try to deal with the fallout. It's not cleaner for a domain that wishes to publish ADSP and has thousands of hostnames in the same domain now faces the prospect of publishing thousands of ADSP records, and doesn't have tools to automate this process. This can be resolved by qualifying possible valid domains with the existence of resource records needed to discover SMTP servers. This limits the instances where ADSP records are need to those nodes that contain SMTP discovery resource records. My comment at ESPC was that I believe it would be a Best Practice for Coalition members to routinely publish, or have published, explicit ADSP records for domains that they send from. In that case, there is no need for ADSP. Change the ADSP draft to simply say use ESPC data to ascertain DKIM signature requirements. Perhaps ADSP draft should change into a standard format for this data. -Doug ___ 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
Wietse Venema wrote: 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 [any DNS] 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. To clarify a perhaps overlooked point: the existence of [any DNS] record for the Originator domain does NOT imply that it is a valid email origin. If the record is absent, then we know nothing that the absence of the ADSP record for that domain didn't already tell us. Any suggestion to the contrary is probably a mistake. Jim Fenton: ADSP is doing the converse of that: it takes the non-existence of [any DNS] record for the Author Domain as an implication that it is NOT a valid email origin, or more accurately reports if that is the reason there isn't an ADSP record for that domain. 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. Wietse ___ 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
Wietse Venema wrote: Wietse Venema wrote: 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 [any DNS] 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. To clarify a perhaps overlooked point: the existence of [any DNS] record for the Originator domain does NOT imply that it is a valid email origin. If the record is absent, then we know nothing that the absence of the ADSP record for that domain didn't already tell us. Any suggestion to the contrary is probably a mistake. Jim Fenton: ADSP is doing the converse of that: it takes the non-existence of [any DNS] record for the Author Domain as an implication that it is NOT a valid email origin, or more accurately reports if that is the reason there isn't an ADSP record for that domain. 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. That's true; that's why the result from ADSP in this case is, or should be, Unknown. But I don't see that in the spec; it simply indicates that no ADSP record was present, and the spec isn't giving enough guidance about what to do in that case. In ssp-01, it had said non-suspicious in this case, and apparently this got lost when suspiciousness was removed. Thanks for spotting that. -Jim ___ 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 (#1534)
Frank Ellermann wrote: I see no #1534 in the nine IETF 71 PDF pages, and no 1534 in the jabber log. #1543 was discussed. As I noted in http://mipassoc.org/pipermail/ietf-dkim/2008q1/009713.html , issue #1534 fell through the cracks when I was preparing my slides for Philadelphia and was not discussed. I had suggested that it not be closed without the opportunity for some discussion. -Jim ___ 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 (#1534)
Jim Fenton wrote: As I noted in http://mipassoc.org/pipermail/ietf-dkim/2008q1/009713.html , issue #1534 fell through the cracks when I was preparing my slides No problem, for the known reasons I (try to) stay out of sub-domain discussions. Swapping steps 1 and 2 in 4.2.2 might make sense: If an author-domain does not exist looking for an ADSP is pointless, result nxdomain is bad enough. Frank ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
