I've gone through the IETF last call comments for ADSP. I've understood that the major issues raised by Doug have been discussed in the WG earlier, and the WG reached rough consensus on them.
If that's the case, I have no problem with it. However, after reading Doug's comments together with RFC 4871 and draft-ietf-dkim-ssp-07, I think there are some cases where the document needs additional clarify or details about the decisions that were made. 1) "i=" tag The terms "Valid Signature from an Author Domain" and "Author Signature" are very easily confused. If I understood Doug's comments right, he's essentially proposing making these two terms identical. That would certainly simplify things, but since the WG has decided otherwise, we need to make sure the distinction is understood by the reader. I will send a separate email about this topic. 2) Protecting subdomains S3.1 is clear that an ADSP record at _adsp._domainkey.domain.example applies only to emails from that specific domain (domain.example), not its subdomains. However, I think we need an additional paragraph explaining the implications of this choice for domains that would like to protect their subdomains (for every <X>.domain.example that exists, they have to deploy ADSP record at _adsp._domainkey.<X>.domain.example), and give some advice how DNS management tools could do this without either undue manual effort or wildcards (which are prohibited in S6.3). 3) Scope of ADSP Doug also commented the sentence "ADSP as defined in this document is bound to DNS", and suggested changing that to "...DNS and SMTP". I have a question here: Suppose that some future FooMTP protocol used e.g. SRV records at "_foomtp._tcp.eng.example.com" to find the server for address "[email protected]" (instead of using MX records). If all the RRs (including "_foomtp._tcp.eng.example.com") are in the "example.com" zone (no zone cuts under it), and no RRs with owner "eng.example.com" exist, does a DNS query for "eng.example.com" return NXDOMAIN or NODATA? If I had a DNS server installation at hand, I could of course test what it returns... but perhaps someone knows the answer already? If a query for "eng.example.com" returns NXDOMAIN in this case, then saying we're bound to SMTP (or protocols that use DNS records in very similar way as SMTP) might be more accurate. 4) Minor clarifications/nits >From my email on 2008-11-25: Section 4.1: OLD: The "Tag=Value List" syntax described in section 3.2 of [RFC4871] is used. NEW: The "Tag=Value List" syntax described in section 3.2 of [RFC4871] is used, with one minor change: WSP is used instead of FWS. Section 4.2.1 OLD ADSP records use the "tag=value" syntax described in section 3.2 of [RFC4871]. NEW: ADSP records use the "tag=value" syntax described in section 3.2 of [RFC4871], with one minor change: WSP is used instead of FWS. >From Miguel Garcia's Gen-ART review: "Section 6.2 discusses DNS attcks. However, I don't think that the second paragraph is discussing a DNS attack. It seems to be discussing a regular failure of a DNS server. While I don't disagree with the content, it seems that it would be better place in a section that is NOT titled "DNS attacks"." Any suggestions on this? In Section 1, "Author Signing Practices" probably should be "Author Domain Signing Practices" Section 2.7: "For example, if a message has a Valid Signature, with the DKIM- Signature field containing "[email protected]", then domain.example is asserting that it takes responsibility for the message. If the message's From: field contains the address "[email protected]" and an ADSP query produces a "dkim=all" or "dkim=discardable" result, that would mean that the message does not have a valid Author Signature. Even though the message is signed by the same domain, it fails to satisfy ADSP. The second sentence seems incorrect. Should this say something like [...] If the message's From: field contains the address "[email protected]" that would mean that the message does not have a valid Author Signature. If an ADSP query produces a "dkim=all" or "dkim=discardable" result, even though the message is signed by the same domain, it fails to satisfy ADSP. Best regards, Pasi _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
