On Tue, 2005-04-05 at 20:34, Hallam-Baker, Phillip wrote:
My suggestion prevents this risk. Don't give anyone your
private keys. This prevents any message you have not seen (or
processed) from being signed. By having the bank sign their
own messages, rather than some untrusted third-party, then
what is contained within the message remains within their
control.
You are suggesting that the largest banks in the world, not to mention
any other company that outsources email sending are likely to make a
major change in their current business practices wrt email.
Banks signing their mail would be a change, with respect to the way they
conduct their email practices. Corporations, in general, will also need
to change practices, whether they sign their mail or not. Passing
outbound mail through logged and trusted servers should already be a
requirement for most institutions.
This is certainly a bracing approach to requirements analysis if nothing
else.
Keep this signature process simple, without it becoming a mess of keys,
or based upon unrealistic expectations as to what per-user keys will
provide. The advantage of DomainKeys is found leveraging email
authentication, and avoiding a need to defend the dispersal of keys.
Outbound server security is far more obtainable, than that needed for a
key distribution system to thousands of individual user systems.
Which is more practical, establishing a means for users to send mail
through outbound servers, or securely distributing keys and the
gathering of fragmented logs? Email is not just sent on port 25
anymore. Use the Net.
From where I sit what you have successfully argued is the case for
per-user keying.
The phishing scenario remains viable only with per-user keys, so I am at
a loss to understand how you arrived at this conclusion. It would be
practical to assert a domain signature requirement for the FROM field,
as suggested in the mass-reputation draft. This would prevent phishing
by any untrusted entity, provided they are within a separate
sub-domain. This would be a plainly visible alternative, with
assertions limited to the domain, as explained. This deployment
strategy would not be a new practice either.
The number of assertions and records needed to defend and support a
delegation of keys would be difficult to justify. Nor am I confident
DNS would do well, should everyone expect DomainKeys for each mailbox
address.
DomainKeys also offers large providers a mode where the user can use any
email address they desire. DomainKeys, in this case, could offer
greater utility by including an opaque revocation-identifier. Expecting
user-keys to perform a revocation function would create burdensome loads
resulting from short TTLs, when being responsive to replay attacks.
-Doug