ietf-dkim
[Top] [All Lists]

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

2006-08-24 12:24:15
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 goofus(_at_)domain(_dot_)com in a different key than gallant(_at_)domain(_dot_)com, 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 jon(_at_)pgp(_dot_)com(_dot_) My server rewrites that to jcallas(_at_)pgp(_dot_)com, 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- who-is-90-days-late-in-payment(_at_)domain(_dot_)com) 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

<Prev in Thread] Current Thread [Next in Thread>