-----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.2. Preventing backscatter
>>
>> *Issue:*
>>
>> With DKIM1, you can send delayed bounces if the message has come
>> directly to you and the DKIM signature is DMARC aligned, but
>> otherwise you need to reject at SMTP transaction time to ensure you
>> won't be creating backscatter.
>
>What is a 'delayed bounce'?
a DSN (Delivery Status Notification)
> *DKIM has nothing to do with bounces. Really. Nothing.*
>
>Nothing 'requires' rejection at SMTP transaction time.
Perhaps you could explain how backscatter is avoided if you do not
reject at SMTP transaction time ? We give one example of how you can
currently avoid it, but it makes assumptions that do not always hold
>Rejection at transaction time merely moves the question of sending a bounce
>from
>the server SMTP, after the session, to the client SMTP, contemporaneously with
>the session. Or also after it.
yes, but presumably the client SMTP system has some reason for believing
it should be handling the email in the first place -- so it is far
better placed in deciding whether a DSN is appropriate
>In the overall, global model of multi-handler email, this distinction is
>pretty
>minor. It might be deemed significant only in a highly constrained,
>single-hop
>scenario. But even then, well...
>
>> *Mitigation:*
>>
>> Provided that an email is correctly signed when received, it can be
>> rejected at a later point in time. The DSN will be sent to the
>> immediately preceding intermediary. Since the bounce travels back
>> along the (fully authenticated) incoming path it cannot be sent to an
>> uninvolved third party.
>
>So, the model is a per-hop signing sequence that is used in reverse to send
>bounces back through every /relay/ that handled the message?
>
> *This is quite a fragile operational model.*
why is it fragile when the cryptography gives assurance as to which
entities are taking some "responsibility" for the email ?
>Note that source routing has been largely deprecated in modern networking, yet
>this scheme relies on it.
it is retracing the outgoing path -- so it is not source routing
>If someone thinks there is promising operational history with this model,
>please
>provide citations.
Tor works this way
Dingledine, Roger, Nick Mathewson, and Paul F. Syverson. "Tor:
The second-generation onion router." USENIX security symposium.
Vol. 4. 2004.
there's a lot more papers, that will get you started
>> 4.3. Improved privacy for forwarders
>>
>> *Issue:*
>>
>> If you want to create a privacy preserving forwarding service, you
>> need to SRS rewrite the email's bounce address so that bounces don't
>> accidentally leak the real address of the recipient.
>
>This is presented in a fashion that does not adequately describe the context
>for
>the concern.
we should definitely make our document longer in due course
> *Also, I believe it is a wholly new functional requirement, lacking
> any history of community concern. *
>
>Feel free to provide documentation to the contrary.
I am told that major German ISPs do not send DSNs when relaying from
their system to another system fails -- on the advice of the lawyers who
believe that GDPR violations may occur.
>To suggest a more complete foundation and to test whether I understand what is
>intended:
>
> When a message is re-posted, such as by an aliasing or mailing list
> service, the original author will not necessarily know the address
> of the final recipient. If there is desire to keep the original
> author from knowing that (new) address, then a bounce message
> created during this later processing MUST NOT have the original
> RFC5321.Mail-From return address. Otherwise, the original author
> might see this later recipient address in the bounce email.
yes, that's what we are on about
>> *Mitigation:*
>>
>> Since the DSN messages always go back up the DKIM2 chain, any hop can
>> strip off the higher number (i=) records; including the sender and
>> recipient addresses for them, and create a bounce as if the forwarder
>> itself was doing the rejection. As asynchronous bounces will be
>> common in DKIM2, this is indistinguishable to the sender.
>
> *This is quite a lot of unnecessary mechanism, for this purpose,
> absent a much larger system-wide goal for hardened security and
> privacy functions. *
>
> *To date, there is no specification for such a service. That makes
> the requirement, here, frankly arbitrary.*
>
>Replacing an SMTP Mail From with a different address is appropriate for a
>number
>of cases. It is simple and effective. It is also already quite common.
>
>The current scheme is much more complicated and does not seem to provide an
>improvement.
>
>How is i= relevant to this?
later (in time, and higher i= values) of DKIM2 header field
>What does it mean to be a 'higher number' i=
>record? The text here appears to rely on some extensive detail that isn't at
>all
>obvious to me. I suspect it won't be to other readers. (From reading much
>farther down, I gather it's the sequence number, except that the nature and
>use
>of the sequence number is not explained. E.g., sequence of what?
yes, we should explain what i= means before using it... and the i=
values are ascending integer values (with no gaps)
- --
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/l032HfC/FfW545EQLO7wCggAOLmQHETJWkMeb9L5XdjvFyX4oAniWX
yy1Xo3XUJw3/A4UNAS9eIFIm
=yJRY
-----END PGP SIGNATURE-----
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
