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 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=.
If the local-part of the From address isn't compared when there is a
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
joe(_at_)example(_dot_)com 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: joe(_at_)example(_dot_)com to Joe, and we use your proposed hack,
it'll get signed with a signature saying it's joe(_at_)example(_dot_)com 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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html