Subject: [ietf-dkim] SSP and local parts

From: Jim Fenton <[email-masked]>
Date: Sun, 02 Dec 2007 07:48:51 -0800

At the time DKIM base was designed and standardized, we wanted it to
be a domain-level signature for a number of reasons, including privacy
concerns.  We also wanted to make it easy for domains to delegate
signing authority to outside parties that might send newsletters and
perform other outsourced services on behalf of the domain.

Delegating a key to an outside party that gives them the ability to sign
any mail from the domain requires a great deal of trust.  In order to
lower the trust requirement to a level where key delegation might more
readily happen, the g= tag in the keys was provided to allow a key to be
delegated where the signing address could not be any address in the
domain, but only those whose local-part matches the g= tag.  The i= tag
in the signature specifies what the signing address is; there is not
a requirement that the signing address match any other address in the
header.

The only time that a local-part is required in the i= address is when
the g= tag in the key being used restricts the signing address from
being anything in the domain.  Under all other circumstances, the
local-part of i= MAY be supplied, or not, at the discretion of the
signer.  In that way, DKIM remains a domain-level signature except when
needed to facilitate delegation.

SSP attempts to match the signing address against the address in the
From: header field in order to determine whether a given signature is an
Originator Signature (that it represents the author of the message).  In
the great majority of cases, the local-part of i= will not be present,
and this comparison will be based on domain name only.

If the local-part of the From address isn't compared when there is a
local-part of i=, a serious exploit is possible.  Suppose a party to
whom signing authority for a specific address, e.g.,
[email-masked], signs messages allegedly from other addresses in
the domain for which they are not authorized.  While they could create a
valid signature using i=[email-masked], this should not be
accepted by verifiers as an Originator Signature, any more than a
signature from a completely different domain.  Without the local-part
comparison, this would be accepted as an Originator Signature counter to
the domain owner's intent to delegate the key for a narrower use.

If the intent is to enhance user anonymity, the local-part of i= should
be left blank, so that it will match any local-part in the domain, and
not populated with other tokens or identifiers.  If the signer is
interested in additional tracking information, either the t= timestamp
can be used or a private tag can be added, since an unrecognized MUST be
ignored by the verifier.

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

---

From: John Levine <[email-masked]>
Date: 2 Dec 2007 17:59:23 -0000

>domain, but only those whose local-part matches the g= tag.

The g= field is for key management.  It has the same semantics as the
local part of the i= tag.  Since the local part of i= is an opaque
token, so is g=.

>local-part of i=, a serious exploit is possible.

The problem is that you're assuming a very specific hypothetical usage
model of DKIM and SSP where mail managers are able to do some sensible
things but not others, and then proposing a retroactive change to the
semantics of DKIM to fix a security hole in your hypothetical model.
I see at least one equally large hole in your model which your change
doesn't fix, which tells me that the problem is with the usage model,
not with DKIM.

If a domain is sending a combination of mail where the From: address
is known to be "real" and mail where it isn't, and you want your SSP
to say all the signed mail is "real", then clearly you need to put
different signatures on the "real" mail and the other mail.  That's
fine, make the draft say that, but don't invent new sub-semantics for
DKIM signatures.  Say that if the signed mail from foo.com is supposed
to have "real" From: addresses, don't put a foo.com signature on mail
whose From: line you don't trust.

There are a lot of ways to run mailing lists, and there are a lot of
ways to verify the people sending mail to lists.  Your model in which
the mail managers are brilliantly skilled in applying DKIM signatures
to outbound mail but too inept to check the addresses on inbound mail
is certainly one possible model but hardly the only one, and not even
a particularly likely one.

So here's another hypothetical situation: let's say we have a user
[email-masked] who goes somewhere else and has his mail forwarded to
his Yahoo account.  The people running this setup are the same as the
ones in your hypothetical, so they don't verify inbound mail and just
forward it and sign it.  This means that if I send mail which says
it's From: [email-masked] to Joe, and we use your proposed hack,
it'll get signed with a signature saying it's [email-masked] and sent
along to Joe's mailbox at Yahoo, fully DKIM and SSP compliant mail in
which he appears to spam himself.  It only took two minutes to come up
with this scenario, doubtless we could come up with others.

There are equally many scenarios about how a mail system could decide
what outgoing mail is "real".  In my actual setup, which I think is
not unusual, all senders have to authenticate before sending mail, and
the Received: headers of the mail include hints that let me tell who
it was, but once they authenticate, they can send mail with any return
address they want.  If I want to distinguish "real" mail, at signing
time I need to check the authentication info to figure out what the
authenticated user's known address is, and in your model to put that
into the i= field.  But once I know the address, it's just as easy to
check the From: line and apply different signatures to "real" than to
other mail, and not try to redefine DKIM.

R's,
John