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
