Subject: Re: [ietf-dkim] Delegated signatures in real life

From: Scott Kitterman <[email-masked]>
Date: Wed, 30 Aug 2006 12:18 -0400

On 30 Aug 2006 14:28:29 -0000 John Levine <[email-masked]> wrote:
>>In addition, I would also note that it is extremely easy in a group like 
>>this to lose track of how non-technical many domain owners are today. 
>
>Right, and that means that they use someone else to provide their
>mail service.

Exactly.  Odds are, not the same provider that does their DNS.  They are in 
the middle.  

>Keep in mind that DKIM, unlike SPF, requires the active participation
>of whoever runs your outgoing mail server to apply signatures, unless
>you are enough of a weenie to run a signing engine in your MUA and do
>your own key management.  For the vast majority of non-technical
>users, their ISP or hosting company's MTA will apply its own
>signature, and that will be good enough.  Indeed, it will probably be
>better than a tiny domain's own signature, since whatever formal or
>informal reputation systems recipients use are much more likely to
>have entries for the ISP than for a tiny domain that sends 12 messages
>a week.

That sounds to me like you are saying that DKIM first party signing is only 
for big domains.  If that's the WG consensus, then that's what we should 
design to, but I hope not.  I have said before that I think scalable works 
two ways.  It has to scale small too.

I also think that you underestimate the scalability of the proprietary 
reptation vendors.  Mail servers get their IP address into, for example 
Ironport's Senderbase, such systems after having sent just a handful of 
messages.  I doubt name based systems will be less granular.

Let's not do another round of should reputation accrue based on the 
author's domain or the MTA operator's domain.  I, for one, think that, 
"You're little, third party is good enough for you" is not the right answer.

>I suppose it is hypothetically possible that providers will upgrade
>their MTAs to support per-domain DKIM signing and out of perverse
>hostility won't offer the DNS support for it.  That has never
>impressed me as a scenario likely enough to be worth inventing a new
>mechanism with unknown security problems that has to be implemented by
>all DKIM recipients.

It's fortunate then that that isn't the scenario I'm trying to support.  
The likely scenario is the outsouced MTA and DNS are provided via different 
companies.  I think MTA from the ISP and DNS from a name registrar is 
entirely typical.

At this point I'm not suggesting an alternative.  My point is that NS 
subdomain delegation is not sufficient by itself.

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

---

From: John Levine <[email-masked]>
Date: 30 Aug 2006 19:38:58 -0000

>for big domains.

No, I'm saying that the anyone who wants to sign their mail with their
own domain can do so.  If you want to delegate that to a service
bureau, we have working examples today of domains using NS delegation
to outsource their mail including DK signing.  Even if you are too
cheap to use a DNS service that lets you put in NS records, your can
get much the same effect by having your mail service make up your
keys, send you CNAME or TXT records, and you cut and paste them into
your zone, not unlike the way that you help people to put in SPF
records.

>"You're little, third party is good enough for you" is not the right answer.

Actually, what I was saying is "you're little, your ISP's signature is
the one that matters."  I host a bunch of little domains, and I expect
to sign all of their mail with my own somewhat better known domain.  I
should be able to sign the mail of people who want with their own
domain, probably at modest extra cost, but I doubt many will ask.

>subdomain delegation is not sufficient by itself.

If I understand your position, you are positing that someone will pay
between $20 and $50/mo for Internet access, probably some extra amount
per month for a DKIM-capable mail service, but they use a crummy DNS
service where they don't know how to put in NS records, and the $2/mo
it would cost to switch to a DNS service that does support them is an
insurmountable barrier.  Maybe I'm getting hard hearted in my old age,
but pleas of selective ineptness or selective poverty do not make a
compelling argument for anything.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Wed, 30 Aug 2006 13:24:57 -0700

John Levine wrote:
> service where they don't know how to put in NS records, 

And... Even if this scenario is correct, it does not warrant adding an 
entire layer of security mechanism into DKIM.

d/

-- 

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

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 30 Aug 2006 13:32:32 -0700 (PDT)

> entire layer of security mechanism into DKIM.

Not "into" - on-top of or as supplement. And for specific type of
email identity security protection.

And not that it matters (ok it does, but its off-topic for WG list)
but accreditation and reputation services are also not built "into"
but are an additional layer above the base.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Wed, 30 Aug 2006 15:17:13 -0700

On Aug 30, 2006, at 12:38 PM, John Levine wrote:

> If I understand your position, you are positing that someone will  
> pay between $20 and $50/mo for Internet access, probably some extra  
> amount per month for a DKIM-capable mail service, but they use a  
> crummy DNS service where they don't know how to put in NS records,  
> and the $2/mo it would cost to switch to a DNS service that does  
> support them is an insurmountable barrier.  Maybe I'm getting hard  
> hearted in my old age, but pleas of selective ineptness or  
> selective poverty do not make a compelling argument for anything.

Why sign a message when the signature is never seen by the  
recipient?  In all likelihood, a valid signature not matching the  
address in question will not receive any positive annotations,  
especially from a large domain.

Assume you are right about the majority not wanting to coordinate  
with their email-provider, convey a set of moderately complex details  
to their name service provider, and then hope their mail continues to  
work.  When either name-service-provider, or the domain owner makes  
an error transcribing a detail, it is likely the email-service  
provider who will need to sort out what went wrong.  This will  
require support staff (your time) to deal with configuration issues  
when someone makes a mistake.  In addition, all of your accounts now  
must carefully track who uses what keys.

The many ways that this can be done, is a problem in itself.  Even  
within this group, it is difficult for anyone to predict what the  
other may want, and where it might be placed within the namespace.   
As a result of these issues, this service will cost more per month.   
The question "Why did we want DKIM?" might come many people's mind.

Some might suggest so Eliot's dad knows when Eliot is telling him to  
buy shares in Petroleum International stock, or load a player for the  
latest video from Paris.  Social relationships are exposed in many  
ways, perhaps by promotions offering free music downloads when you  
tell a friend, or by mailing lists like this one.  The majority  
remains prone to social spoofing.  Some might call it spear phishing,  
but it is worse.  There is little that is more compelling than being  
told by a friend to try something that is really exciting or funny.

Ensuring your email-address is within the signing domain is not  
really the end of the story either.  Is everyone else within this  
domain trustworthy?  Is there a way for a recipient to know whether  
anyone within the domain can also use this address, and which domain  
is actually doing the signing and validating of the email-address.   
It is not good to have these details hidden.  It would be better for  
the message annotations to indicate who is doing what for whom, and  
whether they said it was okay.

Imagine that you want to raise some money to fund those foreign  
exchanges students, but you don't want to deal with telling everyone  
how to setup their DNS, so you offer to sign messages is a "special"  
way. : )

Your premium service now asserts the email address has been  
"validated" (when it has been of course).  Along with their assigned  
address within the domain, you asked for a secondary contact address  
that you happen to also validate.  As part of this service they can  
also request inclusion of a limited number of other addresses.  It  
does not matter whether the address is within in your domain.

To allow this to work, a special signature is needed to be able to  
assert (for any address domain) the email-address is valid.  Alas  
that is missing from DKIM at this time, but assume it does exist.   
Eliot knows that he can trust your service, and signs up the moment  
he hears about it.  To allow his dad to know that he is using your  
service, Eliot puts your domain name into the policy of his vanity  
email-address, [email-masked].  _dfsp._domainkey.at-large.com IN  
TXT "v=0.0; f=A; a=taugh.com:at-large.com;"

Eliot's dad's MUA knows all about DKIM and this new special way of  
asserting a valid address.  The MUA notices Eliot's email-address is  
in the address book.  It then checks the policy record.  When the  
policy indicates taugh.com signs for at-large.com, the signature is  
then checked.  Because the signing domain was in the policy "a="  
list, the MUA also knows that the message is valid when asserted  
"valid" with this new and special Inter-Domain assertion.  A gold  
star is then placed next Eliot's email-address allowing his dad to  
know it was from him.  Eliot did not having to explain to his dad all  
about how trustworthy John Levine is at taugh.com and where to look  
in the raw headers for taugh.com.

-Doug

---

From: [email-masked] (Wietse Venema)
Date: Wed, 30 Aug 2006 18:57:42 -0400 (EDT)

> email identity security protection.

This would be a required component for all DKIM signature verifiers,
because there is no point building verifiers that can't verify all
valid signatures.

Let's not re-invent the wheel. DNS already provides delegation of
leaf nodes (CNAME) and interior nodes (NS). It already works. People
who are unhappy with their DNS service can vote with their wallet.

	Wietse

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 31 Aug 2006 07:03:44 -0700 (PDT)

> because there is no point building verifiers that can't verify all

A policy described in separate record and use of which is described
in separate document RFC is a required component for those who only
want to do base verifier? Who said that?

Chairs - please step up! Please clarify for everyone what the
relation between documents and requirement for implementers would be.

> who are unhappy with their DNS service can vote with their wallet.

People who want to do CNAME and NS delegation to allow somebody to
sign with their domain in 'd' are all still be free to do so.

But let me repeat what I said before - not everyone can or would
want do that noth only because of how their dns is hosted but simply
because it requires coordination between them and signing system.
Added to that not everyone wants outside signing system (i.e. 3rd
party) putting signature without taking some responsibility for email
that is more like it is really coming from them (i.e. mail lists).

So you loose nothing but gain number of additional uses and making
it easier for more domains to claim they have all their emails signed.

---
William Leibzon
Elan Networks
[email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 31 Aug 2006 15:18:06 +0100

> relation between documents and requirement for implementers would be.

Since base has no normative reference to ssp then there is no
requirement to implement ssp for conformance with base.

Nothing to do with being a chair that - the lack of the
normative reference says it all (as a quick read of the document
should make clear).

S.

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 31 Aug 2006 10:48:02 -0400

----- Original Message -----
From: "Stephen Farrell" <[email-masked]>
To: "william(at)elan.net" <[email-masked]>

> normative reference says it all (as a quick read of the document

At the risk of being in the wrong position here, you do have the tie in with
the TA document with pretty profound statements:

3.2.  Use of Specific Identities

   ....

   DKIM is effective against the use of specific identities only when
   there is an expectation that such messages will, in fact, be signed.
   The primary means for establishing this is the use of Sender Signing
   Practices (SSP)[I-D.allman-dkim-ssp].

4.  Attacks on Message Signing

   Bad actors can be expected to exploit all of the limitations of
   message authentication systems.  They are also likely to be motivated
   to degrade the usefulness of message authentication systems in order
   to hinder their deployment.  Both the signature mechanism itself and
   declarations made regarding use of message signatures (referred to
   here as Sender Signing Policy, Sender Signing Practices or SSP, as
   described in [I-D.ietf-dkim-base] ) can be expected to be the target
   of attacks.

Plus to other references in 4.0 sub-sections indicating how SSP can be
abused and also subdue attacks.

5.  Derived Requirements

   This section lists requirements for DKIM not explicitly stated in the
   above discussion.  These requirements include:

      The store for key and SSP records must be capable of utilizing
      multiple geographically-dispersed servers.

      Key and SSP records must be cacheable, either by the verifier
      requesting them or by other infrastructure.

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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 31 Aug 2006 16:09:44 +0100

> the TA document with pretty profound statements:

This is quite clear. Base does NOT REQUIRE SSP.

That doesn't stop anyone who implements a DKIM-verifier from using SSP
in as a enthusiastic manner as they like.

Stephen.

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 31 Aug 2006 11:19:27 -0400

----- Original Message -----
From: "Stephen Farrell" <[email-masked]>
To: "Hector Santos" <[email-masked]>

> This is quite clear. Base does NOT REQUIRE SSP.

No doubt. It is made quite clear.

> That doesn't stop anyone who implements a DKIM-verifier from
> using SSP in as a enthusiastic manner as they like.

Or more importantly, DKIM-SIGNERS who may also read the TA document in their
research to see "how safe this is" and see they might need something SSP.

---

From: <[email-masked]>
Date: Thu, 31 Aug 2006 11:33:51 -0400

My reading of base, states that the d= is signing domain, nothing in
base requires the signer to be a node of the from domain. Which in my
case is a good reason to only use base.
Thanks,

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

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of william(at)elan.net
Sent: Thursday, August 31, 2006 10:04 AM
To: Wietse Venema
Cc: [email-masked]
Subject: Re: [ietf-dkim] Delegated signatures in real life

>>>> If I understand your position, you are positing that someone will
pay

---
William Leibzon
Elan Networks
[email-masked]

---

From: [email-masked] (Wietse Venema)
Date: Thu, 31 Aug 2006 11:48:42 -0400 (EDT)

> want to do base verifier? Who said that?

This thread was about the delegation of the DKIM signing operation
including the delegation of DKIM public key information. Whatever
delegation methods are used (DNS or other), they would have to be
built into DKIM verifiers.

This is different from a third-party DKIM scenario with a policy
that says "domain X signs all mail from domain Y".  That is not
delegation in the sense of the previous paragraph, and that does
not affect verifiers.
 
        Wietse

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 31 Aug 2006 10:28:05 -0700 (PDT)

> built into DKIM verifiers.

My apologies. With so many emails on this list lately its hard
to keep track and I was expecting that all current topics of
discussions would have to do with SSP.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 31 Aug 2006 12:54:12 -0700

> delegation in the sense of the previous paragraph, and that does  

It be clear you could have said domain Y policy.  I agree this is not  
delegation that affects verifiers.  This poly would affect message  
handling either preceding or subsequent to signature verification.

-Doug