-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In message <[email protected]
>, Bron Gondwana <[email protected]> writes
>I've been thinking more about the strong objection to "explicit list of signed
>headers", which is that a new header, e.g. `Message-Evil: no` could be created
>by a new draft and have very important security properties, but the sending
>system doesn't know that and hence doesn't include it (as blank) in the signed
>set of header fields, and then a later system could add it, and that would be
>bad.
The strong objection is that ANY header (including well-known ones) has
a security property that the original signer is unaware of (or does not
consider carefully enough) and they fails to sign that it is absent (or
indeed that it is present)
As was pointed out "in Montreal", it is difficult for a message
originator to know whether or not the form of a particular will or will
not affect the security of (the presentation of / the handling of) a
message at another site
Hence asking for all headers to be signed is the cautious thing to do
(and we are building an email security system here so cautious is wise).
For reasons of practicality (and simplicity) "all headers" should not
include:
Received
Return-Path
these are added during transmission solely for diagnostic
purposes so signing them adds complexity to no purpose
X-*
these header fields have no meaning outside the site that adds
them (and no "new header fields" can start X-) so they can be
excluded. This is pf significant practical help to numerous
sites that add these for their own internal purposes and would
otherwise have to document their addition
DKIM1-Signature
ARC-*
if these are not excluded then DKIM2 header fields could have to
be added after these header fields were added, and forcing an
ordering onto the application of signatures seems unnecessarily
restrictive
>This does require some clever security considerations and correct
>implementation, but I think my answer is:
>
>If a header field is not signed by the current instances, then can be assumed
>to
>be blank in all previous instances. Any instance signing a header field which
>was not signed by the previous instance is assumed to be adding it; and
>receiving systems MUST NOT assume it was present before.
>
>The latest signed copy of that header field MUST be used for any security-
>related purpose, so if
>
>`Message-Instance: i=1` didn't sign it
>`Message-Instance: i=2` did sign it, with value 'yes'
>`Message-Instance: i=3` didn't sign it, but changed it to "no" with
>instructions
>how to convert back
>
>Then the signed value is "yes", and that's the only value which can be used
>for
>anything security related, and only when attributing it to the system which
>signed `i=2`.
This deals with "new" header fields -- but it does not deal with an
originator who cannot be bothered to sign a particular header field and
later on the header field is removed or changed -- this is not safe.
To repeat the example I have given before, a very large online retailer
does not sign Reply-To: because they don't generally use this header
field; a very large online payment provider does (doesn't do) the same.
Since the latter has had a very significant DKIM replay problem of
recent times (because they have been unable to prevent bad people from
signing up for accounts and sending out fictitious invoices), this is
IMO borderline negligent.
>I believe this is actually sufficient for good security, it doesn't mandate
>that
>any instance sign ANYTHING in particular, only the things for which it
>requires
>attribution. And of course if you modify anything which was signed by ANY
>previous instance, you have to provide the algebra to convert back to the
>value
>it had. Those algebras don't need to be signed because they either work or
>they
>don't.
I disagree ... unless you think people are going to reject mail where a
Reply-To: header field is present but there are no signatures for it.
- --
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/AwUBaSzf+2HfC/FfW545EQJjHQCdEEaC3Sn9IwBwIrmuxeGlodMRPYEAnj44
j+YeNXGzBAJmDLzkh9OqDugD
=UePO
-----END PGP SIGNATURE-----
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
