Subject: [ietf-dkim] What third-party ISP problem?

From: Mark Delany <[email-masked]>
Date: Thu, 3 Aug 2006 03:54:21 +0000

On Wed, Aug 02, 2006 at 08:02:54PM -0700, Dave Crocker allegedly wrote:

[Starting a new thread to focus on a one aspect]

> Outsourcing for mail sending is already common, so it seems likely that
> delegating signing would be, too.
> 
> But my question is why it is better to have a "delegation of my domain" scheme
> rather than simply having the outsourced sending do its own signature and then
> use its domain name for evaluating its own reputation.  If it is a Good Actor,
> then it shouldn't need to rely on the domain name of the content author.  If it
> is a Bad Actor, then relying on the domain name of the content author would
> merely wind up hurting the content author.

The point seems to be that there is a potential mis-match. Reputation
of content author != reputation of outsourced-sender, aka ISP.

One imagines that most small businesses fall into this category where
they have an impeccable record, yet their ISP is, by necessity, the
lowest-common-denominator of all their customers.

For example, is bbiw.net equal to, worse than or better than the ISP
it uses? Would you want the reputation of bbiw.net tied to your ISP or
would you rather stand on your own? And would your answer be the same
if your ISP was larger, say, Earthlink or AT&T or BT Internet?

But then I don't understand the great difficulty with "delegated
signing" in the first place.

Wheeling out my - admittedly dusty - ISP hat, I wonder why we need
third-party ISP signatures when an ISP can relatively easily generate
first-party signatures on behalf of their customer.

Thinking out aloud here, what if:

a) bbiw.net delegates _domainkey.bbiw.net to their ISP - typically
   that'll be a no-brainer as your ISP already runs your DNS content
   server. If not, add a couple of NS entries or a CNAME and you're
   done.

b) bbiw.net makes authenticated SUBMITs to their ISP

c) Based on the authenticated SUBMIT, the ISP picks a selector for the
   bbiw.net domain and signs on their behalf and generates a
   d=bbiw.net, etc.

The interesting thing is, depending on where SSP ends up, an ISP need
not even care about the various identities in the submitted email, ie,
2822.From, all it has to do is generate the d= based on the SUBMIT
authentication and let verifiers apply SSP to the content.

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

---

From: Dave Crocker <[email-masked]>
Date: Wed, 02 Aug 2006 21:24:40 -0700

> if your ISP was larger, say, Earthlink or AT&T or BT Internet?

If I used a skanky ISP, rather than the stellar songbird.com, how could my own
wonderful reputation overcome the awfulness of the reputation of my ISP?

In other words, I think that fate-sharing is inherent here, where two different
domain names can be identified.

>    server. If not, add a couple of NS entries or a CNAME and you're

John L pointed this out, privately, too.  What I think it highlights is that all
our focus on "third-party" signatures might be missing the boat (except maybe
for signatures from mailing lists, but let's hold that in abeyance for the
moment.)

A "delegated" signature is one that is done by an outsourced service, but it
uses the same (parent) domain as the rfc2822.From.  Hence, delegation is not at
all like "third-party" where the domain of the signature is different than the From.

> authentication and let verifiers apply SSP to the content.

Hmmm.  Sounds reasonable, although I find myself a little concerned about the
possibility -- or likelihood -- of independent operation of the ISP's MTA from
the 2822.From's domain entries. Certainly this is a coordination issue.

d/
-- 

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

---

From: John Levine <[email-masked]>
Date: 3 Aug 2006 14:46:42 -0000

>If I used a skanky ISP, rather than the stellar songbird.com, how
>could my own wonderful reputation overcome the awfulness of the
>reputation of my ISP?

Um, isn't the whole point of signature schemes like DKIM to apply the
authentication/reputation juju to the message itself and the signing
domain rather than to the path it took?

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Thu, 03 Aug 2006 07:53:12 -0700

>signing" in the first place.
What I've got out of this current discussion is the real problem is
with selector management.  If I want isp.com to run my mail with
their zillions of mta's, I as the customer am clearly not going to keep
my DNS in synch by hand -- some automation is some kind is clearly
needed.

>   server. If not, add a couple of NS entries or a CNAME and you're

NS delegation works for exactly one provider. This is probably just
fine for a pretty reasonable swath of small business, but it really
doesn't addresss the whole spectrum. For example, if I outsource my
mail to isp.com, I'm also pretty likely to outsource my email campaigns
to advertisomatic.com too. If I delegate the entire _domainkey subdomain
to isp.com, will they also set up the infrastructure to allow 
advertisomatic.com
also sign my mail? How would that work?

And I don't see how CNAME's would work: as far as I know, you can
only CNAME at a leaf which would be at the individual selector level.
That would make it rather problematic for a provider to retire/revoke a
selector, not to mention adding new selectors.

So *if* it could be done (which I am not convinced about), there seems
like there would be some advantage to do the indirection at the protocol
layer (eg, SSP) rather than at the DNS layer (eg NS).

       Mike

---

From: Dave Crocker <[email-masked]>
Date: Thu, 03 Aug 2006 08:14:19 -0700

Mark Delany wrote:
> On Wed, Aug 02, 2006 at 09:24:40PM -0700, Dave Crocker allegedly wrote:
> 
> Er, unless the ISP is truly skanky and abuses access to your DNS, then
> doesn't your email signed by your domain make the ISP irrelevant?

That certainly sounds reasonable, doesn't it?  However I find myself wondering
whether receive-side filtering really will ignore who I use as my operator.

So far, filtering efforts seem to try pretty hard to use as much information as
they can find, not as little.

In other words, I think that what we are talking about here is a paradigm change
for receive-side filtering.  But perhaps my assessment is not correct.

> Why would your ISP be identified and, even if it is, why would its
> signature, as a third-party, be more relevant than your signature, as
> a first party?

Some will do their own signature "just to be safe".  Certainly their IP address
will be obtained as it is now.

> Personally, if I see an inbound email with valid a first-party
> signature, the relaying ISP is pretty much irrelevant. You could send
> it via songbird, AT&T, Starbucks, hilton.com, who cares? Isn't that
> the point of DKIM?

Folks have been pretty cavalier about the idea that a message will have multiple
signatures, for whatever reason strikes the fancy of an (additional) signer.

I think this discussion suggests that extra signatures invites extra problems.
(Cliche: If you have one watch, you know what time it is; if you have two, you
are never quite sure.)

> Quite so. Your ISP is acting on your behalf but the ability of the
> verifier to discern that, strike me as a) hard and b) un-necessary.

Upon being stated, this seems pretty obvious.  However it has not been a clear
implication, to me, and I find myself suspecting that it has been missed by
others, too.  It strikes me as a rather important implication, in terms of what
we want to add to DKIM; or at least important for discussing DKIM usage.

> I may not understand your concerns exactly. The failure case is that
> your ISP uses your keys on behalf of another SUBMITTER.
...
> Point being that you have to get everything aligned for a first-party
> signature. 

Definitely true.  However my point was not a concern about ISP misbehavior, but
having the administrator of the ISP be different from the administrator of the
DNS entry that contains your DKIM information.  This falls under your statement
about alignment, but I think it is an operational scenario that needs to be
cited explicitly because it invites misalignment.

> To summarize, if your ISP can match up your authenticated submission
> with a key that they usually manage, then that ISP need never add
> third-party signatures and you get first-party signatures with no
> work.

Right.

d/
-- 

  Dave Crocker

---

From: Mark Delany <[email-masked]>
Date: Thu, 3 Aug 2006 15:30:03 +0000

> to advertisomatic.com too.

Right. I wasn't really trying to address the whole spectrum. The
suggestion is that the common case is not as hard as it seems some are
saying. More importantly, the common case need not involve third-party
signatures.

> layer (eg, SSP) rather than at the DNS layer (eg NS).

Sure, in this scenario you need a multi-indirection capability,
regardless of the technology you use. But is this saying anything more
than complex requirements require complex deployments?

The more general question I guess is how much do we want to get into
defining management mechanisms? Largely I'd think such things don't
require standardization and might benefit from a competitive
landscape.

Mark.

---

From: Mark Delany <[email-masked]>
Date: Thu, 3 Aug 2006 15:50:15 +0000

> will be obtained as it is now.

Which I think is the point. Filters already thrive on diversity, so
it's not clear to me that we will be able to impose much uniformity on
that front.

The only mandate I think we could possibly make towards uniformity is
if we said that signers MUST remove all existing signatures. If
verification ever allow the presence of multiple signatures, then
pretty much all bets are off as to how deployments will add
signatures.

Having said that. In the dim distant past we did talk about origin
signatures and relay signatures (or some such, I forget the exact
nomenclature for the moment). So I suppose if we can clearly
distinguish origin signatures from relay signatures, that might be
useful.

Mark.

---

From: Damon <[email-masked]>
Date: Thu, 3 Aug 2006 12:19:01 -0400

> distinguish origin signatures from relay signatures, that might be

Mark,

 I think the idea of distinguishing between originator signature and the
non-originator is very interesting. I see a technical issue with the
previous statement you made about removing all previous signatures and the
next statement. I am assuming that you would _never_ remove the originators
signature. So that would leave an outgoing relay looking for all the other
relays but not touching the originator. Sounds like a spot that a parser
could break the signing fairly easy.

Damon Sauer

---

From: Michael Thomas <[email-masked]>
Date: Thu, 03 Aug 2006 09:25:19 -0700

>saying. More importantly, the common case need not involve third-party
But do we really know if the common case really works for the common 
solution (ns)
that we're envisioning? You sign for a lot of domains, but do you really 
know
what other mailing services that your customers are using? If many/most 
are also
using outsourced third parties as well as your regular mail service, 
then that mail
will not have valid signatures until you provide an interface to publish 
their selectors.

>require standardization and might benefit from a competitive
I certainly don't want to get into that definition, but the question is 
whether
the deployment model is even plausible. Your opening up this management
interface for their _domainkey space strikes me as a pretty esoteric,
high cost/low gain kind of proposition from the service provider's 
standpoint.
Wouldn't it be better if there were a way for you to shift that burden 
back onto
your customers reasonably?

       Mike

---

From: Douglas Otis <[email-masked]>
Date: Thu, 3 Aug 2006 10:04:37 -0700

On Aug 3, 2006, at 9:25 AM, Michael Thomas wrote:

> Mark Delany wrote:
>
>>> NS delegation works for exactly one provider. This is probably  
>>> just fine for a pretty reasonable swath of small business, but it  
>>> really doesn't addresss the whole spectrum. For example, if I  
>>> outsource my mail to isp.com, I'm also pretty likely to outsource  
>>> my email campaigns to advertisomatic.com too.
>>
>> suggestion is that the common case is not as hard as it seems some  
>> are saying. More importantly, the common case need not involve  
>> third-party signatures.
>
> But do we really know if the common case really works for the  
> common solution (ns) that we're envisioning? You sign for a lot of  
> domains, but do you really know what other mailing services that  
> your customers are using? If many/most are also using outsourced  
> third parties as well as your regular mail service, then that mail  
> will not have valid signatures until you provide an interface to  
> publish their selectors.
>
>>> like there would be some advantage to do the indirection at the  
>>> protocol layer (eg, SSP) rather than at the DNS layer (eg NS).
>>
>> regardless of the technology you use. But is this saying anything  
>> more than complex requirements require complex deployments?
>>
>> The more general question I guess is how much do we want to get  
>> into defining management mechanisms? Largely I'd think such things  
>> don't require standardization and might benefit from a competitive  
>> landscape.
>
> I certainly don't want to get into that definition, but the  
> question is whether the deployment model is even plausible. Your  
> opening up this management interface for their _domainkey space  
> strikes me as a pretty esoteric, high cost/low gain kind of  
> proposition from the service provider's standpoint. Wouldn't it be  
> better if there were a way for you to shift that burden back onto  

Agreed.  A list of designated signing domains would be this  
mechanism.  All that would be required of the DKIM provider would be to:

1) Authenticate all accounts.

2) Verify reception of any From email-address used by these accounts.

Both 1 and 2 should rather simple.  Step 2 should represent  
essentially the same process as used to subscribe to a mailing list.   
Both of these are rather simple to automatically administer.  Neither  
of these steps will involve making DNS changes in order to satisfy  
their users.

The effort is moved to the user, where they can designate the DKIM  
provider that they use and also believe to be doing the right thing.   
This information then informs the recipients which identities might  
be trusted based upon assurances made by the signer and the policy of  
the From domain.

-Doug

---

From: Mark Delany <[email-masked]>
Date: Thu, 3 Aug 2006 14:35:35 +0000

However, if your ISP gets it right, that is they only use your
keys/selectors for your authenticated submission, then the failure
case is that your signature will be treated as a lesser third-party if
you choose to have a mis-matching 2822.From (or whatever SSP
anoints).

Point being that you have to get everything aligned for a first-party
signature. Any mis-alignment, apart for a buggy ISP, results in a
lesser, third-party signature.

Mark.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 3 Aug 2006 11:45:27 -0700

> distinguish origin signatures from relay signatures, that might be

This was reviewed in a draft:
http://www.sonic.net/~dougotis/id/draft-otis-dkim-options-00.html

The idea was to devise a scheme for retention of a minimal number of  
DKIM signatures.  The concern was related to DoS issues.  It used  
three roles, the MSA, Mediator, and MDA.  Rather than removing the  
signatures, it would overwrite the b= parameter.  Today, over-writing  
the first few characters of the bh= would be a better choice.

-Doug

---

From: John Levine <[email-masked]>
Date: 3 Aug 2006 21:23:05 -0000

>NS delegation works for exactly one provider.

Ahem, that's one provider per subdomain.  Why do you think that Orbitz
sends their newsletters from email.orbitz.com?

>And I don't see how CNAME's would work

I agree, they're only useful for planting an alias if some leaf's name
changes.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Fri, 04 Aug 2006 07:52:32 -0700

>sends their newsletters from email.orbitz.com?

True, but when discussing this there seems to be some not-small faction
who hate using subdomains. Maybe they'll just get over it, but iirc there
was more than just aesthetics involved.

       Mike

---

From: John L <[email-masked]>
Date: Fri, 4 Aug 2006 11:04:17 -0400 (EDT)

> was more than just aesthetics involved.

I observe that significant mailers delegate subdomains to their 
contractors now for DK signing, so whatever problems people are worried 
about don't seem to occur in practice.  I think that counts as running 
code.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://johnlevine.com, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html