[ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree

[Douglas Otis]

On Apr 7, 2008, at 8:33 AM, Eliot Lear wrote:

> Barry:
>>> 3.  At least one of the sub-tree mechanisms is attempting to glean  
>>> information from the absence of publisher action.  Let me explain:
>>>
>> ...
>>
>>>>   c) Checking for the presence of an A record is intended to try  
>>>> tell you something in the absence of an explicit action by the  
>>>> domain owner.  That's it's flaw: It is intuiting ADSP information  
>>>> from non-ADSP action.
>>>>
>>>>   While there is nothing wrong with checking the A record, it's  
>>>> semantics have literally nothing (directly) to do with ADSP.
>>>>
>>
>> I agree with that assessment, but more importantly, I think the  
>> working group doesn't yet agree on whether he's right or not.
>
> As Frank points out, that's not what the draft says.  The draft says  
> that you can pick *any* record.  The purpose is simply to determine  
> whether the domain exists.  The argument is semantically different,  
> particularly when you discuss this in terms of the recommended  
> query, an MX record.  The worst you can say is that there is an  
> interdependency between the deployment of MX records and ADSP  
> records in the very same domain.  The only reason you have to do the  
> query is because of the additional labels applied.  If you want to  
> get away from this you need to use a new RR.

This could be generalized as a domain spoofing issue.  Before SMTP  
receivers expend resources validating signatures, a check of the  
originating domain's validity eliminates the expenditures of  
validating signatures for domains that otherwise are determined  
invalid through the lack of inbound SMTP servers.  Protecting  
resources is not a trivial matter, as DKIM demands more of receivers.

Querying any record may not be conclusive.  When either network  
providers or domains themselves inject synthesized wildcard records,  
sub-domains unrelated to valid message email addresses will appear to  
exist.  To prevent this situation from being exploited, specific  
checks for MX or A resource records indicate at least possible support  
of SMTP servers by the domain.  The recommendation in issue 1547  
simplifies this test.  Without MX resource records being found,  
receivers could conclude ADSP records below the '_adsp.' prefix do not  
exist either.

While DKIM is not limited to SMTP, the purpose for ADSP seems related  
to the spoofing of SMTP message sources.  After all, methods of  
message exchange involving prior arrangements are unlikely benefited  
by ADSP.  As such, ADSP should stipulate this limitation as this would  
better ensure proper use.

It seems some aspect of this concern appears to have been closed in  
issue 1551.  The tracking note only indicates 'resolved' by the Philly  
meeting consensus.  There is nothing within the minutes indicating  
what discussion took place or what aspect of this issue had been  
resolved or rejected.

While MUA related protocols may be used in conjunction with SMTP, the  
public exchange of messages using SMTP is where ADSP offers benefit.   
If messages from sources other than those initially from SMTP are to  
be covered by ADSP, is there a list of these initial non-SMTP message  
sources?  Such a list could permit a review of ADSP's impact on these  
different protocols.  The introduction and even details related SMTP  
error codes seem to indicate ADSP is a mechanism intended to operate  
in conjunction with messages initially exchanged by SMTP, and then  
secondarily through MUA related protocols.  What problem would be  
created by making a statement that ADSP is intended to benefit  
messages initially exchanged using SMTP?

-Doug