ietf-mailsig
[Top] [All Lists]

Re: DKIM: Canonicalization

2005-07-19 18:05:01

On July 19, 2005 at 15:11, Jon Callas wrote:

Yes!  Since DKIM makes allows digitally signing of message bodies,
there is an implicit indication that message content can be "protected"
via DKIM.

I have to disagree here, as a DKIM author, OpenPGP author, and OpenPGP 
implementer (and soon to be DKIM implementer).

The whole point of DKIM is *envelope* protection, not body protection. 
Yes, envelope is metaphorical, and implementation-wise, you have to 
sign the body to sign the envelope, but the whole point of DKIM is that 
you know the source of the message where the source is an 
administrative domain, and not any content signing.

This goal is not clear according to the current draft.  From the
Abstract:

  DomainKeys Identified Mail (DKIM) defines a domain-level
  authentication framework for email using public-key cryptography
  and key server technology to permit verification of the source
  and contents of messages by either Mail Transport Agents (MTAs)
      ^^^^^^^^^^^^^^^^^^^^
  or Mail User Agents (MUAs). The ultimate goal of this framework is
  to prove and protect message sender identity and the integrity of
                                                       ^^^^^^^^^^^^
  the messages they convey...
  ^^^^^^^^^^^^

Am I incorrect that the above wording can imply that DKIM can be used to
protect the body of the message via digital signatures?

By your own statement, you can only achieve your stated goal by
supporting body protection.  So in reality, DKIM can be used for body
protection.

I think you must be aware of how DKIM will get used in the real-world,
and where people can use DKIM in ways that may have not been initially
intended, or desired.  If such alternate ways cannot be prevented,
because doing so would prevent DKIM's primary goals (and it is easily
forseen that such ways will be exercised) then it is pointless to
say such uses are prohibited.

Imagine that I send you a letter, and I have signed over the seal of 
the envelope. Imagine inside that envelope, there is a signed letter.

DKIM is the external signature, OpenPGP and S/MIME are the internal 
signature.

I think we need to be clear on what is the "envelope".  In the
email world, the envelope is the stuff at the SMTP level, not at
the RFC-2822 level (though there are direct relationships between the
two).

Maybe what you are really refering to is the email encapsulation
of a set of data.  I.e.  The MIME/mail encapsulation of the
data vs the data itself, since mail encapulation can include
encoding of the data, where there is no longer an octet-to-octet
equality between the encoded form and raw form.

If this is the case, it is worth noting that S/MIME and OpenPGP
work at the MIME/mail level.  I.e.  They do not sign the original
raw form of the data, but the MIME/mail encapsulation of the data.
DKIM appears to work at the same level (for purposes of signature
generation and validation).

Unlike DKIM, S/MIME and OpenPGP are MIME-aware.  DKIM only works
at the RFC-2822 level.

It seems some comments on this list indicate that such protection
is not to be as solid as S/MIME or OpenPGP, but a "fuzzy" form of
protection, that is not well-defined (a security red flag).

It's not fuzzy at all. It's very well defined.

The fuzziness comes in wrt canonicalization.  I.e. I've gotten the
impression (maybe incorrectly) by some that it is not critical that
message contents integrity be fully protected: some forms of mutation
that can change the meaning of the content are acceptable.

Of course, others are even more strict about protection, including
violating RFC-2822 semantics.

It is however, not what 
traditionally digital signatures have been used for. It is for 
authenticity, rather than authentication.

What you are describing above is an anti-goal of DKIM. DKIM does not 
sign the letter.

Yes it does.  DKIM explicitly allows the body of the message to
be included in the signature.  If this is not "signing the message"
than I do not know what is.

--ewh


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