On Jul 4, 2008, at 5:03 AM, Stephen Farrell wrote:
Issue description: https://rt.psg.com/Ticket/Display.html?id=1576
Thread: http://mipassoc.org/pipermail/ietf-dkim/2008q2/010387.html
ssp-04 did revise the wildcard text, but not exactly as suggested in
the issue, nor am I clear about whether the new text satisfies the
couple of people (Eliot, Frank) who commented in the thread.
However, given that ssp-04 made changes along the lines suggested if
there's no further discussion I'll ask Eliot to close this one
on July 11.
Suggesting a wildcard domain to publish ADSP records is ill advised.
The current ADSP draft fails to stipulate a syntax for host names,
other than to mention case insensitive per RFC2821, or that RFC2821
procedures _MAY_ be used to verify existence.
Ironically, declaring which transport protocol is asserted by ADSP
records has been described as "mission creep" by some. This
indifference means there is _no_ guiding basis regarding valid domain
name syntax. There is a normative reference to RFC2822, where RFC2822
uses an example of RFC2821 as to where a domain might be specified.
Nevertheless, RFC2822 permits "atext" within the domain name. As
such, a domain such as "chosen.*.example.com, or
"chosen._domainkey.example.com" would be valid. Permitting these
names defeats synthesizing ADSP records which, if relied upon, would
then become a significant security hole. Omission of any relevant
public transport permits critical security aspects to be overlooked.
A "valid" domain depends upon the transport protocol, however, in the
case of ADSP, no transport is defined! When dealing with domains at
the MUA, where DKIM validation, and therefore ADSP, might be applied,
non-DNS based domains _are_ legitimately exchanged using non-SMTP
transports. One example would be MS Exchange. Although it is
unlikely any other public exchange transport other than RFC2821 will
initially include DKIM signatures, this transport is not mentioned
within the ADSP draft as providing a basis for conformance
expectations. There is also no mention of what might happen to
converted messages carried by other transports then introduced into
SMTP.
As a result, ADSP offers no guidance as to what TLD domains might be
used to bypass conformance requirements. For example, ".nntp",
".local", or ".invalid" might offer a means to request exceptions to
expectations asserted by ADSP records. It also seems that getting
exceptional TLDs defined now is important due to policy changes being
proposed by ICANN.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html