Subject: [ietf-dkim] DKIM, privacy, and user authentication

From: Jon Callas <[email-masked]>
Date: Thu, 24 Aug 2006 12:12:54 -0700

There's something about DKIM that I think needs to be stated again,  
as it often gets lost. There is a potential problem that any sort of  
digital signature can become a tracking system.

Email already has problems with not being as privacy-friendly as it  
should be in an ideal world. For example, it's possible from this  
message to know where I am to a reasonably small area. It doesn't  
take the powers of Sherlock Holmes to infer a good deal more about  
what I'm doing this week.

Digital signatures also have weird side-effects that are not privacy- 
friendly. If Alice sends Bob a signed message with tart comments  
about Charlie, this can come back to haunt her in ways that mere  
plaintext would not. On top of this are issues of how much a  
signature may or may not imply a legal commitment

When we first created DKIM, we worried about the interactions between  
these things. We didn't want a signature-based email authentication  
system to become a tracking system that makes the loss of privacy  
coming from electronic communications even worse. There are a number  
of facets of DKIM that reflect this desire.

For example, DKIM is a *domain* level system, not a *user* level  
system. Part of the reason is to protect the end users. More  
precisely, it is to permit the administrative domain to protect its  
users. There are other reasons it's a domain-level system, too, but  
let me focus on this one.

A DKIM signature says nothing about the user because the user didn't  
make it. It can't be mistaken for a commitment. It doesn't introduce  
new disclosures of private information. This is not an accident. It  
is not a bug. It is an intentional feature.

This feature has some ramifications. One of these is that the actions  
of a bad user affect the opinion receivers will have of an  
administrative domain, and this affects the good users in the same  
administrative domain. But there are ways that the managers of that  
system can do interesting things. These are allowed, but orthogonal  
to the basic DKIM. For example, a large ISP can use selectors to put  
"good" users under the aegis of different set of keys than the less  
good users.

Another ramification of this is that the end user has no control over  
this. This is the flip side of the above. If I put [email-masked]  
in a different key than [email-masked], Goofus has to lump it or  
pack up. But we want this! It is again, a *feature*. If DKIM didn't  
have this, then commercial ISPs couldn't use it.

Yet another side-effect of this is that the receiver is kept out of a  
lot of intra-domain policy and politics. They can use emergent DKIM  
systems without needing to get involved in actual sausage factory  
behind them.

There is also a dark side of this. An ISP can send email on a user's  
behalf. An ISP can put in i= a string that the end user does not  
like. These are not bugs, they are not omissions. They are  
intentional features. But they are also not problems that exist  
because of DKIM. An ISP can rewrite the headers of a mail now.

On my work mail system, I send out mail with the address of  
[email-masked]. My server rewrites that to [email-masked], and it  
pisses me off. However, this isn't an issue between me and RFC n, it  
is an issue between me and the admins of my mail server. There's  
nothing today that prevents an ISP from slurring an end user by  
putting obnoxious notes in their address. (E.g. goofus+spamming-idiot- 
[email-masked]) It isn't even interesting  
to think of ways that an administrative domain can annoy or defame  
the end users.

But these aren't DKIM problems. They are email problems. Heck, I'd  
argue that they aren't even problems, they are situations. But  
whatever they are, they're beyond the DKIM standard itself.

Similarly, there are ways that an evil ISP can break the very privacy  
protections that are part of DKIM. But they aren't our problem, here  
in this working group. I think it is wrong to do user-level keying,  
because it has bad privacy characteristics. But in your domain --  
knock yourself out.

To sum up, please do not lose sight of the privacy protections that  
are in DKIM. They are there for a reason, and they are agreed upon as  
part of the consensus of this working group. DKIM is not a user  
authentication system. It is not a protocol that forces  
administrative domains to be good actors. This is by intention and  
design.

	Jon

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

---

From: Dave Crocker <[email-masked]>
Date: Thu, 24 Aug 2006 15:12:24 -0700

Jon, et al,

Not to distract from the primary points you are making -- and which I both agree
with and am happy to see documented -- I think it worth clarification a
particular issue.  I am pretty sure it is actually what you meant:

> This feature has some ramifications. One of these is that the actions of
> > a bad user affect the opinion receivers will have of an administrative
> > domain, and this affects the good users in the same administrative
> > domain. But there are ways that the managers of that system can do
> > interesting things. These are allowed, but orthogonal to the basic DKIM.
> > For example, a large ISP can use selectors to put "good" users under the
> > aegis of different set of keys than the less good users.

If the difference between the good actors and bad actors is visible to
receive-side valdiation and assessment, then the distinction should be between
different d= strings, not different selectors.

> > this. This is the flip side of the above. If I put [email-masked] in
> > a different key than [email-masked], Goofus has to lump it or pack
> > up. But we want this! It is again, a *feature*. If DKIM didn't have
> > this, then commercial ISPs couldn't use it.

Again, I believe you mean different d= values, rather than different "keys".  If
the signing is done by the same entity for both types of users, then there is no
benefit in using different keys, whereas there is quite a bit of benefit in
having the reputation identity use different domain names.

d/

-- 

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

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 25 Aug 2006 00:24:47 +0200

Jon Callas wrote:

[...skipping many good points...]

> My server rewrites that to [email-masked], and it pisses me
> off. However, this isn't an issue between me and RFC n, it
> is an issue between me and the admins of my mail server.

For n != 4409 (formerly 2476), its "MAY add Sender" isn't "just
modify From".  They can reject all your submissions until you
use jcallas@, they can even modify the From if that's in their
AUP and you agreed.  They shouldn't silently introduce such
modifications without informing you.  Maybe you have important
reasons when you don't want to use jcallas@.

Frank

---

From: Jon Callas <[email-masked]>
Date: Thu, 24 Aug 2006 17:36:21 -0700

> particular issue.  I am pretty sure it is actually what you meant:
Thank you, Dave. You're right. I was sloppy, and meant d=.

	Jon