EKR wrote:
I agree that something should be provided that explains why something
like S/MIME or OpenPGP are not used a basis for MASS. Such information
can be provided in the threat analysis document when possible solutions
are mentioned.
BTW, here may be some possible reasons S/MIME or OpenPGP are
not useful as a basis for MASS:
* S/MIME, et.al. do not provide arbitrary header signing
capabilities, especially key fields like Subject and From.
Well, unless you do message/rfc822. I could certainly imagine
making a copy of the headers in the body if one wanted to go
the S/MIME direction. Sure, it bloats the messages a bit, but
it has the advantage you're not designing a new cryptographic
messaging protocol.
It's not the bloating, but the complete and utter inconsistancy
of how MUA's render such complicated MIME bodies. We've had a
*lot* of input about that and the consensus was that it is a
requirement that it not touch the body.
----
I think this analysis misses something important: DKIM depends on
wide deployment of signing infrastructure in order to make
a message being not signed meaningful. If popular senders
are regularly unverifiable, this strongly reduces recipients
incentive to make decisions based on DKIM settings.
This will be the case for any new system deployed, so I'm not sure
the argument has much merit.
I'm not sure what you mean by "any new system deployed". There are
lots of network protocols that have value even if only two
people deploy them. (SSH is a good example). The requirement
for very wide deployment is actually mostly unique to situations
where decisions are made on the new protocol *not* being used.
As it turns out, DKIM is useful even in the intra-domain case. Quite
independently, our IT folks were puzzling how to deal with the blow
back of their campaign to alert our people to the dangers of phishing.
What they didn't count on is that a lot of our internal mass mail looks
pretty suspicious -- it asks you to log on and do something, for
example. After they started getting a lot of cases, they went looking
for a way for users to know whether or not they should be believe
that the messages are legit. DKIM fits this bill very nicely, and the
rollout is both incremental within the company and doesn't require
external cooperation outside the company. The network effect will
certainly multiply the advantages, but it isn't necessary for DKIM
to take hold.
FWIW, this is one reason I'm not very hung up about having to come
up with elaborate purposes. The forgery hole is *so* large that it's
very hard to really understand all of its implications, or what closing
it will allow in practice. OTOH, we have plenty of exerience of what
not closing it has permitted. The likelihood of doing net harm in this
area is remote.
Mike