Subject: [ietf-dkim] Another take on "all email from us is dkim signed"

From: Steve Atkins <[email-masked]>
Date: Wed, 11 Mar 2009 12:33:45 -0700

It seems to me that the domains likely to benefit from the ability to  
state "All email we send is DKIM signed" share a few things in common.

   1. They're concerned about other people sending email claiming to  
be "from" the domain.

   2. They send email using the domain to, typically, a large number  
of B2C recipients (excluding the null assertion "we send no email",  
which can be handled in other ways)

   3. All the email they send is DKIM signed.

   4. They primarily care about mail appearing to be "from" their  
domain being sent to users who also legitimately receive real email  
from them.

It also seems that the number of domains who want this will likely be  
a small fraction of the total number of domains, and likely a small  
fraction of the number of emails sent.

The combination of 2, 3 and 4 means that any receiving ISP that  
receives "forged" email that the domain cares about will also receive  
legitimate email from that domain.

If there were another field in the DKIM-Signature header, or an  
entirely separate email header covered by the DKIM signature, that  
stated "all email sent using this domain in the From field will be  
DKIM signed" then any receiving MTA or MTA cluster could keep track of  
that state (probably using their existing reputation tracking system  
in the case of large receivers, and using a fairly trivial extension  
to their DKIM plugins in the case of smaller ones).

That would provide all the benefit of ADSP to senders who want it,  
without adding a per-email latency overhead for receivers who want to  
support it, at the cost of a keeping a fairly small amount of state at  
the receiving MTA.

(Other information could be communicated in-band in the same way -  
including "we're no longer dkim signing every email sent").

Did we already look at this idea and discard it before we settled on  
using a DNS query for every email received?

Cheers,
   Steve

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

---

From: HLS <[email-masked]>
Date: Wed, 11 Mar 2009 16:05:27 -0400

> using a DNS query for every email received?

Discussed, not discarded.  AFAIR,  the general feeling is that Lookups are
cheap today.

As defined by the SSP design requirements, the guideline is that policy
lookup is only required for an invalid or no signature inbound scenario.
 The Threats Analysis provided the universal agreement among all pro and con
policy people that a valid 1st party signature does not require a policy
lookup.

The complexity was the authorization of 3rd party signatures, which I though
was removed with ADSP reduction to 1st party considerations only.

But as was expected, you could not entirely do away and remove the idea,
hence you have the mess that is going on now with i=.

-- 
hls

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 11 Mar 2009 16:20:28 -0400

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Steve Atkins
> Sent: Wednesday, March 11, 2009 3:34 PM
> To: ietf-dkim WG
> Subject: [ietf-dkim] Another take on "all email from us is dkim
signed"
> which can be handled in other ways)

I would not exclude B2B out of hand. Many financial institutions
communicate with business customers. I would also point to this example
http://www.webpronews.com/topnews/2007/10/31/grocery-store-falls-for-10-
million-phishing-scam as to why businesses might want to assert that all
their B2B mail is signed.

Which other ways would you assert "we send no mail" to protect the
RFC2822 From email address?

> fraction of the number of emails sent.

That may be true today but may not be true tomorrow. 

> legitimate email from that domain.

Perhaps, perhaps not. There is also the case of an ISP receiving
fraudulent email prior to receiving legitimate email (race condition).

> including "we're no longer dkim signing every email sent").

Why not include both options (trying to be flexible here)? If one looks
at Daves affilias proposal, some receivers might choose to check for
ADSP records against some arbitrary list of domains (all registered
financial institutions for example). 

> using a DNS query for every email received?

It was discussed at one point.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 11 Mar 2009 13:26:06 -0700

> to their DKIM plugins in the case of smaller ones).

   If nothing else, this would make revocation sort of... bizarre
   and unpredictable. The implication is that I'd have to send $you
   mail (for $you == 'universe') to get you to nuke my record in your
   database. Of course every good protocol becomes a control protocol
   for others, but still this seems a little whacked even by that
   standard :)

		Mike

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 11 Mar 2009 16:30:32 -0400

> [email-masked]] On Behalf Of Michael Thomas
> Sent: Wednesday, March 11, 2009 4:26 PM
> To: Steve Atkins
> Cc: ietf-dkim WG
> Subject: Re: [ietf-dkim] Another take on "all email from us is dkim
> signed"
> 
> Steve Atkins wrote:

Well, I suppose we could always include a TTL in the tag <G>.

Mike

---

From: Steve Atkins <[email-masked]>
Date: Wed, 11 Mar 2009 13:31:08 -0700

On Mar 11, 2009, at 1:26 PM, Michael Thomas wrote:

>> DKIM signed" then any receiving MTA or MTA cluster could keep track  
>> of  that state (probably using their existing reputation tracking  
>> system  in the case of large receivers, and using a fairly trivial  
>> extension  to their DKIM plugins in the case of smaller ones).
>

The only affect of the record is to reject mail that claims to be from
me. If I never send you legitimate email then it'll never be an issue.
If I send you legitimate email that's DKIM signed, then that includes
the revocation.

I'd presume there'd be some sort of TTL included, probably in the
2-13 month sort of timescale. So you'd just have to keep signing all
your outbound email with DKIM for a little longer than that TTL.

Cheers,
   Steve

---

From: Steve Atkins <[email-masked]>
Date: Wed, 11 Mar 2009 13:35:30 -0700

> their B2B mail is signed.

The same reasoning applies to B2B email.

> RFC2822 From email address?

SPF is the obvious solution. MX 0 . is another.

However, given the supposed threat is phishing, "we send no email"
is mostly a red herring.

> fraudulent email prior to receiving legitimate email (race condition).

If the threat is phishing, this is very unlikely. Phishing is pretending
to be an existing brand. If the existing brand is already in use then
it's very likely that there's going to be at least one existing user at
an ISP. It would also be very easy to setup your business model
such that you can ensure that every user has received at least
one legitimate email from you before they are in the situation
where they are at any risk of phishing. Sending them an email
with their username in it, for example.

If the threat is not phishing, then we need to be explicit about what
the threat is before judging how different approaches affect it.

>> of

If there's a third party list then this, and ADSP, are entirely  
irrelevant.

This, and ADSP, address the specific use case where senders
believe there should be no such third party list and that they should
be able to self-publish the information.

That doesn't mean that they couldn't both be used, just that they
shouldn't be conflated.

Cheers,
   Steve

---

From: Michael Thomas <[email-masked]>
Date: Wed, 11 Mar 2009 13:36:39 -0700

> Well, I suppose we could always include a TTL in the tag <G>.

   Yes, but then you'd have to continuously deal with domains that you
   send to TTL+dt being unprotected, which would be pretty easy
   for an attacker to exploit. The implications of policy+push is
   flood fill. Not a happy implication, IMO.
	
		Mike

---

From: HLS <[email-masked]>
Date: Wed, 11 Mar 2009 16:38:06 -0400

> to their DKIM plugins in the case of smaller ones).

This was touched upon back in 2007/2008 holidays with a WG suggestion to add
a DKIM-Signature tag thats says *first party only, neutral, etc* which can
be viewed as an optimization.

I think it is a great idea.  But the issue is legacy mail.   The issue is
not the good mail. The issue is the bad mail - the one that don't have the
"extra" DNA genes to detect.

---

From: Steve Atkins <[email-masked]>
Date: Wed, 11 Mar 2009 13:41:26 -0700

On Mar 11, 2009, at 1:38 PM, HLS wrote:

>
>
> On Wed, Mar 11, 2009 at 3:33 PM, Steve Atkins  
> <[email-masked]> wrote:
>
> This was touched upon back in 2007/2008 holidays with a WG  
> suggestion to add a DKIM-Signature tag thats says *first party only,  
> neutral, etc* which can be viewed as an optimization.
>
> I think it is a great idea.  But the issue is legacy mail.   The  
> issue is not the good mail. The issue is the bad mail - the one that  
> don't have the "extra" DNA genes to detect.

If the flaw is bad mail being sent to recipients who have never  
received good mail, what's the threat that's being defended against?

Cheers,
   Steve

---

From: HLS <[email-masked]>
Date: Wed, 11 Mar 2009 16:42:43 -0400

On Wed, Mar 11, 2009 at 4:33 PM, Mark Delany
<[email-masked]<[email-masked]>
> wrote:

> Essentially such an approach is asking every MX target with more than one
> system to invent some way of distributing the knowledge it discovers on an
> inbound, signed message.
> You also have to invent mechanisms to deal with corner cases and timing
> windows, such as when one MX target receives a "we don't sign all anymore"
> and another MX target for the same domain almost immediately receives an
> unsigned email from that domain. Or what if you use your ISP as a secondary
> MX and the "state changing emails" happened to be queued up there for a
> while?
>
> I also don't see how it changes anything from a functional POV. If ADSP is
> carried in the signature vs carried in a DNS record, it would presumably
> invoke the same level of WG discussion over semantics and purpose.
>
> Given the highly cacheable nature of ADSP information and the fact that
> we're already querying the DNS for key information, it's unclear what the
> big benefit would be in moving this in-band.
>

Outside of DNS query related technical issues,  the first
operational repercussion is  the lost of handling legacy mail.   We need to
use an "standard anchor" something we know will always be there, which as it
is now, is the From: domain lookup.

---

From: Mark Delany <[email-masked]>
Date: Wed, 11 Mar 2009 13:33:54 -0700

> Discussed, not discarded.  AFAIR,  the general feeling is that  
> Lookups are cheap today.
>

Essentially such an approach is asking every MX target with more than  
one system to invent some way of distributing the knowledge it  
discovers on an inbound, signed message.

You also have to invent mechanisms to deal with corner cases and  
timing windows, such as when one MX target receives a "we don't sign  
all anymore" and another MX target for the same domain almost  
immediately receives an unsigned email from that domain. Or what if  
you use your ISP as a secondary MX and the "state changing emails"  
happened to be queued up there for a while?

I also don't see how it changes anything from a functional POV. If  
ADSP is carried in the signature vs carried in a DNS record, it would  
presumably invoke the same level of WG discussion over semantics and  
purpose.

Given the highly cacheable nature of ADSP information and the fact  
that we're already querying the DNS for key information, it's unclear  
what the big benefit would be in moving this in-band.

Mark.

---

From: HLS <[email-masked]>
Date: Wed, 11 Mar 2009 17:11:39 -0400

On Wed, Mar 11, 2009 at 4:53 PM, Mark Delany
<[email-masked]<[email-masked]>

> Outside of DNS query related technical issues,  the first operational
>> repercussion is  the lost of handling legacy mail.   We need to use an
>> "standard anchor" something we know will always be there, which as it is
>> now, is the From: domain lookup.
>>
>>
> For those subset of folk who want to do that, nothing stops you storing the
> ADSP query result with the email when you write it to your local disk. Your
> disk, your rules.

Right, and also which was Fenton's points out in regard to dns caching
currently employed - you define your timeouts on your DNS records hence
there would be local dns client caching.

My only come back there (a minor one) is that the DNS client API used
defines how that caching will be done, if any.  So sure, the receiver should
probably keep in mind the possible need to do its own caching.

Overall, I don't think this part is an non-issue and as was pointed out by
some, many receivers are already doing all kinds of lookups, SPF, RBL,
SENDERID, etc.  It would be a dream to have one universal lookup that covers
all, nonetheless, that is not the case and an additional ADSP should not be
an issue.

> Besideswhich, since only signed mail could legitimately contain the "I
> don't sign everything anymore" you'll have to somehow track that across to
> unsigned emails when you store them or maintain a state change history per
> domain so you can correctly analyze unsigned legacy mail.
>

+1.  IIR, this was all covered.  Caching is a plus in all this.

---

From: Mark Delany <[email-masked]>
Date: Wed, 11 Mar 2009 13:53:08 -0700

> operational repercussion is  the lost of handling legacy mail.   We  
> need to use an "standard anchor" something we know will always be  
> there, which as it is now, is the From: domain lookup.
>

For those subset of folk who want to do that, nothing stops you  
storing the ADSP query result with the email when you write it to your  
local disk. Your disk, your rules.

Besideswhich, since only signed mail could legitimately contain the "I  
don't sign everything anymore" you'll have to somehow track that  
across to unsigned emails when you store them or maintain a state  
change history per domain so you can correctly analyze unsigned legacy  
mail.

Mark.

---

From: HLS <[email-masked]>
Date: Wed, 11 Mar 2009 18:02:34 -0400

> received good mail, what's the threat that's being defended against?

Bad mail?

Caching and recording is good.  But what if you never saw this before and
 don't have information recorded?

An example:

corp.xyz.com is a company that would like to do online commerce or billing
with their customers (B2U).  A rare market scenario <g>

They use "customer-support.xyz.com" as a special 2822.From address in all
their correspondence to their user base.

Pre-DKIM:  Legacy mail

   From:  [email-masked]
   To: layman_user @ someisp.com

As we know, this is subject to spoofing and phishing.  There are
indeterminate results that simply ends up getting  passed to the users.  I
think we can all agree this one the motives and reasons why we are here.

DKIM: 1st party signature

   DKIM-Signature: d=customer-support.xyz.com
   From:  [email-masked]
   To: layman_user @ someisp.com

And a ADSP DKIM=DISCARDABLE record is available.

Now, with immediate short-term and long term benefits, this company will be
protected at all ADSP compliant receivers.  No more or a greatly diminished
 legacy spoofing problem for this domain.  Domains, receivers and users
benefits.

So the concern is, "is this too much DNS overhead?"

Well, we already covered two aspects for optimization per SSP design
requirements guide and the TA (threats analysis) guide.

  1) Valid 1st party signatures do no not policy lookups.
  2) Only with no signatures (invalid), is ASDP recommended.

This is where the issue regarding the 4871 "Failure = No Signature" comes to
play  Not trying to rehash it. Just analyzing it from an implementation
standpoint:

For #2 above, it means two things:

2) Only with no signatures (invalid), is ASDP recommended.

   2.1 No (physical) signature exist
   2.2. An failure signature promoted to no signature.

Well, the in-band policy tag idea will only work for 2.2 and in this vain, I
think it is a good idea as we move into the long term operations of
DKIM/ADSP.

But you still need to deal with 2.1 when there is no recording information,
no signature.  This is the only way to protect corp.xyz.com with its
vendor/user communications.

The idea discussed is that this ADSP policy would need to be duplicated in
the DKIM-SIGNATURE as an optimized long term operation.

Jim Fenton pointed out that this is good, but it may further complex DNS
key/policy management.

---

From: Hector Santos <[email-masked]>
Date: Wed, 11 Mar 2009 19:07:54 -0400

> That may be true today but may not be true tomorrow. 

Besides the fact you can't design a public protocol starting with a 
discrimination model, all must be applied using the same public 
protocol, same rules, whether its true or not, this may be exactly the 
segment of people who will benefit the most from DKIM+POLICY.

But even then, the BIGGER domains are also needing protection.

Gmail.com sends millions of messages per day now signed when you are 
on GMAIL.COM.

I can use the same gmail.com junk mail account across other sites and 
I do so very very loosly because I don't care - its a junk address.

So GMAIL.COM, in my view, as a public free service email model does 
not benefit with ADSP for their branded domain because its potential 
is high for a "Cry Wolf" effect - high potential for failure at 
receivers, hence receivers will have a tendency of ignoring it.

But there are people and companies that use Google Apps seriously and 
their gmail.com is important to them.

Now, there is another solution that the Google developer mindset might 
consider in the area of WEB SERVICES.   Each gmail user can have its 
own LOOKUP policy setting

     [X] I only use GMAIL Online to create mail. Never outside.

Now GOOGLE can publish a REST web server user DKIM lookup protocol 
that is not DNS based. The have tons of REST web service user lookup 
functions already so this one would be a simply addition.  This will 
allow receivers who get email from a  purported GMAIL.COM account to 
support what I would call:

      GUSP (GMail User Signing Policy) Protocol.

      http://gusp.gmail.com?user=xxxxxxxx

It can be done as a fast SMTP callout and the call response will be 
200 (GMAIL_ONLY) or (403) OPEN and certainly, the receiver can cache 
this for some TTL.

Now all receivers will be able to protect GMAIL.COM accounts, 
disseminate the junk spoofing that is rampant today for all these free 
ESP domains.

So get busy google and write that GUSP I-D! and get a leg up on their 
competitives!  Add value to GMAIL.COM commercial usage with DKIM/GUSP 
protection.

> financial institutions for example). 

No public standard protocol will work well if its done on a 
discriminatory basis.  Some group will be hurt by this way of 
designing a protocol and history has shown that when you intentional 
neglect something believe it will have a low impact, it is among the 
first things that is exploited.

-- 
Sincerely

Hector Santos
http://www.santronics.com

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Thu, 12 Mar 2009 09:48:33 -0400

> Sent: Wednesday, March 11, 2009 4:36 PM
> To: ietf-dkim WG
> SPF is the obvious solution. MX 0 . is another.

There are a number of issues in using SPF in the manner you suggest. The
first is that SPF is path based. It basically says "here are the hosts
authorized to send mail for this domain" (transport layer). The RFC2822
>From is data, not transport layer. This is exactly the complaint against
Microsoft/Sender-ID when they decided to misuse SPFv1 records for PRA
evaluation.

SPF protects the transport layer Mail From and EHLO. For most
implementations I'm aware of the intent and practice is to reject at
EHLO or reject on Mail From. At this point the RFC2822 From is not
available for checking. If a receiver has already checked

> with their username in it, for example.

A brand can have brand recognition without an individual (or receiving
domain) having received an email from that domain before. Take the
domain ibm.com. How many people are familiar with IBM as a
company/brand? How many people know that IBM never sends email from the
primary domain ibm.com? So how many receivers have received an email
from ibm.com? (the correct answer is none).

Consider the cases of Facebook, MySpace, and LinkedIn. Many
people/receivers were aware of the brands long before they received an
email from those brands. So, how would individuals/receivers know a
priori what the characteristics of a legitimate email from those brands
are or what a legitimate email from those brands should look like?

> the threat is before judging how different approaches affect it.

I've been talking about phishing. What other threats would you like to
throw into the fire?
> If there's a third party list then this, and ADSP, are entirely

Not at all. Before DKIM signing becomes universal (Mike starts singing
"that'll be the day"), receivers may choose to use various approaches to
authenticating domains and validating the nature of those domains. For
example, BITS has stated (and indicated specific time frames) for
members (financial institutions) to implement SPF and DKIM signing.
Therefore, a receiver may choose to look at a list of members provided
by BITS after the compliance date as a means of knowing that mail
purporting to be from these member institutions should have an ADSP
record. In this case ADSP is NOT irrelevant. Determining that a domain
SHOULD have an ADSP record does not tell us what that ADSP record
contains.

> That doesn't mean that they couldn't both be used, just that they

No conflation here.