On Aug 25, 2006, at 2:48 PM, Jim Fenton wrote:
[This is the first of a two messages outlining my concerns about
SSP Designated Signing Domains. I'll break each category of
concerns into a separate thread.]
If Designated Signing Domains become an accepted of delegating
authority to sign messages, I'm concerned about the scaling
characteristics of the list of domains. I haven't heard anyone say
that the list should consist of only one domain, but I have heard
discussion that even mailing list providers used by a domain might
be delegated domains. But let's not go there yet.
Let's assume for a minute that SSP is distributed in DNS, which is
at least a likely outcome. I'm aware of large enterprises with
>120 outside entities that send mail on their behalf. If each of
these entities takes 10 characters, then the list is 1200
characters long -- getting interesting for DNS over UDP, even with
EDNS0. If the delegation is to subdomains of the delegatees, each
the name of each entity is likely to be longer than that.
We shouldn't be designing something that is this likely to go over
a limit such as this. Does this mean that we need to have
continuation records to carry the additional entries? It sounds
like the retrieval of these continuation records would be additive
to the time required to evaluate the message. Verifiers would also
need to be prepared for the possibility that only portions of SSP
are going to be available at a given time, and maintain state
information to keep track of that.
A designation scheme should be viewed as a means to provide small
outfits a simple means to enable DKIM protection for their desired
2822.From address. Perhaps this mode of designated delegation might
encourage a cadre of provider's to validate the 2822.From addresses
signed by their "common man's" domain.
When large ISPs kick out a slew of 2822.From addresses that have not
been validated, the DKIM signature added to these messages is of
little value. Bots! Just the validation of the 2822.From would
enable their customers to use their desired email-addresses while at
the same time receive protection from any other customers within that
signing domain from spoofing them, assuming the MUA has a way to
annotate the message containing a signing-domain/email-address
protection. All their customers can still enjoying the freedom of
being able to use their desired email-address after demonstrating its
receipt. This validation is a scheme used in millions of places
represents improved security.
In section 3.3 of this "straw-man" draft:
http://www.sonic.net/~dougotis/dkim/draft-otis-dkim-dfsp-00.html:
-- "The Designated Signing for Address list is not intended to
include more than a few domains. When more than a few domains are
required, key/location methods of delegation should be used instead." --
This should be a good compromise. Perhaps you want more however.
If someone wanted to associate tens of thousands of domains, this
would still require just one lookup:
query (<domain-in-question>._dfsp._domainkey.<domain-of-from>, TXT)
which also returns a small record containing only a pertinent answer
and not a long list.
This query is answered with a zone as follows:
*._dfsp._domainkey.<domain-of-from> TXT v= 0.0
a=domain-of-from;
<domain-in-question>._dfsp._domainkey.<domain-of-from> TXT v= 0.0
a=domain-in-question;
This is not a Turing complete language of redirects. This uses a
common utility within DNS. This mode of operation is very common for
doing block-list lookups of urls, and is used in this manner in many
places.
Are there going to be guidelines on what sorts of entities should
be included in the lists and what sorts should not? For example,
should ietf.org be included if someone in the domain is subscribed
to ietf mailing lists? Should mipassoc.org be included, even if we
didn't know that Dave is unquestionably reliable?
No. Assume there is a DKIM aware MUA that can note when a valid email-
address has been found in the address book. This mode of operation
saves someone from having to ask "Is that really you Jim? You would
not want to enable an avenue for spoofing just for this luxury.
Delegation of keys, either through publication of a selector that
includes a provider's public key or through delegation of a
subdomain to a provider, does not run into this problem.
Actually it does. When this delegation does not occur and the
2822.From domain does not match. Getting a message with an identity
of "[EMAIL PROTECTED]" is joyless. You may not even know whether the
@isp.com component of the email-address is to be trusted.
Yes there are problems with DNS and changes of conduct will be
needed, but there are also solutions. Opt for the exchange of public
keys when setting up a relay. They well need to poke you with new
keys at some set of internals. Perhaps you could use your existing
key to decrypt the next to narrow the exposure when using this method.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
