Subject: [ietf-dkim] Scalability concerns with Designated Signing Domains

From: Jim Fenton <[email-masked]>
Date: Fri, 25 Aug 2006 14:48:42 -0700

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

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.

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?

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.

-Jim
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 25 Aug 2006 18:06:26 -0400

> Designated Signing Domains.  I'll break each category of concerns into a
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.

> mailing list providers used by a domain might be delegated domains.  But
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.

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

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

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

> 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

---

From: Douglas Otis <[email-masked]>
Date: Fri, 25 Aug 2006 16:10:08 -0700

On Aug 25, 2006, at 2:48 PM, 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.
>
> 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.

A designation scheme should be viewed as a means to provide small  
outfits a simple means to enable DKIM protection for their desired  
2822.From address.  Perhaps this mode of designated delegation might  
encourage a cadre of provider's to validate the 2822.From addresses  
signed by their "common man's" domain.

When large ISPs kick out a slew of 2822.From addresses that have not  
been validated, the DKIM signature added to these messages is of  
little value.  Bots!  Just the validation of the 2822.From would  
enable their customers to use their desired email-addresses while at  
the same time receive protection from any other customers within that  
signing domain from spoofing them, assuming the MUA has a way to  
annotate the message containing a signing-domain/email-address  
protection.  All their customers can still enjoying the freedom of  
being able to use their desired email-address after demonstrating its  
receipt.  This validation is a scheme used in millions of places  
represents improved security.

In section 3.3 of this "straw-man" draft:
http://www.sonic.net/~dougotis/dkim/draft-otis-dkim-dfsp-00.html:

-- "The Designated Signing for Address list is not intended to  
include more than a few domains. When more than a few domains are  
required, key/location methods of delegation should be used instead." --

This should be a good compromise.  Perhaps you want more however.

If someone wanted to associate tens of thousands of domains, this  
would still require just one lookup:

query (<domain-in-question>._dfsp._domainkey.<domain-of-from>, TXT)

which also returns a small record containing only a pertinent answer  
and not a long list.

This query is answered with a zone as follows:

  *._dfsp._domainkey.<domain-of-from>                    TXT v= 0.0  
a=domain-of-from;
  <domain-in-question>._dfsp._domainkey.<domain-of-from> TXT v= 0.0  
a=domain-in-question;

This is not a Turing complete language of redirects.  This uses a  
common utility within DNS.  This mode of operation is very common for  
doing block-list lookups of urls, and is used in this manner in many  
places.

> 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?

No. Assume there is a DKIM aware MUA that can note when a valid email- 
address has been found in the address book.  This mode of operation  
saves someone from having to ask "Is that really you Jim?  You would  
not want to enable an avenue for spoofing just for this luxury.

> includes a provider's public key or through delegation of a  
> subdomain to a provider, does not run into this problem.

Actually it does.  When this delegation does not occur and the  
2822.From domain does not match.  Getting a message with an identity  
of "i=@isp.com" is joyless.  You may not even know whether the  
@isp.com component of the email-address is to be trusted.

Yes there are problems with DNS and changes of conduct will be  
needed, but there are also solutions.  Opt for the exchange of public  
keys when setting up a relay.  They well need to poke you with new  
keys at some set of internals.  Perhaps you could use your existing  
key to decrypt the next to narrow the exposure when using this method.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 26 Aug 2006 00:44:55 +0100

> mailing list providers used by a domain might be delegated domains.  But

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?)

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

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

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

---

From: <[email-masked]>
Date: Fri, 25 Aug 2006 21:20:55 -0400

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-masked] 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 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

> If Designated Signing Domains become an accepted of delegating
authority

S.

---

From: Jim Fenton <[email-masked]>
Date: Fri, 25 Aug 2006 21:55:44 -0700

> this well. (Though we will decide it well of course.)
I have yet to see concrete examples of domains that would not easily be
able to do NS delegation or key-based delegation.  There seems to be an
assumption that it's easier for some domains to publish TXT records than
it is for them to publish NS records, but I haven't seen anything to
support this.

There is also an underlying assumption that SSP will be published using
TXT records, which has not been decided.  I believe there are good
reasons for using a new RR for this, even though this might be yet
harder for some domains to publish at first.
> single domain is very bad. Doesn't sound good though.
The 120 delegates using key delegation can easily have have their own
distinct keys.  They just sign with different selectors.  Nobody is
proposing doing key delegation using the same key, AFAIK.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Fri, 25 Aug 2006 21:56:18 -0700

512k??

-Jim

[email-masked] wrote:
>> Designated Signing Domains.  I'll break each category of concerns into
>>     
> a
>   
>> separate thread.]
>>
>> to sign messages, I'm concerned about the scaling characteristics of
>>     
> the
>   
>> mailing list providers used by a domain might be delegated domains.
>>     
> But
>   
>> let's not go there yet.
>>     
>
>> of these continuation records would be additive to the time required
>>     
> to
>   
>> evaluate the message.  Verifiers would also need to be prepared for
>>     
> the
>   
>> mailing lists?  Should mipassoc.org be included, even if we didn't
>>     
> know
>   
>> includes a provider's public key or through delegation of a subdomain
>>     
> to
>

---

From: "Hector Santos" <[email-masked]>
Date: Sat, 26 Aug 2006 06:42:46 -0400

----- Original Message -----
From: "Stephen Farrell" <[email-masked]>
To: "Jim Fenton" <[email-masked]>

> this well. (Though we will decide it well of course.)

+1.

I think anyone comtemplating DKIM (at this large magnitude of
a large enterprise with over 120 outsource mail distributors) will be more
than capable to decide how they will decide to use DKIM to fit their
operations.

I can also imagine someone (Alex) at the large enterprise "DKIM
Consideration" meeting asking:

    "Why are we doing this (considering DKIM) in the first place?"

I can also imagine, someone (Sally) replying:

    "Well, we just got this brochure from one of our outsource
     mail providers offering this new DKIM Signing Service. They
     claim it will help protect our mail, help stop spoofing and phishing
     and increase the acceptability rate by receivers and users.
     Maybe this will work for a few of our domains."

And Alex follows up:

    "But not all of our domains?  Are you suggesting that if this
     works, we can eliminate some of the providers and just go with
     this new DKIM ready provider?"

And Sally responds as she passes the brochure to Alex:

    "Maybe or just maybe get rid of 80% of them. Lunch Anyone?"

And Alex says after looking at the brochure:

    "Yeah sure, but it says here that we would have to designate
     them as the 3rd party signer for our domain mail. What about
     the others who don't sign?"

Then Sally responds:

    "I saw that. That is why we might want to create a new special
     domain for this 3rd party DKIM provider. But then again, this
     all optional.  We don't have to subscribe to there new signing
     service. It ain't free.  So we have to think about that too."

And then another software guy at the meeting (Tom) suggest:

    "Well, maybe we can just sign the mail outselves and not
     pay or allow anyone else to sign.  Can we do that?"

Sally responds:

    "Good question. Take this brochure Tom and call their
     Technical Sales rep and also research the IETF specifications
     and see if there are any  open source code available or 3rd
     party APIs.  Lets go to Lunch!"

Tom Grumbles to himself:

    "Oh man!! More WORK!! I don't get paid enough!"

So who knows how administrators and engineers or large companies will decide
how their 1 or 2 or thousands of domains will be used with DKIM or not or
just partially.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: <[email-masked]>
Date: Sat, 26 Aug 2006 08:46:05 -0400

It was late, the size of a udp packet

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: Jim Fenton [mailto:[email-masked]] 
Sent: Saturday, August 26, 2006 12:56 AM
To: Oxley, Bill (CCI-Atlanta)
Cc: [email-masked]; [email-masked]
Subject: Re: [ietf-dkim] Scalability concerns with Designated Signing
Domains

512k??

-Jim

---

From: "william(at)elan.net" <[email-masked]>
Date: Sat, 26 Aug 2006 08:18:50 -0700 (PDT)

I've proposed before that in case of large number of domains SPF-like
macro expansion be allowed in place of actual domain.

---

From: Douglas Otis <[email-masked]>
Date: Sat, 26 Aug 2006 08:41:42 -0700

> macro expansion be allowed in place of actual domain.

Bad idea and not needed.  To scale into the tens of thousands, just
prefix the queried domain above the policy label and use wildcards
within this isolated namespace to answer the query.  Zero macros are
required and the answer and the query remain small.

-Doug

---

From: Dave Crocker <[email-masked]>
Date: Mon, 28 Aug 2006 12:42:28 -0700

+1.

d/
-- 

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Mon, 28 Aug 2006 14:33:40 -0700

On Aug 28, 2006, at 12:42 PM, Dave Crocker wrote:

>
> Jim Fenton wrote:
>> I have yet to see concrete examples of domains that would not  
>> easily be able to do NS delegation or key-based delegation.  There  
>> seems to be an assumption that it's easier for some domains to  
>> publish TXT records than it is for them to publish NS records, but  
>> I haven't seen anything to support this.
>
> +1.

May I respectfully disagree.  The assumption of a designated domain  
being easier is indeed valid.

DNS delegation involves the domain owner, the email-service provider,  
and possibly their respective name-service providers.  The mail- 
service provider must then select the correct signing domain based  
upon the account used to gain access.  Any error made transcribing  
DNS related information will involve potentially two or three  
different entities.  Debugging a complex arrangement represents a  
scaling issue. (additional people required)

Any abuse related issues will likely be sent to the signing domain  
and not the email-service provider offering the outbound services.   
The email-service provider must be diligent at preventing abusive use  
of their IP addresses, but delegation may represent a disadvantage  
regarding oversight.  A significant amount of resources may be  
subsequently expended responding to situations where abuse warnings  
appeared to have been ignored.  Oversight is a scaling issue.  
(additional people required)

A designated signing domain would be a completely different  
situation.  This transaction would involve only the domain owner and  
their name-service provider. (no additional people required)

Any abuse would still be reported to the signing domain which better  
facilitates oversight. (no additional people required.)

Either effort only affects annotations placed upon the message.   
Designation should offer different annotations from that of a  
matching From/signing domain to allay security concerns.

-Doug