[ietf-dkim] Scalability concerns with Designated Signing Domains
stephen.farrell at cs.tcd.ie
Fri Aug 25 16:44:55 PDT 2006
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.
More information about the ietf-dkim