ietf-mailsig
[Top] [All Lists]

Re: Feedback on DKIM draft (long)

2005-07-16 08:30:22


On July 15, 2005 at 04:51, "william(at)elan.net" wrote:

 Note, quoted-printable tends to have a bad (mostly undeserved)
 reputation, so it may help to avoid using it, especially when its
 use has never been applied to header data (at least to my knowledge).

There is a variation of quoted-printable used primarily with Subject
header field (mostly internationalization support), but its not the
same as what is introduced in dkim.

Your refering to non-ASCII encoded words as defined in RFC-2047.
I consider it a separate beast since it deals with non-ASCII
based character encodings for supporting non-English languages.

Encoded words as a whole do this, but this doesn't change the fact that
encoded words define a variant of quoted-printable specifically for
use in message headers.

 - I find it odd that the header field that will contain the
   signature (DKIM-Signature) must also be included in the
   signing/verification process.

This has been discussed on this mail list briefly before and was fist
introduced in META-Signature specs (which originally did it on per-tag
basis where each such tag had to be opted-in to be included with "+="
instead of "="; latest spec is closer to DKIM where its done on
per-segment basis with all but 'sig' segment being included by default).

The reasons for including data from signature header itself is to make
it less useful for replay attacks, for example an attacker could take a
signature and replace some of its key parts (like change expiration,
change signer name and domain, etc) and then introduce it as his own.
By including key data tags, the range of replay attacks is reduced.

I am not saying that the information in DKIM-Signature should not be
part of the digest, just that the signature is in a separate field.
For example, the "DKIM-Spec" field (or whatever its name would be)
would be included in the digest computation to protect it from
unintentional or malicious modification.

Exactly.

It causes no change in the risk of replay attacks.

Agreed.

What I'm slightly concerned however is that DKIM says that all tags
are to be included (except 'b') but there maybe reasons to introduce
extensions as new tags with data that is not to be included so I think
opt-out option for unknown tags should be made available.

Do not see the reason, or more appropiately, the usefulness to support
such behavior.  If extension tags are supported, they should be
part of the digest.

I think I agree, but I'm not entirely sure. The handling of extension
tags is hard to get right when signatures are involved.

I think header reordering is not too common, but it does it happen.
Ned suggested that if the field names are the same, header order
is preserved.  I defer to his experience that this is a common
behavior.

I don't believe I've ever seen a case where headers fields with the same
name are reordered. Dropped, sure, changed, absolutely, merged with other
fields of the same name, sometimes, but reordered, never.

However, if reordering is done even on same-named header fields,
it worth knowing how common it is, and if not common, it may
be an acceptable risk.  It would also spur mail administrators
to upgrade old systems or developers to not do reordering in
their software.

OK, let's ask the question directly: Does anyone know of an agent which,
in clear violation of the relevant standards, reorders fields of the same
name?

 - For greatest flexible, the digest should be separated out, and
   it, along with meta-information is what is signed.  Meta-Signatures
   takes this approach.

Yes, separate content digest data makes signature system a lot more
flexible and allows signer better options to make certain his/her
content survives and is verifiable (or at least its key parts). This
also makes it possible to reference retrievable content data in the
appropriate way.

I view it from the flexbility of having different parties performing
different roles in the process.  I.e.  There are potential applications
of DKIM/Meta-Sig where the digest of the email message data is a
separate component that is included in the "Spec" field.  Then, only
the "Spec" field is signed vs the email message data entirely.  This
still protects the integrity of the message data along with clearly
defining the separate roles of the author and the signing agent.

Separation clearly has some benefits.

For example, the author computes the digest and then hands it off
(along with "Spec" info) to the signing agent to create the signature.
This way, the signing agent does not need to know what the actual
content of the email message is (for privacy reasons).

The signing agent may be a service that is provided to multiple
users/customers, and the signing agent does not need to have a complete
copy of the email message to create the signature.

There is no procedure in RFC282[1/2] to introduce new trace fields so
basically any software that does not know about new trace fields will
treat them as regular unknown fields which is not the same as trace.

Unfortunately true.

The procedure is to propose a new standard defining any new
trace fields and what their ordering restriction are :)

I suppose that's possible, especially given that RFC 2821/2822 are
still at proposed.

If you mean there is no way to indicate in a message header which
fields are trace fields, you are correct.  Also, the restrictions
on the Received header field is described in RFC-2821 vs some
"markup" in the header indicating the restriction.

I also think that having "v" tag is better - after all we do have it
always as mime-version and nobody is complaining even though its mostly
still just "1.0". Almost every application I know includes version for
its data format even if that version is just "1.0".

I find it to be good practice to be explicit when possible.  Implicit
can lead to more ambiguity and can make diagnosing problems more
difficult.

Agreed.

                                Ned


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