There are a lot of ways to do this but lets try to keep it all within 512k please.
Bill Oxley Messaging Engineer Cox Communications, Inc. Alpharetta GA 404-847-6397 [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Farrell Sent: Friday, August 25, 2006 7:45 PM To: Jim Fenton Cc: IETF-DKIM Subject: Re: [ietf-dkim] Scalability concerns with Designated Signing Domains 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. S. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
