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

[Frank Ellermann]

Douglas Otis wrote:

> RFC2822 specifies "Internet Domain".

Yeah, good enough for ADSP.  There is a note in 2822upd-06:

| A liberal syntax for the domain portion of addr-spec is
| given here.  However, the domain portion contains addressing
| information specified by and used in other protocols (e.g.,
| [RFC1034], [RFC1035], [RFC1123], [I-D.klensin-rfc2821bis]).
| It is therefore incumbent upon implementations to conform to
| the syntax of addresses for the context in which they are used.

> name spaces within corresponding services resolving addresses
> and services could be introduced under differing TLDs.

They could, and they will do the right thing, or publish a
draft explaining what "the right thing" is if it's unclear.

> PRNP was given as an example, since this scheme resolves  
> address structures needed to navigate through gateways and
> tunnels.

AFAIK MS still thinks that SenderID solved the spam problem
in 2006, everybody uses it, and nobody bothered to inform
them that they confused PRA and SPF among other things. ;-)

Seriously, you don't want to discuss the "Cesidian root"
and Apple Talk on the DKIM list, or do you ?  That's fun
stuff for edit wars in Wikipedia, or flame wars on the
Namedroppers list...

> unique identifiers which may overlap DNS name space.

...their problem, they broke it, they fix it.  Of course
odd things happen when name spaces overlap, e.g., what is
a "unique identifier" in this case ?  For a unique number
in a name space UUID take 122 SHA-1 bits, that is "better"
than 122 MD5-bits.  Some RFCs are hilarious, or I missed
the clue, completely.

> using a scheme like name._group for example.  With ADSP
> imposing "existence" requirements, now only DNS determines
> what is an Internet Domain.

Where do you want to get _adsp_.domainkey.name._group from ?
If the existence of name._group does not matter, what about
the uniqueness of _adsp._domainkey.name._group ?  And under
what circumstances would IANA survive the introduction of a
_group TLD violating RFC 1123 and my 1123-erratum ?  Don't
mess around with RFC 3696 :-(

> The suggestion is to avoid conflicts by binding ADSP policy
> assertions specifically to email addresses _suitable_ for
> SMTP/DNS.

The existence check is at worst bound to class IN (please
check this) and limited to non-existence, where SMTP, HTTP,
NNTP, etc. don't enter the picture.  FWIW "NXDOMAIN" also
means no WKS, no RP, no HINFO, no SRV (please check this).

> When the ADSP existence scheme depends upon an NXDOMAIN,
> this will fail to offer protections when either a network
> or TLD provider introduces wildcards

Not for what we are talking about.  As long as "something"
exists at claranet.de. TLD de. cannot create any wildcard 
affecting xyzzy.claranet.de., www.xyzzy.claranet.de., etc.

> or when the domain itself uses wildcards.

Yes, that's the case for xyzzy.claranet.de.  So what ?  It
is a stupid wildcard, permanently disabled due to abuse by
spammers sending more spam to @xyzzy than claranet.de was
willing to let me kill with POP3 over V.90.  (They gave up,
JFTR, but admittedly I didn't insist on reviving @xyzzy :-)

> By depending upon NXDOMAIN, ADSP protections just not
> possible when wildcards are introduced.

ADSP and DKIM are not designed for wildcard tricks, we know
this, this has nothing to do with NXDOMAIN, it is just a
consequence of using _adsp._domainkey "property-subdomain-
labels" (correct term TBD, compare Dave's draft).

 [Off Topic about 2821bis]
> 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.

I don't disagree.  But obviously the PTB prefer to handle
it elsewhere, in separate RFCs.  

 Frank