512k?? -Jim
[EMAIL PROTECTED] wrote: > 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
