There are a lot of ways to do this but lets try to keep it all within
512k please.
Bill Oxley
Messaging Engineer
Cox Communications, Inc.
Alpharetta GA
404-847-6397
bill(_dot_)oxley(_at_)cox(_dot_)com
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Stephen
Farrell
Sent: Friday, August 25, 2006 7:45 PM
To: Jim Fenton
Cc: IETF-DKIM
Subject: Re: [ietf-dkim] Scalability concerns with Designated Signing
Domains
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.
Yes. I can see terrible scaling problems if we went that way. But
our current reqs draft does have text on this in 4.3. Maybe that needs
to translate into a new section 5.x on scaling requirements? (Covering
both the large, and the small, scale?)
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.
Yep. 120 names sounds horrible. But then so would be 120 delegatees
of whatever flavour probably.
But I at least have no clue as to how many domains would have so
many delegatees, versus how many would not easily be able to use
NS delegation or key based delegation. And I see different opinions
on the list. That's why I find it hard to see how to we can decide
this well. (Though we will decide it well of course.)
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?
Have to hope not. But I suspect the number of signing delegatees
should really be (able to be) a different scaling issue than the
number of mailing-lists a domain uses.
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.
True. But 120 copies of the same public key is also bad, and 120 copies
of the same private key is unthinkable (for a security type anyway:-).
I don't personally know if 120 copies of the same key record in
different bits of the DNS is bad, not whether 120 key records for a
single domain is very bad. Doesn't sound good though.
So, yes, all delegation schemes each have their different problems.
I suspect that that'll always be the case since delegating is basically
not an easy thing to do with precision.
S.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html