On Tue, 2005-03-29 at 21:54 -0500, Sam Hartman wrote:
"Douglas" == Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> writes:
Douglas> This is extending assurances for the local-part. This is
Douglas> not an extension for this local-part mailbox address, and
Douglas> the selector already permits per-user keys.
Yes. But you need to scope a per-user key so that a key intended to
be used for accounts-outgoing(_at_)domain is not used say for
system-administration(_at_)domain(_dot_)
This may be more important for anti-phishing than anti-spam.
An institution receiving phishing attacks can thwart these efforts by
simply signing their email messages based upon the domain, regardless of
the local-part, internal links, or phone numbers that may appear within
these messages. In fact, most of the phishing attempts endeavor to have
the recipient click on a link which appears to bring them to a trusted
web-site.
Having the local-part of the SENDER header bound to a key does
surprisingly little in terms of improving security or consumer
protection. The real danger would be within the message, header order,
and where a link could take the recipient. Perhaps the link is to some
bogus website that simply stages a man-in-the-middle attack while
logging user-names and passwords.
---------------
SENDER: accounts-outgoing(_at_)big-bank(_dot_)com (not seen by user)
FROM: system-administrator(_at_)big-bank(_dot_)com
Dear <recipient local-part>,
The system administrator at Big Bank wishing wishes you to confirm the
balance of your account. For your convenience, the following link will
direct you to the Big Bank account account page. For you safety, this
message has been signed by Big Bank, but you can also find this web page
by following these series of links at our home page:
Enable your browser's Active-Y script, and then follow these links
Customer Support, Accounts, Valued Customer, and Login.
<a href="https://192.168.1.1";>https://www.big-bank.com/logon.php</a>.
Big Al,
System Administrator,
900-555-1212
Big Bank
-------------
Don't give out keys for signing messages you'll never see. A financial
institution being phished would be extremely foolish to expect binding a
local-part to a key will ensure protection. The recipient in this case
will still think the system-administrator sent the message, rather than
accounts-outgoing, although in this case, the signature key may have
been bound to accounts-outgoing.
When Big Bank does not trust the entity they provided a private key (for
signing messages within their domain), binding to a local-part does
little in terms of increasing protection. A design feature of
DomainKeys allows the user mailbox-domain to be separate from the
signing domain. When the signing domain does not control the structure
or content of this message, such as pre-filtering for SSN, account
numbers, quotes, HTML links, or other sensitive information, the
signature will only increase their legal exposure, regardless of a silly
local-part binding.
Of course, generic promotions could be pre-signed where no keys would
need to be given to a bulk email providers. You consider it easier to
distribute special signing MUA programs, and private keys for more than
65,536 users and publish their public keys within DNS, than setting up
an authenticated SMTP submissions on port 587? What protection do you
expect a local-part bound to a key will provide?
In terms of replay protection, it is more effective to use an opaque
identifier and allow the user their desired email account. Perhaps
there could be a Postmaster key flag. With the postmaster flag asserted
within the key, the only valid local-part would be postmaster. The
normal use for this type of key would be within the SENDER header for
delegated keys.
Douglas> Is it prudent for domainkeys to attempt making assurances
Douglas> for the local-part of the mailbox address?
Yes doing so seems like a requirement for per-user keys to be
reasonable from a security standpoint. I do not see myself agreeing
to a proposal that supports per-user keys without scoping the set of
identities those keys are allowed to authenticate.
The scope of a DomainKey is the mailbox-domain. What the domain does
with respect to ensuring which header is significant, what links are
included, and what information is shared, can only be enforced when
these messages are first seen and then signed by the administering
domain. From a security standpoint, binding the local-part to a key
only invites an abusive level of keys being published within DNS, and
may lead to scenarios where the recipient is deceived, as in the above
example.
This, because of a claim it would be too difficult to allow
authenticated access to an outbound SMTP server? DomainKeys will not
prevent users from having their own providers sign their messages. The
major significance of the DomainKey signature, is that a domain accepts
accountability for the message. These may be messages from individuals
using unrelated email mailboxes.
Douglas> Any organization with the resources needed to establish
Douglas> per-user keys, will also have resources to ensure mail is
Douglas> submitted through their own servers.
This statement is false. I'll submit MIT as an example: I'm sure we
could set up a scheme to hand out per-user keys to anyone who wanted
them. I'm equally sure we will never be able to convince everyone to
use our outgoing servers from all mail having an mit.edu from line. I
suspect there are a lot of other organizations with similar
requirements.
Only signing mail sent through MIT servers would allow MIT to control
security. The domain that signs the message does not need to be the
domain found within the FROM header. Convincing users of anything is
simply not required. The Sender would need to be within a domain that
forgives a lack of signature, or that provides a signature.
-Doug