On Mar 18, 2008, at 9:09 AM, Dave Crocker wrote: > > > Steve Atkins wrote: >> Without that check, an unsigned mail from [EMAIL PROTECTED] will >> be considered to comply with ASP unless there is an ASP record >> for _asp._domainkey.bar.baz.ebay.com or for >> _asp._domainkey.baz.ebay.com > ... >> The domain existence check means that only a defined number of ASP >> records need to be published (the number of hostnames you publish >> would be an upper bound unless you're using wildcards anywhere else >> in your DNS, in which case all bets are off). > > (Thanks for Barry for reminding me to review this.) > > Steve, > > Many apologies, but I am simply not understanding this. > > Just to make sure we are on the same page about the hierarchy trick > in the spec: > > The one-level-up hack might be useful for saving some > administration, but it does not provide meaningful "protection", > since all an attacker has to do is use a level down.
Yup. It adds no new functionality (actually it removes some), but does make deployment for the record publisher simpler, at the cost of making deployment for the record publisher less flexible and the checker more complex and slower. It doesn't provide for protection of all possible hostnames in a domain, and using one a level down is one example of that. > > > With respect to an A record, its presence does tell you that the > name is valid, but it does not tell you anything about ADSP > support. Initially there will be virtually no adoption of ADSP. So > what does finding an A record, but no _adsp record, tell you? It tells you two things. It tells you that the domain owner is aware of that hostname, and that they did not choose to publish an _adsp record that covers it. If we consider a two step process, where in order for an _adsp[1] record to match a query it must either be the same, or one level up the domain hierarchy from the hostname (this is what we have now if we exclude the existence test - www.example.com will be covered only by a TXT record for_adsp._domainkey.www.example.com or _adsp._domainkey.example.com). A domain owner cannot publish a single _adsp record that covers an entire domain (example.com and any hostname having .example.com as a suffix). Similarly, they cannot publish a finite list of _adsp records that cover an entire domain. This is true whether or not you consider the "up one level" hack. A domain owner cannot conveniently publish an infinite[2] list of _adsp records. If a desired functionality is for a domain owner to be able to assert policy over all hostnames within their domain by publishing a finite number of _adsp records, then you need an additional step in the process. One possibility for that would be to extend the "up one level" hack to chase up the tree until it reaches the root. Another possibility, the one in the current draft, is to assert that the domain owner has a finite number of hostnames in use within their domain and so can publish a finite number of _adsp records to cover those hostnames in use (trivially, by a 1:1 correspondence between _adsp records and hostnames, at worst). As there will never be a legitimate use of a hostname that may be checked for an _adsp record that doesn't have any DNS record corresponding to it[3], asserting an ADSP fail for any case where there is not a corresponding record in DNS will not cause any unintended failures, and allows the domain owner to assert policy across all possible hostnames within their domain. This fails in the case where the domain owner is using wildcard records for any use within their domain. > I think what this is uncovering is that adoption of ADSP requires > ensuring ADSP query results for all valid names. In that context, > I guess I can see the benefit of having an A record serve to define > what names are valid. An A record is not adequate for proof of validity, as there will be quite legitimate cases where the hostname has an MX record but not an A record, and we can't assert an ADSP fail there just because there's no A record. "A or MX" is likely adequate, but "any record" is certainly adequate, and likely free to check in most cases. > Mumble. This is still feeling a bit squishy to me, although at > least I'm starting to see the possibility of its being useful. (I > think the doc at least is going to have to be much more clear about > its role.) It's all very squishy. (And part of the squishy is that "but if there's no A or MX record for the email address then the mail will be rejected before checking ADSP" is clearly true whether or not an ADSP spec says so, so adding that step to the spec doesn't actually change what will be done operationally, but it's needed to make the spec self- contained and to document the thought process.) But if there is a desire for a domain owner to be able to assert policy across all possible hostnames within their domain then you cannot remove the domain existence check without replacing it with something else[4]. The approach in the current draft is inexpensive to check, but does fail spectacularly if there is any use of wildcard records within the domain. We should document that, probably without using the phrase "fail spectacularly". Cheers, Steve [1] I'm just following the flow of conversation by using _adsp, don't consider it a show of support for that phrasing as I'm really agnostic about the name. [2] For values of infinite that are in excess of 38^189, if not truly without bound. Well, you can pretty easily, but not using standard configurations of bind, powerdns etc, as they don't support generalized wildcard records. [3] As the hostname being checked is on the RHS of an email address there must be an A record or MX record for it, in order for it to be... operationally relevant, anyway. [4] Given that the stated purpose of ADSP is to protect email addresses I believe that replacing both the one level up hack and the existence check with an explicit check for an MX record for the given hostname, and returning an ADSP fail for any email sent with a RHS that has no MX record for it would be a Good Thing, but it would probably step on too many toes to actually consider as a standard. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
