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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html