Subject: [dmarc-ietf] ARC signing when *not* modifying the message...

From: "Kurt Andersen (b)" <[email-masked]>
Date: Fri, 11 Aug 2017 17:36:27 -0700

Splitting out this discussion point into a new thread...

On Fri, Aug 11, 2017 at 5:27 PM, Bron Gondwana <[email-masked]>
wrote:

> On Sat, 12 Aug 2017, at 10:16, Kurt Andersen (b) wrote:
>
> On Fri, Aug 11, 2017 at 4:54 PM, Bron Gondwana <[email-masked]>
> wrote:
>
>
> . . . it's a bad idea to sign if you're not modifying, because then
> everybody has to trust you or their chain breaks, even though you didn't do
> anything which required signing.
>
> I would like to address this point, but maybe we should have a separate
> thread for it?  I would strongly argue that sites not changing the message
> SHOULD NOT add ARC headers.  I spelled out the reasons in my initial
> posting on this thread.
>

Various folks in the ARC space have debated this particular point. You make
a good argument from a trust point of view.

The reasoning for our (current) advice to "always" ARC-seal is that not
sealing requires a comprehensive understanding of everything that might
happen within the realm of your ADMD - and that is usually not available
beyond the smallest of realms. By "always" sealing, the ADMD does not have
to worry about whether the message might pass through some previously
unknown internal list or forwarding mechanism which may or may not break
the signature on the received message.

It's certainly possible for an ADMD to ARC-seal upon receipt and then
redact that seal upon egress if the AMS is unbroken, but I'm worried about
explaining that operational nuance effectively (given that it has only
recently become known to some people that the ingress state needs to be
propagated through to the egress sealing process).

--Kurt

---

From: Bron Gondwana <[email-masked]>
Date: Sat, 12 Aug 2017 10:50:49 +1000

On Sat, 12 Aug 2017, at 10:36, Kurt Andersen (b) wrote:
> On Fri, Aug 11, 2017 at 5:27 PM, Bron Gondwana
> <[email-masked]> wrote:>> __
>> 
>>> On Fri, Aug 11, 2017 at 4:54 PM, Bron Gondwana
>>> <[email-masked]> wrote:>>>> __
>>>>   everybody has to trust you or their chain breaks, even though you
>>>>   didn't do anything which required signing.>> 
>> I would like to address this point, but maybe we should have a
>> separate thread for it?  I would strongly argue that sites not
>> changing the message SHOULD NOT add ARC headers.  I spelled out the
>> reasons in my initial posting on this thread.> 
> Various folks in the ARC space have debated this particular point. You
> make a good argument from a trust point of view.> 
> The reasoning for our (current) advice to "always" ARC-seal is that
> not sealing requires a comprehensive understanding of everything that
> might happen within the realm of your ADMD - and that is usually not
> available beyond the smallest of realms. By "always" sealing, the ADMD
> does not have to worry about whether the message might pass through
> some previously unknown internal list or forwarding mechanism which
> may or may not break the signature on the received message.
How does that help?  If there is an internal list or forwarding
mechanism which breaks the signature then you're going to need to ARC-
Seal it again afterwards.
If you added an Authentication-Results header on ingress which you know
is yours because you always add it on ingress (and strip other Authentication-
Results headers), then you can confirm from that header that you checked
ARC on ingress, and then you can ARC-Seal on egress.
At that point any ARC you added on ingress is either unbroken (in which
case pointless anyway) or broken (in which case you need to re-ARC-sign
anyway).  Either way, the ingress ARC is useless.
> redact that seal upon egress if the AMS is unbroken, but I'm worried
> about explaining that operational nuance effectively (given that it
> has only recently become known to some people that the ingress state
> needs to be propagated through to the egress sealing process).
Again - why seal on ingress?  It's bogus.

* check authentication on ingress
* add authentication on egress

That's the pattern that means something and works.  Otherwise your
internal mechanisms are going to have to be either ARC aware anyway, or
you'll have to fix up ARC anyway.
Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [email-masked]

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Fri, 11 Aug 2017 17:54:53 -0700

> you'll have to fix up ARC anyway.

As long as your method of communicating the ingress auth check survives the
transit of your internal infrastructure (which A-R does not necessarily do
as a result of some brain-dead gateway implementations), I agree. Sealing
on ingress is one such way to provide that communication from ingress point
to egress point but is a bit noisy to do so.

--Kurt

---

From: Bron Gondwana <[email-masked]>
Date: Sat, 12 Aug 2017 11:01:06 +1000

On Sat, 12 Aug 2017, at 10:54, Kurt Andersen (b) wrote:
> On Fri, Aug 11, 2017 at 5:50 PM, Bron Gondwana
>> internal mechanisms are going to have to be either ARC aware anyway,
>> or you'll have to fix up ARC anyway.>> 
> As long as your method of communicating the ingress auth check
> survives the transit of your internal infrastructure (which A-R does
> not necessarily do as a result of some brain-dead gateway
> implementations), I agree. Sealing on ingress is one such way to
> provide that communication from ingress point to egress point but is a
> bit noisy to do so.
The obvious thing to do here (something we do in our FastMail
infrastructure) is to add X-orgname-*: headers as required, and strip
them all on egress.  If your infrastructure is that complex, it's
definitely worth doing something with your own custom headers
internally, and by namespacing them  with a common prefix, it's easy to
make sure they don't leak out.
And yes - in that case I would be making our egress system check the X-FM-
AR header to make sure it came in authenticated, and then do an ARC
check of its own to see if the message got modified internally, strip
X-FM-*, and then either add ARC if the message was modified internally,
or just send it with its existing ARC if it was untouched.
Bron.