-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I thought it might be useful to explain why the DKIM2 drafts written by
myself and my co-authors have made the choices they have as regards to
which header fields should be signed (and how duplicates should be
handled).
DKIM1 (the current RFC) specifies on a per-email basis which header
fields should be signed. However, many email senders do not appreciate
that numerous header fields impact how an email is handled, displayed
and responded to -- and that if these are not signed then there is scope
for security problems to arise. This is a Bad Thing.
There are websites and blogs that proffer advice at to what should be
signed, but there is limited agreement in this advice.
There is a further problem with DKIM1 in that header fields may appear
more than once (even though RFC5322 might forbid this for many header
fields). As various people have described it is not uncommon for
different parts of a mail system to use different instances of these
duplicated fields, so that a verifier might check instance 1 but the
user will be shown instance 2 (or vice versa). This is Also Bad.
Hence, many systems "oversign" by specifying a header field name more
than once -- signing the null second instance means that if an actual
second instance is added then DKIM1 verification will fail.
These are issues even for some of the largest organisations out
there -- as just one example (of a great many) a household name
eCommerce website fails to sign the "Reply-To:" field -- because
they don't usually supply one.
So best practice for DKIM1 is to have a rather long list of header
fields (combining all the various bits of advice) and oversign every
header field that is actually present. If this actually done then
there's quite a lot of bytes being shifted around with every email... if
not done (which is generally the case) then there are numerous
opportunities for bad people to mess with authenticated mail in
undetectable ways to the detriment of email recipients.
So in DKIM2 our first design decision was to get rid of over-signing by
specifying that if a header field is signed then all instances are
combined and signed. Assume hat is the case as we move on...
Then as we worked on the DKIM2 design we had to decide exactly which
header fields were to be signed. There are various possible approaches:
A) Allowing each sender to pick and choose which fields are signed for
each individual email. This continues the current completely
unsatisfactory position that a great many people make poor choices.
We did not want that to continue.
B) Specifying a prescribed list of header fields (combining all the
best practice advice out there) and allowing people to add any
further custom header fields if they felt it appropriate. This list
turns out to be quite long -- some 20 to 30 header fields, maybe
rather more.
This approach is, I think, easier said than done since there is a
lack of agreement on some header fields as to the extent that they
have security properties at all; and some header fields may have
security properties and be commonly seen but are not defined in an
RFC, so we may overlook them.
Also expertise may be hard to come by; for example MMHS is seldom
encountered (and I suspect most readers need to break off and Google
that acronym) but these header fields are listed by IANA so we'd
need to decide about their security impact ...
But the major problem with this approach is that it is not
especially future-proof. If a new header field with important
security properties is developed and comes into widespread use then
it will only be signed if people get around to adding it to the list
of custom header fields (eg an h= field) and that is problematic. We
will end up with important header fields not being signed and we
will be back in a Bad Place.
C) We could sign every single header field. This is attractive, but (D)
is better !
D) We could sign every header field except for the ones that we
explicitly don't sign. So which fields would we wish not to sign?
a) Trace header fields document how an email is handled, as such
they do not make any difference to how a user interacts with the
email, so signing them is not a security issue per se (forensic
examiners who want to know where an email came from might
disagree, but that's not the way we usually think about emaiil
authentication and its security properties).
According to IANA (who maintain a list) there are just two trace
header fields, "Received" and "Return-Path". The latter should
only exist after final delivery. Not signing Received header
fields will also allow intermediate systems to pass email around
within an organisation and still allow verification when a DKIM2
aware system is reached.
b) RFC6376 says that "DKIM-Signature" should be treated as if it
were a trace header field ... and it will be far more convenient
for people inserting both DKIM1 and DKIM2 signatures if DKIM2
did not sign the DKIM1 signatures (the reverse will of course be
true unless the h= field, foolishly I think, specifies
otherwise) because the signing actions can then be done in any
convenient order.
It seems best to say that "DKIM*" is not signed, since that will
improve the lives of people specifying DKIM3. Note that DKIM2
modification header fields WILL be signed, but at special
position towards the end of the algorithm.
c) Similarly signing ARC header fields leads to ordering
complications so we will exclude those.
d) Since draft-clayton-dkim2-spec-00 appeared, discussions have led
us to conclude that we should not be signing any "X-" header
fields at all and -01 will have text to that effect.
The reasoning here is two-fold, firstly most of the commonly
seen X- header fields are de facto trace fields. The only
exceptions that come to mind are X-Face and X-Image-URL and I
don't think these have been used for 15 years or more. New X-
header fields are explicitly discouraged in RFC6648.
The second reason is that many systems (especially the very
large ones) add X- header fields to embed account-related
information ("this email came through my platform for this user
of mine") -- forwarding email in such circumstances will cause
every such email to have to have "modification" header fields to
record the additions. Since this information is inherently
proprietary (and is encrypted/signed in its own right so is
meaningless to anyone else who sees it) there is no value in
signing it with DKIM2.
d) There is perhaps a case to be made for not signing "Resent-"
header fields on the basis that this is really a trace header
field. There's pros and cons on that, I personally lean towards
limiting the number of exceptions (and anyway I can imagine an
MUA that notes the Resent- values and displays email
differently).
e) Some people find that having "List-" header fields signed is a
real nuisance and when messages flow from one mailing list into
another then DKIM1 signatures fail because they have to be
modified. Since DKIM2 has its modification algebra there seems
no reason to special case "List-*" ... these header fields can
be signed as when they are added, and if changed then this is
documented in the standard manner.
f) no other exceptions have occurred to us: so the exceptions list
is effectively "Received", "DKIM*", "ARC-*" and "X-*".
Finally, it is often suggested (albeit I am unsure how common it
actually is today) that there are systems that reorder header fields as
they handle emails. We can tolerate this by the expedient of saying that
we will sign header fields in the alphabetical order of their header
field names.
Note however that header fields with the same header field name need
to remain in their original order (or at least be restored to that
order before (re)signing or verifying.
We could relax the "remain in order requirement" if our sorting prior to
signing was to consider the whole header field, but this leads to
significant implementation complexity when header fields are wrapped (or
relaxation algorithms relating to white space are considered) and it
seems like poor engineering to add all that complexity for what is
likely to be a hypothetical case.
- --
richard @ highwayman . com "Nothing seems the same
Still you never see the change from day to day
And no-one notices the customs slip away"
-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1
iQA/AwUBaMsnIGHfC/FfW545EQLE7wCeLEX9HQAPmil4WZe1eB9EsGfr1Q0AoIWV
V8hYAWS0imileuIDaAEY05Pf
=YKv2
-----END PGP SIGNATURE-----
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
