[ietf-dkim] Scalability concerns with Designated Signing Domains

[Scott Kitterman]

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 
that's appropriate.

> 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, 
great.

> 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 
delegation.

Scott K