Subject: RE: [ietf-dkim] user level ssp

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 6 Sep 2006 10:45:38 -0700

The main value I see in user level policy is easing phased deployment. If you are a bank with 100,000 employees with email and you want to deploy DKIM you probably want some form of hook that lets you do it in stages. 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Michael Thomas
> Sent: Wednesday, September 06, 2006 1:15 PM
> To: IETF-DKIM
> Subject: [ietf-dkim] user level ssp
> 
> 
> All of this talk about additional requirements for user level 
> ssp ignores the basic question: should there be any 
> requirements for user level SSP at all? If so, what are the 
> use cases? I'm not terribly convinced that even that has 
> consensus -- this is the first that I even recall the subject 
> being raised.
> 
>        Mike
> _______________________________________________
> 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

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 06 Sep 2006 13:47:34 -0700

On 2006-09-06 10:45, Hallam-Baker, Phillip wrote:

> The main value I see in user level policy is easing phased
> deployment. If you are a bank with 100,000 employees with email and
> you want to deploy DKIM you probably want some form of hook that lets
> you do it in stages.

So they'll have 100,000 SSP records?

Perhaps there's an easier, more flexible, more scalable hook...like "we 
don't sign all mail."

-- 
J.D. Falk, Anti-Spam Product Manager
Yahoo! Communications Platform Team
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jim Fenton <[email-masked]>
Date: Wed, 06 Sep 2006 15:44:14 -0700

J.D. Falk wrote:
> Perhaps there's an easier, more flexible, more scalable hook...like
> "we don't sign all mail."
>

There's a subtlety in draft-allman-dkim-ssp-02 that if user-level SSP is
specified but no user-level record is found, it uses the domain-level
SSP.  So if there are a few exceptions to the domain-level SSP, you only
need to publish a few.  In any case, for your example, no more than
50,000 :-)

The aspect of user-level SSP that concerns me equally is the transaction
load.  When user-level SSP is "turned on", the verifier MUST query for a
user-level record in addition to the domain-level record.  User-level
queries are not as effectively cached, since these are queries for
individual addresses, not domains.

-Jim

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 6 Sep 2006 16:00:11 -0700 (PDT)

> individual addresses, not domains.

Actually your tree-walking in general is what's most troublesome to me.
This is what would cause the most problems and most extra queries and
cache misses (I know NXDOMAIN can be cached but don't assume you can
rely on it). And I don't think this will fly during last-call and/or
when DNS folks see this.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Wed, 6 Sep 2006 16:05:59 -0700

On Sep 6, 2006, at 3:44 PM, Jim Fenton wrote:

> The aspect of user-level SSP that concerns me equally is the  
> transaction load.  When user-level SSP is "turned on", the verifier  
> MUST query for a user-level record in addition to the domain-level  
> record.  User-level queries are not as effectively cached, since  
> these are queries for individual addresses, not domains.

This depends upon the number of exceptions made, and whether these  
exceptions can normally be handled within the domain level  
transaction.  If this mechanism is intended to provide additional  
assurances by way of added annotations for a few email-addresses, it  
seems likely this could be accommodated within a domain level  
transaction.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Wed, 06 Sep 2006 16:15:36 -0700

> rely on it). And I don't think this will fly during last-call and/or
The tree-walking issue (separate from the user-level SSP) issue has
concerned me too.  The allman-dkim-ssp-02 draft has it down to 2 queries
-- much improved from the previous revision, in part because of the use
of a separate RR.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Wed, 6 Sep 2006 16:25:30 -0700

On Sep 6, 2006, at 4:00 PM, william(at)elan.net wrote:

> Actually your tree-walking in general is what's most troublesome to  
> me.  This is what would cause the most problems and most extra  
> queries and cache misses (I know NXDOMAIN can be cached but don't  
> assume you can rely on it). And I don't think this will fly during  
> last-call and/or when DNS folks see this.

A scheme could offer protection by annotating assured valid email- 
addresses of those also found within the address-book.  This list of  
email-addresses can be enhanced with local-parts added via policy.   
With this scheme there is _no_ need to walk label trees.  This  
protection does _not_ depend upon blocking look-alikes or spoofed  
email-addresses.

DKIM requires some form of annotation, as valid signatures are  
transparent by design.  Blocking all bad actors is not practical.  By  
depending upon the address book, not providing bad actors any  
assuring annotations can be achieved in most cases without any  
additional transactions beyond just verifying the signature.  Some  
additional transactions might extend the list of email-addresses  
being annotated, or extend the assurance of valid email-addresses by  
way of associations.

-Doug

---

From: "Thomas A. Fine" <[email-masked]>
Date: Wed, 6 Sep 2006 19:24:38 -0400 (EDT)

The alleged half-implemented DKIM within a domain makes no sense
whatsoever - why would a domain work really hard to maintain
thousands or millions of records, so that the spammers can continue
to forge spam from their domain with policy-assured freedom?
They won't.

The sensible solution is to dispense with all this user-signed nonsense.
It does no real good.

Domains should be free to set up as many keys as they want, and use
them however they want.  If they want to set up a million keys, one
for each user, well, that's dumb in my opinion, but let them, because
it's not for me to dictate.  At any rate, this will handle any odd
situations where users have a legitimate need to self-sign.

BUT: this should all be part of the standard mechansim for distributing
valid keys, and should not in any way be a special case for user
validation.  It should simply be part of the selector mechanism.

	   tom

---

From: [email-masked] (Wietse Venema)
Date: Wed, 6 Sep 2006 19:38:38 -0400 (EDT)

> individual addresses, not domains.

Could someone please explain the nature of the problem that would
exist when these (financial) institutions can't selectively add
DKIM signatures to outbound email? Engineering is about balance,
but I haven't heard enough to make the trade off yet.

With per-user records in the DNS, should we not be worried about
brute-force attacks to guess email addresses?

I'm also worried about the implied requirement that a DKIM verifier
would have to do SSP lookups even when a valid first-hand DKIM
signature exists.

	Wietse

---

From: Douglas Otis <[email-masked]>
Date: Wed, 6 Sep 2006 16:58:24 -0700

On Sep 6, 2006, at 4:24 PM, Thomas A. Fine wrote:

> to forge spam from their domain with policy-assured freedom? They  
> won't.

What is being forged, the email-address?

> The sensible solution is to dispense with all this user-signed  
> nonsense. It does no real good.

The mechanism being sought is to use policy as a means to  
differentiate a message from other messages within a common signing  
domain.  The concern is not limited to just spammers.  The recipient  
can then recognize specific assurances via message annotations.  This  
mechanism is essential.

> for each user, well, that's dumb in my opinion, but let them,  
> because it's not for me to dictate.  At any rate, this will handle  
> any odd situations where users have a legitimate need to self-sign.
>
> BUT: this should all be part of the standard mechanism for  
> distributing valid keys, and should not in any way be a special  
> case for user validation.  It should simply be part of the selector  
> mechanism.

An arcane component of a DKIM signature (the selector) or a signing  
subdomain (where assurances of the email-address being valid is lost)  
does not offer viable differentiated protections.  Keep in mind, the  
entire domain is not equally trustworthy.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Wed, 6 Sep 2006 14:34:55 -0700

On Sep 6, 2006, at 1:47 PM, J.D. Falk wrote:

>> deployment. If you are a bank with 100,000 employees with email  
>> and you want to deploy DKIM you probably want some form of hook  
>> that lets you do it in stages.
>

The application envisioned would be to limit annotations for email- 
addresses where an assurance is desired.  This avoids needing to have  
a local-part pre-entered into the address book when this is used as  
an annotation filter.  Perhaps these addresses would be accounts@ or  
administrator@, and something different later.  Just a simple list  
could be used when only a few email-addresses warrant special  
annotations.  There is also an ability to use a hash of the local- 
part over a domain lookup method to infinitely expand this list, at  
the expense of an added DNS transaction.  These records should be  
small and short-lived.

Financial institution would be able to then limit the number of email- 
addresses automatically receiving special annotations.  Transactional  
messages could by convention use specific email-addresses for these  
messages.  The convention in use would be conveyed by the policy  
record.  Perhaps Yahoo! could use admin@ or accounts@ addresses to  
differentiate staff or transactional messages from those of other  
users.  The number of these email-addresses will likely be fairly  
limited, and can be limited by convention.

If there is a desire to apply a policy to all but a few email- 
address, then a hash over domain method in conjunction with a  
wildcard offers another solution.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Wed, 6 Sep 2006 17:13:02 -0700

On Sep 6, 2006, at 4:38 PM, Wietse Venema wrote:

>> transaction load.  When user-level SSP is "turned on", the  
>> verifier MUST query for a user-level record in addition to the  
>> domain-level record.  User-level queries are not as effectively  
>> cached, since these are queries for individual addresses, not  
>> domains.
>

An institution that signs all their messages may wish to restrict  
which messages are seen by recipients as being annotated with added  
assurances. (A gold star next to the email-address perhaps.)  Not all  
messages being signed are equally vetted, and not all are equally  
trustworthy.  The desire is to limit assurances automatically placed  
upon their messages to that of a select few.  The identifier commonly  
communicated is that of an email-address, which is a natural means to  
differentiate messages.

> brute-force attacks to guess email addresses?

Why?  The signature must be valid and the email-address must be  
assured to be valid.  How is the email-address susceptible?

> would have to do SSP lookups even when a valid first-hand DKIM  

The envisioned means of applying protection depends upon the email- 
address first being recognized.  Only in those cases, might there be  
any need for any additional transactions.

-Doug

---

From: John Levine <[email-masked]>
Date: 7 Sep 2006 00:21:35 -0000

>but I haven't heard enough to make the trade off yet.

I think the alleged problem that putatively needs to be solved is that
bigbank.com somehow manages to get signing in place for their
employees whose names start with A through M, but hasn't get gotten
around to doing so for N through Z and wants to tell the world that it
signs all ofthe A through M.

I have to admit that I don't see this as a problem worth solving,
either.

R's,
John

---

From: [email-masked] (Wietse Venema)
Date: Wed, 6 Sep 2006 20:39:33 -0400 (EDT)

> An institution that signs all their messages may wish to restrict  

No offense intended, but I had hoped that someone else could answer
the question, instead of the one voice that I hear advocating this
item several times a day.

> assured to be valid.  How is the email-address susceptible?

I can answer that. Exploitation of the mapping from recipient
address to DNS record name, by the application of brute force.

I expect that hammering a DNS server would be much faster and much
stealthier than hammering an SMTP server.

	Wietse

---

From: Douglas Otis <[email-masked]>
Date: Wed, 6 Sep 2006 18:20:32 -0700

> address to DNS record name, by the application of brute force.

If policy attempts to list all valid email-addresses, then it would  
be possible to use these records to discover valid email-addresses as  
you suggest.

This is not how the mechanism is envisioned to be used however.  As  
opposed to John's suggestion, this mechanism would automate  
annotations for "select" email-addresses within a domain.  These  
email-addresses are likely already widely known, and are useful only  
in conjunction with a trusted domain.  These "select" email-addresses  
offer a means to differentiate messages the trusted domain wishes to  
automatically convey as trustworthy.

An annotation scheme can limit annotations to those email-addresses  
found in an address-book and also marked by way of signature syntax  
or policy to be valid.  When a domain is well-known or found within  
an address-book, annotations can be automatically extended to also  
include a "select" few addresses.  Most likely these would represent  
various email-addresses using in transactional messages and bulk  
mailings.

-Doug

---

From: [email-masked] (Wietse Venema)
Date: Wed, 6 Sep 2006 21:42:07 -0400 (EDT)

> automatically convey as trustworthy.

With only a small number of email addresses in a domain, the existing
mechanism is plenty sufficient. Simply use an appropriate selector
field in the DKIM signature.  This problem can easily be solved
without introducing complexity in the form of per-user mechanisms.

As far as I can tell, we're talking about a solution for which a
convincing problem has yet to be found.

	Wietse

---

From: Douglas Otis <[email-masked]>
Date: Wed, 06 Sep 2006 21:05:31 -0700

On Wed, 2006-09-06 at 21:42 -0400, Wietse Venema wrote:

> mechanism is plenty sufficient.

It does not matter whether there are hundreds or millions of
email-addresses within a domain.  A mechanism offering unique policy for
a select email-address offers essential protection when only the domain
is trusted.  This selective mechanism would likely apply to only a few
of the email-addresses.

> Simply use an appropriate selector field in the DKIM signature.  This
> problem can easily be solved without introducing complexity in the
> form of per-user mechanisms.

Currently there is no DKIM convention to assist in identifying which
messages should receive automated assurance-related annotations based
solely upon the domain.  

Do not assume:
 a) Recipients recognize look-alike and cousin domains.
 b) Email-address validity is not important.
 c) Messages signed by a trusted domain are trustworthy.
 d) DKIM selectors or signing domains indicate:
   i) An email-address is valid.
   ii) A message is trustworthy.
 e) All messages from bad actors have been blocked.

> convincing problem has yet to be found.

Not all messages signed by a domain are:
 - trustworthy.
 - offer valid email-addresses.

These facts poses a basic problem when attempting to convey trust
related information to a recipient by way of annotation.  How else is
DKIM to be used? 

Most institutions are not willing to vouch for the integrity of all
signed messages.  Once signed, a message can be replayed, thereby
amplifying concerns of their integrity.  An ability for the domain to
vouch for only specific email-addresses offers substantial protections
for both the domain and the recipient.

This selectivity can be achieved without email-address selective
policies.  However, isolation by email-address likely conforms to most
domain's expectations and present practices.

One a recipient places an email-address into their address book, only
validity semantics are required at that point. 

-Doug

---

From: "Thomas A. Fine" <[email-masked]>
Date: Thu, 7 Sep 2006 09:59:08 -0400 (EDT)

>related information to a recipient by way of annotation.  How else is

Well, MAYBE TO PREVENT SPAM!!!!  Gaaah!

But I just really really don't get what you're getting at.  DKIM is
(or should be!) essentially a transport layer solution, and you're
talking application layer.

So some particular application wants some mechanism whereby it
distributes levels of trust in it's email.  Why wouldn't they
just add a header line to their mail that says "this mail is
extra-double-secret trusted", and then sign that line along with
everything else?

>for both the domain and the recipient.

WHAT!?!?!! WHAT!!?!??  Why would a domain sign a message if it wasn't
vouching for that message!!?"!?!??

Messages can be "replayed"?  How does per-user signatures help stop
that?  DKIM doesn't make assurances about the intended recipient,
only about the sender.

>domain's expectations and present practices.

Please please please give an actual real-world examle of what your
talking about, because everything I read from you sounds like
mumbo jumbo.  Just one little real live situation.  That's all.
Come up with that, and at least maybe I'll finally understand what
you're talking about.

        tom

---

From: Michael Thomas <[email-masked]>
Date: Thu, 07 Sep 2006 08:24:56 -0700

>signs all ofthe A through M.
That may be a use (though pretty unlikely to me), but the use case that I've
heard of is more aimed at securing things like [email-masked] 
without
having to say "I sign everything" for the entire domain which is assumedly a
lot harder. The thing about this is that you can alternately set up a 
record for
[email-masked] or somesuch which would work the same way.
I've heard it expressed that that is problematic for some people, but I 
frankly don't
remember why at this point. Hopefully somebody can remind me.

       Mike

---

From: Douglas Otis <[email-masked]>
Date: Thu, 07 Sep 2006 08:16:40 -0700

> Well, MAYBE TO PREVENT SPAM!!!!  Gaaah!

DKIM can not prevent spam!

> talking application layer.

DKIM is transparent to the recipient.  DKIM is unable to block messages
from bad actors.  DKIM does not even safely allow white-listing from
large domains where there is risk of replay.

There MUST be an application layer to convey which messages are offering
some form of DKIM related assurance.  This could be that an assured
valid email-address is also contained within the address book.  It could
also be that a trusted domain categorically assures an email-address.
Either scheme offers valuable protection from common spoofing.

> extra-double-secret trusted", and then sign that line along with

The only control a domain has with respect to DKIM signing is over the
use of the email-address.  DKIM signing can happen at the MTA and the
MUA.  The only way to say "Trust this message" would be by way of the
email-address or some added assertion made within the key/signature.

> vouching for that message!!?"!?!??

There can be different levels of assurance a domain may wish to convey.
A domain may wish to convey a high level of assurance for only specific
email-addresses or messages.  The other assurance levels would be this
email-address is valid, or this message passed through our system.
These represent distinctly different levels of assurance. 

> that?  DKIM doesn't make assurances about the intended recipient,

When asserting a high level of assurance, the vetting required of these
messages is more stringent than that of other messages.  Perhaps no
links are allowed from outside domains, for example.  The source might
be limited to automated messages or trusted mangers.  The replay risk
simply makes this vetting more critical.

> Come up with that, and at least maybe I'll finally understand what

BigBank.com is being heavily phished.  An MUA vendor wishes to offer
different levels of assurances to combat phishing and to restore trust
in their messages.  BigBank.com is large and has many new employees, and
must deal on occasion with compromised systems.   BigBank.com would like
to limit the risks associated with high level assurances being offered
as a feature of the MUA vendor.  It asks the MUA vendor to limit these
assurances to only those messages from the email-address
[email-masked], for example.

The MUA vendor allows the recipient list their trusted domains, or
perhaps pre-captures a list of trustworthy domains.  The next step is to
determine within these large domains, what email-addresses should
receive high level assurances.

-Doug

---

From: Dave Crocker <[email-masked]>
Date: Thu, 07 Sep 2006 09:03:11 -0700

Michael Thomas wrote:
> I've actually implemented this feature from ssp-00 and it does not require
> a SSP lookup if there's a valid first party signature. It's no different 
> than the normal operation.

The difference between doing an SSP process when there is signature 
present, versus only doing one when there isn't is fundamental.

At base the former seems to move SSP from being a basic means of 
checking for rogue mail, into recruiting the receive-side to be an agent 
of the From-field domain owner, for enforcing potentially complex 
operational rules.

Absent compelling demonstration of market need, why are we considering 
something that, to my knowledge, has no experiential base for the scale 
and complexity of the open Internet?

d/

-- 

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

---

From: Jim Fenton <[email-masked]>
Date: Thu, 07 Sep 2006 09:07:37 -0700

Wietse,

> but I haven't heard enough to make the trade off yet.
If a domain wants to selectively add signatures, it needs to publish SSP
that says "unknown: we may sign some or all email" (or not publish SSP
at all, since this is the default).  The interesting case here is when
there are particular addresses for which they can state that all
messages are signed, and want to publish a different SSP for those
addresses.  Another case is when a particular address, say
[email-masked], is used only for transactional mail and they
want to publish SSP that tells the verifier to tell the verifier to
expect a valid first-party signature from that address.
> brute-force attacks to guess email addresses?
Yes, although the use of hashing on the local-part as suggested by Doug
Otis would tend to make this a dictionary attack, rather than capture of
a username from a DNS cache, etc.  In some use cases, I think, the
local-part for addresses that have user-level SSP records will tend to
be well-known, e.g. 'statements' in the example above.  It's not
necessary to publish user-level SSP records for every address in the domain.
> would have to do SSP lookups even when a valid first-hand DKIM
I don't see that implied requirement, any more than it is a requirement
for domain-level SSP.  Can you elaborate?

-Jim

---

From: John L <[email-masked]>
Date: Thu, 7 Sep 2006 12:23:15 -0400 (EDT)

> heard of is more aimed at securing things like [email-masked] without
> lot harder. The thing about this is that you can alternately set up a record 
> for [email-masked] or somesuch which would work the same way.
> frankly don't remember why at this point.

I think it's a problem for banks that signed up for the $2.99/mo DNS 
hosting service and can't afford to switch to the $7.99 version.

R's,
John

"Save at the Sign of the Sock"
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jim Fenton <[email-masked]>
Date: Thu, 07 Sep 2006 09:25:52 -0700

Michael Thomas wrote:
> I've heard it expressed that that is problematic for some people, but
> I frankly don't
Suppose that, at the domain level, bigbank.com can't say it signs
everything but accounts.bigbank.com does.  If someone received a spoofed
message from [email-masked] which didn't contain a valid
signature, the fact that it didn't come from the 'accounts' subdomain
might not be noticed.

I'm just stating the argument, not advocating user-level SSP.  I think
the above problem is venturing too far down the slippery slope of trying
to solving a human-factors issue, especially considering the overhead
associated with user-level SSP queries.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Thu, 07 Sep 2006 09:45:52 -0700

On Thu, 2006-09-07 at 08:24 -0700, Michael Thomas wrote:

> That may be a use (though pretty unlikely to me), but the use case
> that I've heard of is more aimed at securing things like
> [email-masked] without having to say "I sign everything" for
> the entire domain which is assumedly a lot harder. The thing about
> this is that you can alternately set up a record for
> [email-masked] or some such which would work the same
> way.

The account the recipients expect to see is <[email-masked]>.
When this message is signed by "d=accounts.bigbank.com", then this
prevents semantics that would allow the email-address
<[email-masked]> to be assured as being valid. This misses the
goal of offering a high level of assurance.  In fact, this will likely
reduce the level of assurance annotations. : (

When the recipients start seeing the email-address
<[email-masked]>. then they become more prone to cousin
and look-alike attacks, such as <[email-masked]>.
Using this technique at the signing domain reduces assurances the
email-address is valid.  Using this technique at the email-address
increase exposure to look-alike attacks.

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Thu, 07 Sep 2006 08:30:21 -0700

>but I haven't heard enough to make the trade off yet.

See my note to John.

>brute-force attacks to guess email addresses?
Maybe. A better way to express this would be to phrase it as a requirement
and/or constraint on any solution that have this be a feature.

than
the normal operation.

          Mike

---

From: "Thomas A. Fine" <[email-masked]>
Date: Thu, 7 Sep 2006 13:07:43 -0400 (EDT)

>DKIM can not prevent spam!

If yahoo uses DKIM, then DKIM can prevent forged spam from yahoo.  That's
HUGE!  Spam from valid users is something yahoo can easily control -
and if they fail to do that, they risk blacklisting.  That same
principle, across most domains, together with a good blacklist would
eliminate the vast majority of spam we're seeing.

Do you have any idea how bad spam is?  80% of all the email we receive
is spam!  Our mail server is so overloaded, it keeps shutting down sendmail
so it can catch up on spam processing.  We're being forced to install new
hardware to cope.  We waste a HUGE amount of daily staff time on spam.

So if I seem particularly annoyed on this list, it's because I've been
waiting for domainkeys/dkim to grow up enough to be a leaky dam (better
than the sieve we have now), and then I look at this list, and I see
people wasting time on user keys that will never work anyway, and it
makes me really angry.

>large domains where there is risk of replay.

I think you think I want a perfect whitelist/blacklist.  I don't.
If my whitelisted domains produce a little spam, so what.
Our email is 80% spam!!!  If I can reduce that number to 10%, I'm
thrilled.  I want a DKIM that gives us the tools we need to reduce
spam.

>Either scheme offers valuable protection from common spoofing.

The fact that your email shows up at my email server signed by your
email server is all the protection I need or want.  At that point,
I can use my own internal policies to decide if your domain is trustworthy
or not, based on our experience with you and/or your internet reputation.

>email-address or some added assertion made within the key/signature.

No, "trust this message" happens when the domain signs the message.
If a domain is silly enough to hand out it's private key like candy,
and let all of it's users sign their own keys, then they're likely
to be compromised often, and to have a bad reputation.

>[email-masked], for example.

Why would bigbank.com sign a message from [email-masked] if it
wasn't valid?  If it is signed, then bigbank.com is certifying that
it is valid.  That's enough.

It is not DKIM's place to solve the internal security problems of
bigbank.com.  And I don't see how user-signing could help, even if
it was DKIM's job to do that.

	    tom

---

From: "Thomas A. Fine" <[email-masked]>
Date: Thu, 7 Sep 2006 13:20:49 -0400 (EDT)

Ok.  There's a few reasons why we've been told we need this, and
they're all wrong.  Let's take a look at each of them:

1. Provide the ability to transition a domain, where part is ready and
   part is not.

2. Provide the ability to only sign important addresses.

These can be handled by "I sign some mail" (or perhaps just as
well with no policy at all).  Then the company can sign only the mail
they want to sign.

In both of these first two cases, there is an assumption that it will
be hard for bigbank.com to get to the policy of "I sign all email",
and we should accomodate them.  Granted it's hard.  But we should also
be able to assume that it is worth it, and that "I sign all" is the
desired long-term situation.

A half-covered domain leaves that domain severely exposed.  Suppose
bigbank.com signs for "accounts", "statements", "president",
and "investment".  They would also have to try to exhaustively
cover for 1000 legitimate looking variations on those addresses, as
well as 10000 legitimate looking addresses that don't look anything
like the real ones, and almost certainly miss something, and leave
themselves open to phishing, anyway.  All despite the fact that they
tried to do something that is in many ways more complicated than
full coverage.

100% coverage may be hard, but it is necessary to protect a domain.
Half-assed coverage is useful transitionally, that is all.  Subdomains
are another mechanism by which bigbank.com can split up their transition,
and protect the most important addresses first, although again, without
complete coverage you can have similar problems.

3. Provide the ability to sign all addresses, but offer different strengths
   of signatures, ranging from "this came from us" to "we absolutely
   certify the accuracy of everything in this message"

I'm trying to make sense out of this.  I'm not sure I see it yet.

What good does it do to give a particular address it's own key
if you're already signing everything?  Is there some proposed
mechanism for quality assurance ratings as a part of DKIM?

I suppose one case might be the disgruntled bigbank employee
who starts generating fake messages from [email-masked].
That's an internal matter for bigbank, and it isn't our job to
fix this problem.  Internally, there's dozens of ways for them to
secure important addresses, including software that requires extra
verification for certain addresses, or use of subdomains to partition
off everyone from mid-management on down.

But ultimately, no scheme can completely prevent this from happening.
What if the guy that maintains DNS is the one that's disgruntled?

4. Provide the ability for users outside of a domain to send mail from
   within that domain.

Again, it's not DKIM's job to solve the internal problems of a domain,
especially when those internal problems are so easily solved
otherwise.  VPN is one solution, so widely available that I can
run it on my palm.

          tom

---

From: Douglas Otis <[email-masked]>
Date: Thu, 7 Sep 2006 12:01:47 -0700

On Sep 7, 2006, at 10:07 AM, Thomas A. Fine wrote:

> If yahoo uses DKIM, then DKIM can prevent forged spam from yahoo.   
> That's HUGE!  Spam from valid users is something yahoo can easily  
> control - and if they fail to do that, they risk blacklisting.   
> That same principle, across most domains, together with a good  
> blacklist would eliminate the vast majority of spam we're seeing.

Yahoo!'s use of DKIM will not prevent spam purporting to be from  
Yahoo!.  There can be messages that appear to have been submitted to  
a mailing-list, or replays of messages.  DKIM offers few methods to  
identify a message as being spam.  DKIM offers a means to verify the  
particular domain from which the message had been signed.  While  
allowing for annotations that assure the recipient, DKIM still does  
not prevent spam, even when purporting to be from a domain that  
claims to sign all messages.

> Do you have any idea how bad spam is?  80% of all the email we  
> receive is spam!  Our mail server is so overloaded, it keeps  
> shutting down sendmail so it can catch up on spam processing.   
> We're being forced to install new hardware to cope.  We waste a  
> HUGE amount of daily staff time on spam.

About 70% of that 80% abuse is being sent from compromised systems.   
Tens of thousands of stolen credit card numbers are being used to  
establish email accounts every day as well.  If DKIM is going to make  
a difference, it will be with respect to reporting and preventing  
common spoofs through the use of DKIM annotations in combination with  
the address book, and perhaps trusted domain lists and high level  
assurance annotations.

> So if I seem particularly annoyed on this list, it's because I've  
> been waiting for domainkeys/dkim to grow up enough to be a leaky  
> dam (better than the sieve we have now), and then I look at this  
> list, and I see people wasting time on user keys that will never  
> work anyway, and it makes me really angry.

Stopping people from clicking on malware, or filling out financial  
information is absolutely essential in fighting spam.  Assurance  
annotations that DKIM provides should become a gold standard people  
insist upon seeing before taking actions suggested in an email message.

>> DKIM is transparent to the recipient.  DKIM is unable to block  
>> messages from bad actors.  DKIM does not even safely allow white- 
>> listing from large domains where there is risk of replay.
>
> If my whitelisted domains produce a little spam, so what. Our email  
> is 80% spam!!!  If I can reduce that number to 10%, I'm thrilled.   
> I want a DKIM that gives us the tools we need to reduce
> spam.

While there are a limited number of IP addresses, there are also an  
unlimited number of new and used domains that can be obtained at  
little cost.  The concept that DKIM in conjunction with white/block  
listing will make a dent in the amount of spam is simply wrong.  DKIM  
should improve reporting and help prevent spoofing, nothing more.

>> There MUST be an application layer to convey which messages are  
>> offering some form of DKIM related assurance.  This could be that  
>> an assured valid email-address is also contained within the  
>> address book.  It could also be that a trusted domain  
>> categorically assures an email-address.  Either scheme offers  
>> valuable protection from common spoofing.
>
> I can use my own internal policies to decide if your domain is  
> trustworthy or not, based on our experience with you and/or your  
> internet reputation.

To prevent disruption of email services, your system will also  
continue to accept messages that are not signed, and that have  
signatures that appear to have been damaged.  Perhaps only when an  
email-address domain makes an extreme assertion all their messages  
are assured to have a perfect signature, would there be a basis to  
block those messages.  Every other look-alike or cousin domain will  
still be accepted.  Without annotation applied to signed messages,  
the recipient will not have been helped at all.

>> The only control a domain has with respect to DKIM signing is over  
>> the use of the email-address.  DKIM signing can happen at the MTA  
>> and the MUA.  The only way to say "Trust this message" would be by  
>> way of the email-address or some added assertion made within the  
>> key/signature.
>
> If a domain is silly enough to hand out it's private key like  
> candy, and let all of it's users sign their own keys, then they're  
> likely to be compromised often, and to have a bad reputation.

A large domain like Yahoo! will perpetually have a moderate  
reputation, largely due to their size and ease of obtaining an email  
account.  Does this mean that Yahoo! can never be trusted on the  
basis of their domain?  Most would trust a message that Yahoo! backs  
with a high level of assurance.  Perhaps [email-masked] could  
receive a high level assurance.  This high level assurance might be  
deduced by specific email-address policy this email-address is  
"STRICTLY ASSURED TO BE SIGNED."  A message signed by Yahoo! and  
given a high level of assurance should become a minimal requirement  
before anyone follows actions suggested in an email, at least without  
other out-of-band information.

Perhaps Yahoo! wishes to request their users to go to a web-page and  
update a compromised browser toolbar.  If this were a message from a  
bad-actor holding one of their accounts and people responded based  
solely upon the Yahoo! signature, this would be very bad news  
indeed.  High level assurance annotations offer vital protections.

>> BigBank.com is being heavily phished.  An MUA vendor wishes to  
>> offer different levels of assurances to combat phishing and to  
>> restore trust in their messages.  BigBank.com is large and has  
>> many new employees, and must deal on occasion with compromised  
>> systems.   BigBank.com would like to limit the risks associated  
>> with high level assurances being offered as a feature of the MUA  
>> vendor.  It asks the MUA vendor to limit these assurances to only  
>> those messages from the email-address [email-masked], for  
>> example.
>
> Why would bigbank.com sign a message from [email-masked] if  
> it wasn't valid?  If it is signed, then bigbank.com is certifying  
> that it is valid.  That's enough.

One should not expect the recipient to be able to even recognize the  
email-address.  One should not expect all messages being signed will  
have valid email-addresses, or that they are from trustworthy sources  
either.  A signature alone is never enough.

> it was DKIM's job to do that.

It is not user policy, but email-address policy that is significant.   
If BigBank.com knows that <[email-masked]> is trustworty, but  
that other emails-addresses are less trustworthy, how should that be  
conveyed?  By not signing the other messages?  That would be silly.   
BigBank.com can however make extremely strong assertions about  
<[email-masked]> that would be highly disruptive when applied  
to other addresses.  This could be done solely to increase the level  
of assurance annotations this message receives.  Assurance  
annotations offer a proactive means of preventing broken signature  
and look-alike attacks.

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 07 Sep 2006 20:46:44 +0200

John L wrote:

> I think it's a problem for banks that signed up for the
> $2.99/mo DNS hosting service and can't afford to switch
> to the $7.99 version.

<g>  Finding someone who knows the difference is a hurdle.

Frank

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 7 Sep 2006 12:48:33 -0700 (PDT)

> -- much improved from the previous revision, in part because of the use

Are you sure there is a limit? I distinctly remember a paragraph from
your draft that says that in case of NODATA the verifier needs to
walk down the tree until it reaches root.

Also while I think separate RR is right way to go, I have to note
that since you want to already use TXT for public key, you might
as well (ab)use it for these policy records too - otherwise you'd
cause difference in adoption rates for those wanting to use
signatures and those who want to use policy, making using police.
And personally I think public key is the one that a lot more
belongs into being separate RR (binary CERT preferably) though
in reality you should just avoid putting large public key records
in dns all together as it brings further abuse and problems for
caching name servers that can be avoided otherwise.

---

From: "Thomas A. Fine" <[email-masked]>
Date: Thu, 7 Sep 2006 17:13:04 -0400 (EDT)

>should improve reporting and help prevent spoofing, nothing more.

Little cost.  Compare this to an infinte number of totally free
addresses and domains.  That's the current situation.  I'll take the
improvement.  Especially since each domain a spammer buys is good for a
matter of hours at best before it is distributed to blacklists
worldwide.

>the recipient will not have been helped at all.

There is nothing extreme about signing every outgoing message.  And if
they do that, of course I'll reject their unsigned or invald email.
Disruption of email services?  Email is constantly disrupted, and
people get along.  Right now the biggest cause of non-delivered
messages is false SPAM positives.  If a domain promises to sign all
messages and messes up now and then, they'll still have a better
delivery rate than going through spam filters.

Look-alike domains with valid signatures can be added to a public
blacklist and forever more be blocked by anybody who cares to do so.

>indeed.  High level assurance annotations offer vital protections.

This is yahoo's problem, and they can deal with it.  The mail came from
one of their own accounts, so they can trace all mail from that account
and contact everyone who received that mail.  The bad actor won't keep
the account for long, and won't get to send many messages.  Yahoo might
even catch the problem on an outgoing filter, noticing that it looked
like a forgery of it's own admin mail.  Yahoo might also notice that
this user has sent 1000 messages in the last two minutes, and that
maybe it should just hold onto all of those messages for a little while.
Yahoo could treat all new accounts with suspicion for some period of
time.  There are so many cool things that yahoo could do if they wanted
to stem the tide, and protect the reputation of their own email.

>either.  A signature alone is never enough.

All these these are true separately but not together.  If I get
mail from bigbank, I expect to recognize the address, and I expect
the address to be valid, and I expect it to be signed, and I expect
the signer to be bigbank.  After all that, I'll believe it's
proably from them, although even then not enough for anything really
sensitive.

>conveyed?  By not signing the other messages?  That would be silly.   

If it doesn't trust them internally, it certainly should not sign them.
It would be silly TO sign an outgoing message that you can't trust.

>annotations offer a proactive means of preventing broken signature  

How does it prevent look alikes?  What's to keep a phishing attack with
valid keys and super secure annotations from [email-masked]?
The signature itself without annotations is sufficient to prevent any
lookalikes on the left side of the @.

The thing I find amazing in all of this is that simoultaneously, you
believe these two things about DKIM:

1. DKIM can never be good enough to trust as part of a domain-wide
   delivery filtering mechanism.
2. DKIM can be strong enough to encourage users to enter personal
   information into emailed HTML forms.

First of all, mail gets lost.  ALL THE TIME.  Your mail, my mail,
everybodies mail.  Sometimes NOBODY EVEN NOTICES.  The rest of
the time, it just gets resent.  Who cares?  Transitioning to a
system where a domain promises to sign every message is not that
hard, because SO WHAT if a little mail gets lost in the process.
Mail servers are upgraded regularly, configurations are changed
regularly, and mail gets lost regularly.

Second of all, at this juncture, no reputable company has any business
requesting personal information via email.  It's like receiving
a phone call from a charity and giving them your credit card on the
spot.  And with DKIM, it's like trusting them because caller ID
said plain as day that it was the "Amer Cancer Ass".

Me - I pick up the phone if the caller ID is not blocked or unknown.
But I don't give them my credit card in any case.

	tom

---

From: Douglas Otis <[email-masked]>
Date: Thu, 7 Sep 2006 14:57:17 -0700

On Sep 7, 2006, at 10:20 AM, Thomas A. Fine wrote:

> 1. Provide the ability to transition a domain, where part is ready  
> and part is not.

This would not be a problem unless one assumes policy can only be  
applied domain wide.

> 2. Provide the ability to only sign important addresses.

Or sign all messages and apply different policies based upon email- 
addresses.

> These can be handled by "I sign some mail" (or perhaps just as well  
> with no policy at all).  Then the company can sign only the mail  
> they want to sign.

This affords no protections beyond there being no policy asserted.

> In both of these first two cases, there is an assumption that it  
> will be hard for bigbank.com to get to the policy of "I sign all  
> email", and we should accomodate them.  Granted it's hard.  But we  
> should also be able to assume that it is worth it, and that "I sign  
> all" is the desired long-term situation.

Without a means to differentiate policies based upon email-addresses,  
employees of BigBank.com participating in mailing lists need to use a  
different email-address domains.  Unless all employee's email- 
addresses are changed, BigBank.com remains exposed to the possibility  
of poorly vetted messages being signed without a means to adjust  
assurances being implied by a trusted domain list.

> bigbank.com signs for "accounts", "statements", "president", and  
> "investment".  They would also have to try to exhaustively cover  
> for 1000 legitimate looking variations on those addresses, as well  
> as 10000 legitimate looking addresses that don't look anything like  
> the real ones, and almost certainly miss something, and leave  
> themselves open to phishing, anyway.  All despite the fact that  
> they tried to do something that is in many ways more complicated  
> than full coverage.

When DKIM related annotations are always expected by the recipient,  
there would be zero concern related to look-alike attacks, as these  
messages would not obtain these annotations.  These annotations could  
be based upon an email-address being found within the address book,  
or within a trusted domain list in conjunction with email-address  
assurances made by way of policy.

> Half-assed coverage is useful transitionally, that is all.   
> Subdomains are another mechanism by which bigbank.com can split up  
> their transition, and protect the most important addresses first,  
> although again, without complete coverage you can have similar  
> problems.

100% coverage will not protect the domain.  There remains the problem  
of look-alike and cousin domain attacks.  The only tenable protection  
available would be based upon recognized email-addresses found within  
the address book or domains listed as being trusted.  Even when the  
domain is listed as being trusted, policy can play a vital role in  
identifying which email-address the domain asserts as appropriate for  
high level assurances.

> 3. Provide the ability to sign all addresses, but offer different  
> strengths of signatures, ranging from "this came from us" to "we  
> absolutely certify the accuracy of everything in this message"
>
> What good does it do to give a particular address it's own key if  
> you're already signing everything?  Is there some proposed  

Although there is always the wonders of web-mail. : (

A sales person or executive may wish to obtain their own email- 
address restricted DKIM key.  This would allow them an ability to  
sign messages without needing to obtain direct access to the  
corporate servers, which may be blocked by hotel firewalls for example.

> I suppose one case might be the disgruntled bigbank employee who  
> starts generating fake messages from [email-masked]. That's  
> an internal matter for bigbank, and it isn't our job to fix this  
> problem.  Internally, there's dozens of ways for them to secure  
> important addresses, including software that requires extra  
> verification for certain addresses, or use of subdomains to  
> partition off everyone from mid-management on down.

BigBank may indeed prevent abuse of the [email-masked] email- 
address.  However, don't assume the recipient even sees this  
addresses.  They may be viewing only the display name.  This issue  
must consider how the message is annotated.  Without annotation DKIM  
is absolutely worthless at preventing any type of spoofing.  With  
annotation, DKIM can preventing the all too common spoof.

> But ultimately, no scheme can completely prevent this from  
> happening.  What if the guy that maintains DNS is the one that's  
> disgruntled?

One could presume that someone administering their system has been  
well vetted.  A sale's person's laptop or a temp worker may represent  
something far less trustworthy.

> 4. Provide the ability for users outside of a domain to send mail  
> from within that domain.

External access is not be the issue raising the concern.  All  
messages being signed still leaves an array of possible messages from  
mailing lists and e-invites etc.  There are too many domains for safe  
annotations to be created on a per domain basis without some  
assistance from that domain.  Allow them to indicate which email- 
addresses should be treated harshly, or provided high level assurance  
annotations.

> Again, it's not DKIM's job to solve the internal problems of a  
> domain, especially when those internal problems are so easily  
> solved otherwise.  VPN is one solution, so widely available that I  
> can run it on my palm.

Policy offers a means to better protect recipients of their  
messages.  It has nothing to do with internal problems.  What is  
being described is fairly normal.  Not everyone within an email- 
address domain are equally trustworthy.  Allow policy to assert  
different levels of assurance for those messages where only the  
domain itself is being trusted.  In other words, recipients don't  
already know the specific From email-address, they just trust the  
domain.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Thu, 07 Sep 2006 15:36:17 -0700

> walk down the tree until it reaches root.
Check draft-allman-dkim-ssp-02; the algorithm has changed substantially
in this revision.
> caching name servers that can be avoided otherwise.
Of course the use of a separate RR will require (probably lots of)
further discussion, but I see the considerations relative to the IAB DNS
considerations draft (draft-iab-dns-choices-03) as being rather
different.  In the case of key records, we know exactly where to look
using the selector and domain name, and the record is either there or it
isn't.  The use of a prefix doesn't hinder that at all.  In the case of
SSP, you can do the same thing with TXT records and a prefix, but it
requires additional queries to distinguish the nonexistent domain case
from the nonexistent policy record case.  That is an argument in favor
of use of a separate RR, but we'll see what the consensus is.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Thu, 7 Sep 2006 17:33:36 -0700

On Sep 7, 2006, at 2:13 PM, Thomas A. Fine wrote:

> Douglas Otis wrote:
>> While there are a limited number of IP addresses, there are also  
>> an unlimited number of new and used domains that can be obtained  
>> at little cost.  The concept that DKIM in conjunction with white/ 
>> block listing will make a dent in the amount of spam is simply  
>> wrong.  DKIM should improve reporting and help prevent spoofing,  
>> nothing more.
>
> addresses and domains.

When is a different IP address easier to obtain than a different  
domain name?

> That's the current situation.  I'll take the improvement.   
> Especially since each domain a spammer buys is good for a matter of  
> hours at best before it is distributed to blacklists worldwide.

In many cases domains have already been acquired where the bad actor  
is thrilled to have a minor investment buy them hours of spamming.   
Block-listing by domain name is more perilous than by IP address.   
Errant blocking of an IP address may disable a server, errant  
blocking of a domain name may disable an entire enterprise. : (

>> block those messages.  Every other look-alike or cousin domain  
>> will still be accepted.  Without annotation applied to signed  
>> messages, the recipient will not have been helped at all.
>
> There is nothing extreme about signing every outgoing message.  And  
> if they do that, of course I'll reject their unsigned or invald email.

You would discard messages from an mailing list?  Perhaps this is not  
the desired outcome for all but a few email-addresses being used. : (

> delivery rate than going through spam filters.

That really depends upon the expectations recipients have for DKIM.   
At this point, serious concerns should be raised about the integrity  
of email-delivery when policy is published.  This is unfortunate, as  
policy can provide an ability to better inform recipients.

> blacklist and forever more be blocked by anybody who cares to do so.

There is also an unlimited number of look-alike and cousin domains.   
Phishing tactics are often complete within a brief period of time,  
typically before any bill is paid.  IP address block-lists are  
already in place, and can be applied prior to the data phase of the  
message.  Why would MTA operators switch to using RHS block-lists?

>> Perhaps Yahoo! wishes to request their users to go to a web-page  
>> and update a compromised browser toolbar.  If this were a message  
>> from a bad-actor holding one of their accounts and people  
>> responded based solely upon the Yahoo! signature, this would be  
>> very bad news indeed.  High level assurance annotations offer  
>> vital protections.
>
> This is yahoo's problem, and they can deal with it.

Selective email-address annotations offer a proactive solution.

> The mail came from one of their own accounts, so they can trace all  
> mail from that account and contact everyone who received that  
> mail.  The bad actor won't keep the account for long, and won't get  
> to send many messages.

The DKIM signature, by design, is not related to the envelope and can  
be carried by any MTA.  Who ends up receiving these messages might be  
under their control, assuming messages are not forwarded.  Yahoo! may  
refuse to accept messages that appear to be signed by Yahoo!, but  
this could cause a conflict when a message is being forwarded, as  
example.  Once an exploit has been reported, perhaps Yahoo! could  
retroactively defang messages already in their recipient's  
mailboxes.  That unfortunately is reactive and unpleasant, and people  
often refang because they think the process is mindless.  Obtaining  
new accounts does not represent a major impediment either.

> Yahoo might even catch the problem on an outgoing filter, noticing  
> that it looked like a forgery of it's own admin mail.

The bad actor do not need to forge any specific email-address.   
Without annotation conventions being established, any social  
engineering trick would likely lead to successful spoofing. : (

> Yahoo might also notice that this user has sent 1000 messages in  
> the last two minutes, and that maybe it should just hold onto all  
> of those messages for a little while. Yahoo could treat all new  
> accounts with suspicion for some period of time.  There are so many  
> cool things that yahoo could do if they wanted to stem the tide,  
> and protect the reputation of their own email.

It is common for a Bot army to be 50,000 wide and message amongst  
themselves to appear normal.  Messages could be variations on a  
general theme that reference an apparently harmless website using  
randomized links when being signed.  At 3:00 AM, the bad actor flips  
the switch, and now it looks like a friendly website offering advice  
in how to reinstall a defective Yahoo! toolbar.  The HTML content now  
looks official, and the message is signed by Yahoo!. : (

>> One should not expect the recipient to be able to even recognize  
>> the email-address.  One should not expect all messages being  
>> signed will
>> have valid email-addresses, or that they are from trustworthy  
>> sources either.  A signature alone is never enough.
>
> proably from them, although even then not enough for anything  
> really sensitive.

It sounds as if this depends upon visual acuity.  Such dependence is  
highly perilous.

>> It is not user policy, but email-address policy that is  
>> significant.  If BigBank.com knows that <[email-masked]> is  
>> trustworty, but that other emails-addresses are less trustworthy,  
>> how should that be conveyed?  By not signing the other messages?   
>> That would be silly.
>
> If it doesn't trust them internally, it certainly should not sign  
> them.  It would be silly TO sign an outgoing message that you can't  
> trust.

There are certainly different levels of assurance a domain may wish  
to make regarding their entire domain, versus a specific email- 
address.  When the email-address is recognized by the address-book,  
then the recipient has established cause to trust the email-address  
out-of-band.  When a trusted list of domains is being used to apply  
annotations, then the application of annotations on specific email- 
addresses would be desired.

>> <[email-masked]> that would be highly disruptive when  
>> applied to other addresses.  This could be done solely to increase  
>> the level of assurance annotations this message receives.   
>> Assurance annotations offer a proactive means of preventing broken  
>> signature and look-alike attacks.
>
> How does it prevent look alikes?  What's to keep a phishing attack  
> with valid keys and super secure annotations from accounts@Big- 
> Bank.com? The signature itself without annotations is sufficient to  
> prevent any lookalikes on the left side of the @.

Imagine that a trusted-domain list offers a gold star next to  
specific email-addresses that is established by way of a policy  
assertion.  Recipients seeing these messages don't need to know that  
the gold star is being applied to the <[email-masked]> email- 
address.  They simply see the gold-star.  Look-alike domains are not  
found in either their address book or within a list of trusted  
domains, and hence never receive the gold-star annotation.

> The thing I find amazing in all of this is that simoultaneously,  
> you believe these two things about DKIM:
>

True, there are too many exceptions required, and replay can be  
problematic.

> information into emailed HTML forms.

True, when annotations are properly applied, following the actions  
recommended in the message would be less hazardous.  If their toolbar  
does need to be updated, this method of notification should be  
reasonably safe.  Of course, the user should still check certs on the  
web site, use a VPN or tunnel for DNS when running a wireless  
connection, etc. etc.

> everybodies mail.  Sometimes NOBODY EVEN NOTICES.  The rest of the  
> time, it just gets resent.  Who cares?  Transitioning to a system  
> where a domain promises to sign every message is not that hard,  
> because SO WHAT if a little mail gets lost in the process. Mail  
> servers are upgraded regularly, configurations are changed  

I was not the person that raised the transitioning concern.  DKIM  
will not see broad adoption if it causes delivery issues.  Policy  
must tread very carefully to avoid these pitfalls.

> Second of all, at this juncture, no reputable company has any  
> business requesting personal information via email.

They may offer a friendly link to save you the effort of typing the  
domain.  A bad actor simply does the same thing.

> It's like receiving a phone call from a charity and giving them  
> your credit card on the spot.  And with DKIM, it's like trusting  
> them because caller ID said plain as day that it was the "Amer  
> Cancer Ass".

There are valid cases where information wants to be distributed to  
recipients.  "Your mortgage payment is due.  Automated payments can  
be established at our website at <http://helpful-link/>."  While this  
message is not a phish, the user should not click on the link.  Some  
provider's defang all links unless there is reason to trust who sent  
the message.  DKIM offers some danger when people trust too much of  
the domain's content.  Policy can make this trust much more selective  
and safer.

> Me - I pick up the phone if the caller ID is not blocked or  
> unknown. But I don't give them my credit card in any case.

Heck, my bank pulls this stunt.  They notice unusual activity on my  
account and call with a blocked number asking me to identify myself  
by with personal identifiers.  Everyone knows the list.  When I ask  
how they are listed to call them back, the person says this is not  
possible, they are in a phone exchange without extensions. It is not  
surprising everyone is so prone to spoofing.

-Doug