On Sat, 12 Aug 2017, at 10:36, Kurt Andersen (b) wrote: > Splitting out this discussion point into a new thread... > > On Fri, Aug 11, 2017 at 5:27 PM, Bron Gondwana > <[email protected]> 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 protected]> 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. 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. > 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). 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 protected]
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
