[ietf-dkim] Issue 1576: Revise wildcard discussion

[Douglas Otis]

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