-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
At the end of January Dave Crocker posted a review of the then current
"-01" version of draft-gondwana-dkim2-motivation. This document has now
been split into an "-02" and draft-gondwana-dkim2-headers (-01).
Rather belatedly this is a response to that review, albeit spread over
14 (sorry) emails... ">>" is a quote from our document, ">" a quote from
Dave Crocker ... lines that do not start with a ">" are me speaking.
- -=-=-=-=-=-=-=-=-=-=-=-=-
>> 6. Checking hashes
>>
>> For clarity this is written as if there is only one hash and
>> signature to check, whereas there may in fact be one for the header
>> and one for the body. Issues with DNS will cause [RFC5321] 4xx
>> responses to be sent.
>>
>>
>> 6.1. Step 1
>>
>> Find the latest DKIM2 signature and determine if the email as
>> received matches that hash AND that you are named as the destination
>> of the email AND that the mail is coming from the named source. If
>> not then refuse to accept the email. The previous hop is responsible
>> for the email (they have either forged it or mangled it -- either way
>> it is their problem).
>>
>> If this check passes then other checks can either be done at delivery
>> time or the mail can be accepted and if later rejected there is a
>> valid path back to the sender over which a DSN can be sent.
>>
>> If it is decided, by local policy, to accept an email where the hash
>> fails (or you are not the documented recipient) then DSN messages
>> back along the chain MUST NOT be sent.
>>
>> 6.2. Step 2
>>
>> Find the first DKIM2 header (numbered 1) and determine if the email
>> as received has the same hash as recorded there. If so, you know the
>> email has not been altered on its way to you. The path it has
>> followed is most likely irrelevant for deciding what to do with it.
>>
>> 6.3. Dealing with modifications.
>
>This is not dealing with the hash. It is a separate topic and should be a
>different section.
perhaps we should entitle the section "message processing" since
checking hashes and undoing modifications have to proceed hand in hand
>> Find the highest numbered DKIM2 header that reports a modification.
>> Undo the modification and repeat. When all modifications have been
>> done then there should be a match with the original signature (at
>> hop1). If not then the email has been altered (in an undocumented
>> manner) on its way to you and it SHOULD be rejected.
>
>Do not embed policy directives in the middle of algorithm specifications.
>
>And the framing of such a directive is not to tell them what they should or
>should not do, but what the signers would like done. The difference has to do
>with authority. The signer has no authority over the site interpreting the
>signature. And the choice of policy to apply after evaluation is /always/ a
>local matter. That is, in terms of protocol specification, the actual policy
>applied is outside the scope of this document.
We agree that we should move discussion of what should be done with
messages where the hashes do not match into a separate section.
Having a correct hash is a pre-requisite for some other aspects of the
overall design (e.g. avoiding backscatter, identifying replay etc.)
So I agree that whether or not to accept an email will always be a
matter of local policy -- but the overall design means that if you pass
the email to another system (or generate a DSN) then the final document
is going to have some SHOULDs (probably MUSTs) about how to handle email
where the hashes are not what is expected.
>> Note that it is not necessary to check the signature on a DKIM2
>> header that reports a modification. Undoing the modification and
>> discovering that the message can now be authenticated is sufficient.
>
>The second sentence is too cryptic. Perhaps:
>
> Rather, reversing the modification it reports should make it
> possible to check the original DKIM2 signature and validate that.
> This makes evaluation of a DKIM signature by the reporting site
> unnecessary.
hmmm... we could certainly be more clear. But I'm not sure that using
the term "reporting site" aids that clarity.
>> Over time a reputation can be developed for a intermediary which is
>> making modifications and given sufficient trust then the "undo" step
>> could be skipped.
>
> *I suspect this document has nothing to do with the nature and
> details of reputation assessment. *
We should probably accumulate all of our comments about what reputation
systems might be able to leverage and place them into the "applicability
statement"
>It is attempting to provide some reliable and accurate information that can be
>used by such an engine, but that's different from this document's offering
>comments about how such an engine works.
>
>> Note that the signature of the DKIM2 header that
>> reports the modification would need to be checked to ensure
>> reputation accrued to the correct entity.
>>
>> If the modification is substantial (eg URLs rewritten, MIME parts
>> removed) and it cannot be undone then the receiver (who may not be
>> the immediate next hop) MUST trust the system doing the modification.
>> If it does not then the mail SHOULD be rejected.
>>
>> It will be noted that some modifications can totally change the
>> meaning of an email. This specification does not try to limit
>> modifications. We believe that being able to attribute modifications
>> to a particular entity will allow reliable blocking of malicious
>> intermediaries once they are identified.
>>
>> 6.4. Dealing with replays
>>
>> Checking source and destination as recorded by the previous hop makes
>> many “DKIM replay” scenarios impossible.
>
>There is more than one DKIM scenario? What are they?
there is some helpful information in the now expired draft:
draft-chuang-dkim-replay-problem-03.txt
>> It is possible to exclude all replays by determining if any DKIM2
>> header reports an expansion event (one incoming email resulting in
>> multiple further emails).
>
>uh... This only works if the expansion platform is run by good actors. While
>replay has been done that way, it isn't the interesting arrangement, since
>that
>path is easily closed.
>
>
>
>> If not then you would expect that the
>> (original) hash of the email is unique and duplicates can be
>> rejected.
>>
>> If a expansion event is recorded then receiving multiple copies would
>> not be a surprise.
>
>To whom? And how is this, somehow, a useful point?
the way in which DKIM replay is currently successfully dealt with is by
counting instances of DKIM signatures. If more than <N> are received
then further copies are rejected. The difficulty is of course
determining a suitable value of <N> ... and that is currently done by a
mixture of heuristics and manual overrides.
having the expansion event documented informs those heuristics
>> It will be necessary to use local policy to
>> assess whether the number of copies received is acceptable or not.
>
>This does not deal with expansion that does not produce many copies to the
>same
>platform.
that is correct ... but the replay attacks that are of concern do
>> Over time you may wish to develop a reputation for a DKIM2 identity
>> which is doing expansions and conclude that a specific number of
>> copies is to be expected. This can be used to refine local policy.
>
>cf, Avoiding discussion about reputation in this protocol spec.
as noted above, yes
- --
richard Richard Clayton
Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755
-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1
iQA/AwUBZ/l1y2HfC/FfW545EQK6EwCfYVyRs5QWehRNIeQwLVOL5RJHj10An1CR
i56tOC1LMzrKGHiddTzL99K0
=iCKk
-----END PGP SIGNATURE-----
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
