On 5/2/2014 1:05 PM, Fred Baker (fred) wrote:
> As an example of the case that comes to mind, see attached. It is a
> message sent to v6ops@xxxxxxxx yesterday. The sender signed it
> using DKIM, the IETF changed the message (added some trailing text)
> before forwarding it, the receiver (e.g., Cisco IT) attempted to
> validate the DKIM signature - and failed.
>
> It seems to me that we should not approve a procedure that has that
> effect, at least without some guidance for mail relay
> administrators. I could imagine two forms of guidance: “obey the
> end-to-end principle; don’t change the message the originator
> sent”, or “if you change a signed message, first validate the
> message you received and discard if that fails, change it, and then
> sign it yourself, so that a receiver can see who changed it and
> validate the outcome”.
Fred,
Your comments are consonant with the recurring comments of others, so
it's worth repeating several fundamental points about them:
1. The so-called "end to end principle" was actually labeled end
to end /arguments/. It is a guidance about a design approach that
then needs to be tailored to the specifics of the situation. For
example, the definition of 'end' varies according to the scenario.
With direct, person-to-person email the mailbox is an end point. For
EDI over email, it isn't, since there is a further processing sequence
after email delivery. So we need to be rather careful when asserting
the 'principle'. In the IETF, we've grown fond of tossing out the
label as if its mere statement is useful. However it's actual utility
only happens as part of a tailored design discussion. Like a
protocol, its utility requires being set into motion.
2. In terms of basic email architecture, a mailing list is an
end-point. The author specifies the mailing list explicitly. The
mail gets /delivered/ to it. A mailing list is not an MTA that is
relaying mail; it is an end-user application that /re-/posts it. So a
mailing list is really a value-add mechanism that sits above the basic
email service. In architectural terms, this is identical to your
choosing to forward this note to someone you think should see it.
DKIM is meant for transit protection, starting somewhere near the
(original) author and ending somewhere near the mailbox of the
specified (initial) recipient. In the case of a mailing list, that
mailbox belongs to the mailing list. Should a DKIM signature survive
your manual forwarding of a message? While it's certainly acceptable
for it to survive, it's not reasonable to expect it. Then why should
we expect the re-posting by a mailing list to preserve a DKIM
signature? Depending upon the policies of a specific mailing list,
there are many very good reasons for the changes that are made to the
original message. Some of those happen to break a DKIM signature.
3. The limitations of DMARC have been well understood, including
by both Yahoo and AOL. There is never any way for the IETF community
to protect against an organization's choosing to apply a protocol in a
way that is known to have damaging effects.
4. There is, in fact, a draft BCP about DMARC use that was
posted and awaits pursuit, preferably in the IETF.[1] Working on it
got stalled by the gyrations of trying to decide how to process the
DMARC base specification. Perhaps we should focus our energies into
firing up an IETF engine to develop and progress the BCP?
d/
[1] Using DMARC, https://datatracker.ietf.org/doc/draft-crocker-dmarc-bcp/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net