Earl Hood <earl(_at_)earlhood(_dot_)com> wrote:
On July 30, 2005 at 21:56, EKR wrote:
In my opinion, a substantial new piece of work like this needs
to start with a threat analysis of the problem and an attempt
to determine whether the proposed solution is likely to actually
help. I don't see any of this here. I appreciate that the authors
don't want to get drawn into an extended debate, but I'm also
quite uncomfortable with IETF engaging in major new effort without
having some level of comfort that it will actually succeed.
Sam Hartman makes a similiar point in his MASS BOF message.
A separate document can be created that defines the security threat
being addressed, analysis of threat, and the types of solutions that
may adequately address that threat.
Well, I generally like to do the threat analysis before the solution
design. Otherwise, how do you know that you're choosing the right
solution?
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.
* Signing agents may be MTAs or other entities in the transmission
of message. A process that does not require full MIME parsing
capabilities and minimizes (or avoids) modification to body
data can be desirable. Signing at the RFC-2822 level will
be more efficient than at the MIME level. This does assume
that MIME-awareness is not a critical requirement in achieving
desired goals.
I'm not sure what you mean by "efficient". Performance-wise? You
have data that hows tha thtis is importatn.
S 1.1
------
The approach taken by DKIM differs from previous approaches to
message signing (e.g. S/MIME, OpenPGP) in that:
o the message signature is written to the message header fields so
that neither human recipients nor existing MUA software are
confused by signature-related content appearing in the message
body
o there is no dependency on public and private key pairs being
issued by well-known, trusted certificate authorities
o there is no dependency on the deployment of any new Internet
protocols or services for public key distribution or revocation.
-----
The first point does not apply to PEM (RFC 1421).
How? Checking the PEM-related RFCs, PEM does nothing with the message
header fields. For non-PEM aware MUAs, PEM-specific data is visible
to the human. (BTW, what is the percentage of MUAs that support PEM?)
Huh? PEM puts the signature in a header, just like DKIM.
S 3.3.3:
-----
o Larger keys impose higher CPU costs to verify and sign email
-----
The CPU cost to verify even fairly large RSA signatures is extremely
small.
Increase in key size affects the performance of signing much more
than verification. If performing a large volumes of signing, this
can be a noticeable performance factor. Volume is a concern for
large mail service providers, like Yahoo.
Yes, I appreciate this. But the sentence says "verify and sign".
And the cost to verify is trivial.
I'm not sure that I agree with this analysis. If the model for the
MTA is that it's going to blindly sign any message from someone
who is authorized, then I agree with you, but that's not the
only model. Consider an MTA which does some outgoing spam filtering
and only signs messages it thinks aren't spam--this is to contain
botnet compromise.
The model you describe may be something that should not be supported
or recommended against. In your model, the signature is being used to
denote, "I think this message is not spam," but I am not sure there
is any value to this usage, and it is not explicitly stated as one
of the goals of DKIM, which is "to demonstrate that the sender of
the message was authorized to use a given email address."
Sure. My point is that just saying that collisions aren't relevant
isn't correct.
S 9.3:
-----
Since the key servers are distributed (potentially separate for each
domain), the number of servers that would need to be attacked to
defeat this mechanism on an Internet-wide basis is very large.
Nevertheless, key servers for individual domains could be attacked,
impeding the verification of messages from that domain. This is not
significantly different from the ability of an attacker to deny
service to the mail exchangers for a given domain, although it
affects outgoing, not incoming, mail.
-----
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.
-Ekr