-----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.
- -=-=-=-=-=-=-=-=-=-=-=-=-
>> 4.5. The "mailing list DMARC issue"
>>
>> *Issue:*
>>
>> Once an intermediate (for example, a mailing list or alumni
>> forwarder) makes a change to the header or body of a message, the
>> hashes covered by the sender's DKIM signature no longer match, and
>> it's not possible to see whether the message is semantically similar,
>> or has been completely replaced by a bad actor.
>
>Breakage depends on whether DKIM was covering the portion that got changed.
>
>If preservation of the content is that important, use a content-protecting
>mechanism that is more likely to survive a re-posting. Choices are already
>available, and have been for decades.
>
>If you don't like the choices, consider defining a mime-based protection
>mechanism that is independent of DKIM, while re-using DKIM's design approach.
>
>My guess is that the concern stated here is rather more specific than is
>stated.
It could be argued that only people who attend IETF meetings care about
this issue, everyone else has mitigated it and moved on ... however, it
is in the Working Group charter so it is going to be tackled
>> *Mitigation:*
>>
>> DKIM2 will define an algebra for describing how to reverse any
>> changes to create the prior binary data, by inspecting the diff
>> between the two versions, recipients will be able to see who injected
>> bad content.
>>
>> Mailing lists (or alumni forwarders etc.) that alter the Subject
>> header field (or other [RFC5322] headers) will record the previous
>> header field contents. This is easy to undo for checking purposes.
>>
>> Mailing lists that add text (either to a simple email body or one or
>> more MIME parts within the body) will record details of the text they
>> have added. This text can then be removed when checking earlier
>> signatures.
>>
>> We expect the "algebra" describing changes to be in a stand-alone
>> document that need not be finalised on the same timescale as DKIM2
>> itself.
>
>This is going to cause significant collateral damage, as its use becomes
>ingrained and/or widespread:
>
> This is going to define a set of 'acceptable' changes by
> intermediaries and will result in calling other changes a 'problem'
> or even an 'error'. (cf, calling legitimate From: addresses
> 'spoofed'.)
>
> *This will further marginalize mail that is entirely legitimate, but
> which does not fit into an increasingly Procrustean model.*
I think these are comments which you should put into a review of
draft-gondwana-dkim2-modification-alegbra
rather than here, in particular that document does not currently
constrain changes in any way...
>> 4.6. Security gateways
>>
>> *Issue:*
>>
>> There are some types of alteration, for example by security gateways,
>> that may be impractical to describe in a cost-effective manner.
>
>huh?
"I have removed this malware attachment"
I discuss this topic more in another email
>> *Mitigation:*
>>
>> We would expect that outgoing gateways that may be adding disclaimers
>> or rewriting internal identifiers would be provided with appropriate
>> signing keys so that they could be the "first hop" as far as the rest
>> of the email handling chain is concerned.
>>
>> Incoming security gateways may be making substantial changes.
>> Typically they will remove problematic types of attachment and
>> rewrite URLs to use "interstitials". Since this type of
>> functionality is generally provided on a contracted basis further
>> intermediaries will be fully aware of the presence of the security
>> gateway and can be configured to implicitly trust that it has checked
>> earlier signatures and found them to be correct. Hence there is not
>> need to be able to "undo" these changes.
>
>So, ummm, this problem isn't really a problem?
It's not a problem that the modification algebra is going to tackle
>> 4.7. Addressing DKIM-replay
>>
>> *Issue:*
>>
>> Because an email can currently be sent as "Bcc" such that there's no
>> evidence in the message data of who the recipient is expected to be,
>> it's possible to take a message that is correctly signed and replay
>> it millions of times to different destination addresses as if they
>> had been BCC'd. This message can be resent at any time.
>
>Using BCC does not create this ability. Any recipient -- whether listed or
>not
>-- can replay a message, if they have adequate control of the re-posting
>service.
>
>Using BCC hides the address from recipients, but there is little or no
>evidence
>that that affects recipient behavior. (Other than, perhaps, their sometimes
>wondering why they got the message.)
We agree that saying "bcc" doesn't really illuminate anything ... since
what is happening occurs at the RFC5321 layer not RFC5322.
We will recast the text at the next iteration to eliminate the
confusion.
>> *Migitation:*
>>
>> DKIM2 headers will always have timestamps so that "old" signatures
>> have no value.
>
>Reports of replay attacks have indicated that replay can and does happen, well
>within normal email handling time-frames. So the timestamp is of no help.
it does help with mitigation techniques (which may still be useful in a
DKIM2 world if attacks continue -- which they may not since they will be
far less likely to be widely successful)
>> DKIM2 headers specify both "from" and "to" so that most opportunities
>> to alter a message, re-sign it and replay it at scale will no longer
>> be possible.
>
>This is the more powerful approach to replay mitigation. As long as one copy
>per addressee is acceptable.
>
>Where does the DKIM2 receiver get the addressee info from, to use for
>signature
>evaluation?
from the SMTP conversation ... viz: the 5321 layer
>> Since the "to" address is always encoded in the email,
>> any email to multiple recipients must be exploded by the sender, and
>> each copy signed separately with different headers.
>>
>> If the email is replayed (perhaps through a large system with many
>> different customers) then if the email does not say that it has been
>> duplicated then signatures can be assumed to be unique and hence
>> simple caching (or Bloom filters) will identify replays. If the
>> email has been duplicated then recipients can assign a reputation to
>> the entity that did the duplication (along with the expected number
>> of duplicates that will arrive from that entity) and assess duplicate
>> signatures on that basis.
>
>How will it know which site did the duplication, given the possibility of
>multiple hops after duplication?
It cannot know for sure ... but constructing a reputation is always a
matter of weighing evidence and detecting patterns.
>> If the email is altered before duplication then it is again the case
>> that this will be apparent to the recipient who can develop a
>> reputation system for the entity that did the modification and
>> replay.
- --
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/l1bmHfC/FfW545EQLabgCfSqLMIrnYFq3DuOpFOnLZcT+mxjEAn3s/
zU9dmn01UDKKfS33/3lH1xkz
=uFH5
-----END PGP SIGNATURE-----
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
