ietf-mailsig
[Top] [All Lists]

Re: Comments on draft-allman-dkim-base-00.txt

2005-07-31 01:57:16

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.

There's no reason why these two need to be coupled at all.
Indeed, it would make a lot of sense to couple a generic
message signature protocol to the key retrieval mechanism
described here.

Agreed.  I think Meta-Signatures proposals uses this approach.
I think the message signature protocol can even be further divided
into a digesting protocol and a signing protocol.

I'm not enough of a mail expert to have an informed opinion
on which packaging is superior from the perspective of compatibility,
however it seems to me that the compatibility requirements for 
{S/MIME,OpenPGP} and this application are essentially similar.
If the approach described in DKIM is superior, then shouldn't
we be retargeting S/MIME and OpenPGP to use it? And if not, then
shouldn't DKIM be using S/MIME or OpenPGP?

A key difference with DKIM, and similiar proposals, is the ability
to sign (arbitrary) header fields.  S/MIME and OpenPGP are limited
in this regard.  For example, from a spamming/phishing context,
header fields like Subject and From are important.

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.

  * 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.

  * Multiple signing: Although DKIM does not address this well,
    mulitple signing may be done to show "chain of custody" as a
    message makes its way through the delivery chain.  Multiple signing
    using S/MIME and OpenPGP, although supported, requires modification
    of the message body each time (which implies MIME awareness).
    A header-based method does not.

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?)

I think a problem with the first point is it implies that MUAs do
not need to be DKIM-aware.  I'm not sure this is a safe assumption
if DKIM is to achieve acceptance.  Of course, MUA awareness is
not required to define DKIM, but it may be needed if DKIM is to
be widely accepted.

The second and
third points are sort of misleading since OpenPGP and S/MIME 
can work perfectly well with e.g., self-signed certificates. 
And with the same level of effort required to distribute DKIM
keys you could build key distribution systems for S/MIME and
OpenPGP with similar levels of assurance.

It may be a worthwhile exercise to see what it would take to define
a DNS-based key management system for use in S/MIME or OpenPGP.

-----
   o  does not require the use of a trusted third party (such as a
      certificate authority or other entity) which might impose
      significant costs or introduce delays to deployment

   o  can be deployed incrementally.
-----

I'm not convinced that this *can* be deployed incrementally.
The key here is to focus on the amount of information provided
by a message being unsigned. If most of the internet is sending
unsigned messages, then the negative weight you can assign to 
someone not being signed is necessarily very small and so it's
not very useful for spam triage. This is exactly the kind of
question which needs to be addressed in a security analysis of this
class of system.

I think the MUA plays a key role here, and I think DKIM short-changes
this.  For spamming and phishing to be addressed, any measures must
be visible to the end-users.  If an MUA is not DKIM-aware, what
real value does DKIM provide to achieve its stated goals.

Also, "RSA" isn't a single function because of the padding issue.
You need to specify PKCS#1 something or other. There's a normative
ref to RFC 3447 but nothing in the text.

Full agreement.  I recommended specifying something like
"RSASSA-PKCS1-V1_5" so it is clear what the cryptographic signing
process is.

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.

S 3.4:
------
      algorithms.  To avoid this attack, signers should be wary of using
      this tag, and verifiers might wish to ignore the tag or remove
      text that appears after the specified content length.
------
If verifiers ignore the tag, the signature will fail to verify,
right? That doesn't seem like what we want.

Much stricter requirements must be provided on how l= is handled.
It should either be dropped from the spec, or if provided, verifiers
must use it.  Using terms like "might" can lead to ambiguity in
verification implementations.

I think the l= tag provides no effective benefit.  For the scenarios l=
tries to address, protocols like S/MIME are much better suited.

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."

S 4:
-----
   Further confusion could occur with multiple signatures added at the
   same logical "depth".  For example, a signer could choose to sign
   using different signing or canonicalization algorithms.  However,
   even this is problematic because some of those signatures will
   inevitably have to sign some of the others (and at very minimum must
   be presented to the verification algorithm in the same order as
   presented to the signature algorithm).
-----
Note that this is a result of the particular signature formatting
choices used by the designers. S/MIME handles parallel signatures
with no problem.

But requires modification of the message body for each signature
added.

DKIM, as written now, punts on multiple signatures.  It also lacks
ability to define what role a signature plays in the message.

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.  The key (no pun intended) is if the
system is secure enough to merit acceptance and wide deployment so
the number of signed messages hits a volume where effective decisions
can be made on them.

S 9.5:
Wouldn't one defense against this be to match the To: lines?

Nope.  The message can still be resent without modifying the To.
Remember, SMTP determines delivery by the envelope address and
not what the message data contains.

An envelope-level check with what is provided in rfc2822.From or
rfc2822.Sender could help in dealing with this attack.  I believe this
type of checking is considered in other anti-spam-related proposals,
so such methods can be used in conjunction with DKIM to deal
with the attack.

--ewh

<Prev in Thread] Current Thread [Next in Thread>