On Apr 16, 2008, at 7:58 PM, Frank Ellermann wrote:
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.
DNS has not been required in RFC2822, only that naming _syntax_ be
compliant. In the case of ADSP, DNS is mandated and even includes
heuristics specific to DNS.
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.
Other naming services are being explored where naming service agility
requires minimal dependence on service specific heuristics, AND not
assuming _all_ Internet Domains are resolved within DNS.
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...
A proprietary scheme is not recommended, but it is not be unthinkable
open source schemes might offer similar features, and perhaps overcome
some of DNS's security issues as well. Discussing naming service
agility in the abstract is difficult. However, it is rather clear
ADSP has stipulated DNS and its heuristics. ADSP should declare the
extent of the policy and stipulate this policy _only_ relates to email-
addresses suitable for SMTP and DNS.
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.
In this scheme, the group accepts friendly names bound to a patented
process of self generated identifiers and self-signed certs. Security
seems reliant on the group's vetting. How much worse is this over
BGP? : )
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 ?
When a name is within a different naming service, it is unlikely ADSP
policy would be available. The problem occurs when there is _first_ a
negative "existence" check (NXDOMAIN). When a domain does not exist
within DNS, although the SMTP MAIL FROM email-address does, the
application of ADSP policy may cause such messages to be rejected.
Otherwise, what value would ADSP compliance offer?
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 concern is not over naming syntax.
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).
IN class is a heuristic of DNS. Require email-addresses governed by
ADSP to be compliant with SMTP. This restriction allows dealing with
issues related to wildcards and avoids reliance upon negative
existence checks within DNS (and DNS heuristics such as NXDOMAIN). By
depending upon positive existence, ADSP compliance would minimally
indicate the From email-address is compliant with SMTP.
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.
However, TLD wildcards prevent ADSP spoof protections that might
otherwise have encouraged its application. Coping with this abuse
necessitates confirmation of SMTP discovery records.
or when the domain itself uses wildcards.
Yes, that's the case for xyzzy.claranet.de. So what ?
Unless the MX record are wildcarded, confirming SMTP discovery records
eliminates the use of wildcards being a problem. After all, there are
other reasons to use wildcards unrelated to SMTP.
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).
Of course, the ADSP policy itself can not be wildcarded due to the
prefix, but this issue was not the concern.
[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.
Turing in the wrong direction does not properly direct a slow moving
process. The harm likely to result could be substantial.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html