ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] protecting domains that don't exist

2008-04-16 16:34:07

On Apr 15, 2008, at 7:33 PM, Frank Ellermann wrote:

Douglas Otis wrote:

This is still assuming use of DNS in conjunction with some future  
transport.

Yes, ADSP is published using DNS, and it's about "mail", the  
abstract says.  ADSP flags in Fido nodelists for the purposes of  
Fidomail is not discussed in RFC 5016 (sorry, couldn't resist after  
you forced me to figure out what "PNRP" is ;-)

Okay.

It seems using DNS to assert policy necessitates use of DNS by all  
possible transports.

When I mentioned missing domain literals I meant it, but in essence,  
yes, the format of mail addresses in 2822upd is for DNS lookup, not  
for Fido, UUCP, or X.500.

Since it is impossible for domain literals to represent a signing  
domain for DKIM, it would seem obvious literal addressing is a matter  
not covered by ADSP.

RFC2822 specifies "Internet Domain".  While the term Internet Domain  
infers a single name space, name spaces within corresponding services  
resolving addresses and services could be introduced under differing  
TLDs.  PRNP was given as an example, since this scheme resolves  
address structures needed to navigate through gateways and tunnels.   
While this scheme is proprietary, existence of an enhanced name  
service represents a current need being fulfilled.  PRNP allows groups  
to assign "friendly names" with unique identifiers which may overlap  
DNS name space.  Even so, this name space could be defined in a  
complaint manner using a scheme like name._group for example.  With  
ADSP imposing "existence" requirements, now only DNS determines what  
is an Internet Domain.

Unless consensus surrounding ADSP being forever linked to SMTP/DNS  
can be established, an assumption of 'existence' checks seems  
rather dubious.

DKIM isn't bound to SMTP, and existence checks for something that's  
no domain might not need DNS.  But the discussed ADSP draft wants us  
to look up _adsp._domainkey.example. in DNS if example. exists in  
DNS (swapping steps 1 and 2).

Agreed, DKIM is not bound to SMTP.  The suggestion is to avoid  
conflicts by binding ADSP policy assertions specifically to email  
addresses _suitable_ for SMTP/DNS.  The current ADSP draft requires  
RFC2822 Internet Domains "exist" within DNS, which is not currently  
required.  ADSP stipulates DNS.  ADSP is to benefit SMTP.

Let's solve problems with completely different technologies later,  
and after we've seen that ADSP makes sense for email, that will take  
more than a year.

Agreed.  So limit the scope of the policy assertion to just SMTP/DNS.   
Consensus should be reached about what ADSP "existence" requirements  
really imply.

The NXDOMAIN existence check also ignores issues related wildcards

There are no wildcard issues I'm aware of.  Nothing outside of a  
zone, neither below nor above it, can create wildcards affecting the  
zone.  Please correct me if that's wrong, and give an example of  
what you have in mind...

When the ADSP existence scheme depends upon an NXDOMAIN, this will  
fail to offer protections when either a network or TLD provider  
introduces wildcards, or when the domain itself uses wildcards.  By  
depending upon NXDOMAIN, ADSP protections just not possible when  
wildcards are introduced.

It is rather ironic a well considered alternative policy scheme  
depended upon use of wildcards and publishing records at every node  
blocking the wildcard.

...dunno what you mean.  A single existing node blocks any wildcard  
above it for the complete subtree where it is the root, doesn't  
it ?  If you are interested in domain.example. make sure that it has  
an A or MX or whatever, and there is no wildcard that could affect  
anything below domain.example.

Skipping your 2821bis rant, I supported you as good as I could, when  
Keith gave up the battle was lost from my POV.

Perhaps pride inhibits an ability to impose necessary discipline,  
similar to a proud parent ignoring their misbehaving child.  It is  
ludicrous to suggest domains publish bogus MX records to avoid  
undesired SMTP traffic, but those implementing SMTP can not be  
expected to publish valid MX records.  This is shameful.

-Doug
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>