Subject: Re: [dmarc-ietf] Readability and some technical remarks on draft-ietf-dmarc-arc-protocol-08

From: Brandon Long <[email-masked]>
Date: Wed, 23 Aug 2017 15:29:19 -0700

We did discuss a diff based approach in the past, but ran into issues.

Thread here:
https://mailarchive.ietf.org/arch/msg/dmarc/_soxy-2IPCbXuV5aET9z4RFnG4o

The problem happens when we try to enumerate all the ways in which messages
can be modified during forwarding.

I agree, that if all we cared about was the 99% mailing list case, then
we're talking subject markers and footers, which would be pretty easy to
handle.

If we start getting into the final 1%, we're looking at things like
stripping attachments, and including the attachment in a diff basically
defeats the purpose of removing them.  Or, some mailing list providers like
Yahoo Groups allow the moderator to edit the message, including the diff
there also defeats that (whether such features are a good idea or the
result should actually authenticate as the original author is it's own
debate, of course)

If you go beyond mailing lists, you also run into more things like URL
rewriting or S/MIME de-encapsulation which could also result in large diffs.

There is an argument to be made that handling the 99% mailing list case
simply and effectively would be a better choice, and maybe there are N
solutions for the top M DMARC breaking issues, and even the complete set of
M is a better choice.

Brandon

On Wed, Aug 23, 2017 at 12:27 AM, Rick van Rein <[email-masked]>
wrote:

> Hi,
>
> Enhancing my own remark with example text:
>
> > 11.
> > As a design alternative, catering to those much-cheaper forwarding
> > structures, has it been considered that a "diff" style header could be
> > inserted much more easily? This would inform the recipient with
> > information that could be presented in colour, for instance, seeing that
> > the intention [of DMARC] is to protect that what is shown to the user.
> > Since we're mostly talking of inserted "[listname] " in the Subject:
> > header I wonder if ARC isn't a bit going over the top -- as well as
> > limiting the ability to judge where things went wrong. At the same
> > time, I do believe that the improved privacy of being able to drop
> > information from the headers can be valuable (as long as someone takes
> > responsibility over it).
>
> I worked out a ROUGH SKETCH of how a diff-based approach would look.  It
> could save a lot of work, both in the simplistic forwarders / lists and in
> the validation nodes.  I could work to get this more accurate if you think
> it is a valuable approach.  IMHO, it is simpler and that can be better for
> some use cases.  IMHO, it should not replace current ARC headers but could
> be useful to augment it.
>
> Cheers,
>  -Rick
>
>
>    5.4.  ARC-Patch
>
>    The ARC-Patch header indiciates changes that have been made to the
>    message while in transit.  Headers are inserted at the top in the
>    order of occurrence, and can thus be unwound by going over the
>    headers in their order of appearance in the header list.
>
>    An example application is the insertion of a list name in the Subject
>    header, with:
>
>    ARC-Patch: Subject /^/[Katy] /
>
>    This would transform a Subject header value "Something Like A Song"
>    to "[Katy] Something Like A Song", which is considered helpful by
>    list members, but which also breaks DKIM signatures.  Changes to the
>    body are written as : for the entire email body, or :1 for the first
>    element in a multiple-entry MIME form, :1:2 for the second of the
>    first, and so on.
>
>    Upon presenting content to email users, these differences are helpful
>    in colouring the text presented.  At the same time, they can be used
>    to reverse the changes and return the text to values that can be
>    validated based on their original signature, whether made with DKIM
>    or ARC.
>
>    I-D NOTE: Regular expressions can be kept as simple as possible to
>    make their reversal really simple.  Examples of this include
>    mentioning the line number instead of just ranging over a body;
>    mentioning /KateBush/Katy/ instead of /(K[a-z]*)eBush/\1y/ and so on.
>    It is however possible to reverse even such a patch to a form by
>    swapping (...) and \N to derive /(K[a-z]*)y/\1eBush/ as a reversal of
>    the form.  The trick of specifying this well will be to balance
>    simplicity in the most simplistic mail handling nodes against
>    efficient handling in the mail validation nodes.
>
>    In general, multiple patterns may occur in each line, in the order in
>    which they are applied; upon reconstruction of the original text, the
>    order should be reversed.  Furthermore, the reversal involves
>    matching the pattern of the outcome, which may lead to more matches
>    than desired; to accommodate for this, the matches in the output that
>    should be mapped may be specified in a list of numbers in [N,M,O]
>    form.  Each pattern may be preceded with a line number to which it
>    applies.  Patterns should not span multiple lines; they should then
>    be represented as multiple patterns, each modifying one line.
>    Provisions are made for inserting and removing lines.
>
>    The ARC-Patch header may be released together with (TODO: before,
>    after, between?) a triple of cryptographic ARC headers, but it may
>    also be released independently.  In general, a server passing a
>    message with modest modifications can use this mechanism to avoid the
>    overhead of cryptographic message handling.
>
>

---

From: Brandon Long <[email-masked]>
Date: Wed, 23 Aug 2017 15:40:17 -0700

On Tue, Aug 22, 2017 at 10:41 PM, Rick van Rein <[email-masked]>
wrote:

> Hello,
>
> Thanks for the work on ARC!
>
> I would like to share a few remarks about
>
>
>   draft-ietf-dmarc-arc-protocol-08
>
> that could improve its readability, and then there is one technical
> remark.  I apologise if things are due to reading it not intensely
> enoughh, but that is only a sign that I find the draft difficult to read.
>

[snip]

>
> 11.
> It is not clear to me how the market forces would work in getting all
> those low-cost / low-effort email forwarding arrangements to implement
> this (somewhat complex) technology.  Just the fact that keys have to be
> hunt in domains, presumably by users at the level of understanding of
> forwarding, sounds like an irrational dream to me.  What is the
> intention of ARC in that respect?  Is the intention to push such
> situations out of the Internet [basically breaking email functionality]
> or to use SPF (without DMARC's additional envelope.From==header.From
> check) and/or to trace back Received headers on an incoming "real" mail
> deal?  What would then be the expectations of SPF on the forwarding mail
> domain?  These kinds of impact on the email landscape are incredibly
> important, especially because ARC intends to resolve them -- by being
> rather heavy-weight.
>

I really don't understand what you're saying here (hunt in domains?)

For one, most forwarders, especially the low-cost / low-effort ones, don't
modify mail when forwarding, so there is no DMARC issue.

If they do modify mail, they're already hurting today.

It's also true that the email ecosystem of today is more complicated, and
although you can just send mail from anywhere, it's not clear that anyone
will accept your mail without effort.

The keys put in domains are already a requirement for DKIM, which, if not a
requirement for sending, is a good step at getting your mail accepted
anywhere.

No one's trying to push anyone out of the Internet, but sometimes the bar
for participation is raised.  And no one's saying that ARC will be a
requirement for anything.

One could argue that ARC usage by the larger providers actually allows you
to send mail with only SPF auth and not DKIM, since the SPF auth will be
forwarded with ARC.  Probably be a long time before that can be relied on.

As for the rest of the paragraph about SPF and whatever... it sounds like
you're proposing an alternative or something.

As for the heavy-weight issue, managing a key is the same weight as it was
for DKIM, which isn't to say that most people get it right (someone should
make a lets encrypt style system for managing DKIM keys, it wouldn't be too
hard to do).  The rest is handled by the software, and frankly, although
the software may be a bit tricky to get right, I wouldn't expect the
low-cost / low-effort folks to be writing their own, they'll install
something already written and use it.  And that software is much less
complicated than say the TLS software they are also hopefully using.

Brandon

---

From: Rick van Rein <[email-masked]>
Date: Thu, 24 Aug 2017 08:12:21 +0200

Hi,

> Brandon Long <mailto:[email-masked]>
> 24 August 2017 at 00:40
>
>
> On Tue, Aug 22, 2017 at 10:41 PM, Rick van Rein <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hello,
>
Typo.  "hung" in domains.

> For one, most forwarders, especially the low-cost / low-effort ones,
> don't modify mail when forwarding, so there is no DMARC issue.
>
I've seen at least one that touches the subject, and as a result they
have serious problems.

> If they do modify mail, they're already hurting today.
Yep.  Which is not the same as saying that it's acceptable -- ARC is
supposed to help overcome that kind of pain, after all.

> It's also true that the email ecosystem of today is more complicated,
> and although you can just send mail from anywhere, it's not clear that
> anyone will accept your mail without effort.
>
> The keys put in domains are already a requirement for DKIM, which, if
> not a requirement for sending, is a good step at getting your mail
> accepted anywhere.
>
I'm not fighting with the ideas of using crypto.  I'm only stating that
there may be a much lighter-weight alternative that could increase the
chances of getting the simpler forwarders on board.

> No one's trying to push anyone out of the Internet, but sometimes the
> bar for participation is raised.  And no one's saying that ARC will be
> a requirement for anything.
>
It would be sad to raise the bar without a need.  Hence the
alternative.  In practice, ARC will be a requirement for reliable delivery.

> One could argue that ARC usage by the larger providers actually allows
> you to send mail with only SPF auth and not DKIM, since the SPF auth
> will be forwarded with ARC.  Probably be a long time before that can
> be relied on.
>
"only SPF" -> "only SPF and a matching From in envelope and header"

> As for the rest of the paragraph about SPF and whatever... it sounds
> like you're proposing an alternative or something.
>
Yes, though I'm not sure if it would be added on the same nodes that
also do ARC, or on intermediate nodes.

> As for the heavy-weight issue, managing a key is the same weight as it
> was for DKIM, which isn't to say that most people get it right
> (someone should make a lets encrypt style system for managing DKIM
> keys, it wouldn't be too hard to do).  The rest is handled by the
> software, and frankly, although the software may be a bit tricky to
> get right, I wouldn't expect the low-cost / low-effort folks to be
> writing their own, they'll install something already written and use
> it.  And that software is much less complicated than say the TLS
> software they are also hopefully using.

I agree with all that.  It's just leaning on parties that hardly have a
model of earning an income (forwarders, unlike the senders and
recipients of email) that I find unwise.  Which made me think of an
alternative.

-Rick