[ietf-dkim] Scalability concerns with Designated Signing Domains
ietf-dkim at kitterman.com
Fri Aug 25 15:06:26 PDT 2006
On Friday 25 August 2006 17:48, 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.]
Thanks. I appreciate you taking the time to lay this out. I think different
people have slightly different views of this. I speak only for myself.
> 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.
First, since mailling lists are inherently uncontrolled, I don't think they
would ever be suitable for being designated/delegated.
I agree that the list needs limitations. If we can get two or three, I think
> 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.
This class of entities no doubt has the ability to do NS delegation. I have
always envisioned this as a tool for small, non-technical author domains. We
definitely would need to set up limits.
> 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.
I think this means we set a size limit for the record that won't have these
problems. I think it's unlikely to be an issue for the class of user I
expect will make use of this.
> 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?
Yes. We must have these guidelines and I've volunteered to draft them.
It isn't a question of Dave's reliability, but of his mailing list software's
ability to ensure messages are from who someone claims they are from. I
don't see a good way to do that for mailing lists, but if someone does,
> 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.
That's true. But I don't think there's anything here that isn't easily
manageable as long as we remember this is not a general alternative to NS
More information about the ietf-dkim