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 "joe(_at_)eng(_dot_)example(_dot_)com" (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 "i=a(_at_)domain(_dot_)example", then
domain.example is asserting that it takes responsibility for the
message. If the message's From: field contains the address
"b(_at_)domain(_dot_)example" 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
"b(_at_)domain(_dot_)example" 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