Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value

[Seth Blank <[e-mail]>]

On Thu, Mar 30, 2017 at 7:01 AM, <[e-mail]> wrote:

> > On Mon, Mar 27, 2017 at 11:49 PM, Scott Kitterman <[e-mail]>
> > That sort of organic validation of implementations seemed to work for
> > DKIM.  The unknown here is whether ARC will be as successful with that
> > model.
>
> Exactly. And given the success of the approach with DKIM, the burden is
> on those proposing to use a different model for ARC to explain why it will
> work better.
>
> And note that "this kind of test becomes possible" is not sufficient. All
> kinds of tests become possible when you add constraints - the question is
> what sort of real world problem will those additional tests find.
>


ARC is fundamentally different than DKIM in several key ways. If we were
only talking about ARC Signing messages, I'd generally agree with the
comments on this list.

However, ARC is fundamentally different. It is about a chain of messages
that validate each other. And ARC's complexity is not in the signing (where
most of this conversation has been focused), but in this chain validation
and the cascading issues that can be created by any member of the chain
doing something slightly wrong. And since *everyone* in the chain except
the initial signer is also a receiver, the final receiver simply can't make
up for mistakes caused by a less savvy intermediary - the chain will
already be broken and unrecoverable.

ARC also has a lot of subtlety that is missable at interops because of
this. For instance, if I'm modifying a message, I need to validate the
incoming chain, then make my modifications, and then sign the outgoing
message. An intermediary doing this wrong (say, validating and then signing
after message modification) isn't a bug a final receiver can fix. And
without a seriously complex interop with a ton of intermediaries and
sending relationships mapped out for testing, it's not likely an error in
any specific implementation here will be discovered until it's too late.

To my understanding, working on the test suite shook these issues out
because they were what caused problems running the test suite at the
interop in the first place. So this is actually a good and healthy part of
the process, and is the natural consequence of the interops. What worked
here for DKIM is insufficient with the nuances of ARC.

What we've been discussing doesn't just guarantee a test suite can be made
that works for everyone (which is huge in itself), but constrains the
problem space for everyone involved in an ARC chain. This is clean and
desirable.

Since the spec isn't finalized, this is the perfect time to impose some
order that isn't necessary for DKIM but is critical when we're talking
about multiple operators working together over multiple hops as part of a
chain of trust.

Seth

-- 

[image: logo for sig file.png]

Bringing Trust to Email

Seth Blank | Head of Product for Open Source and Protocols
[e-mail]
[phone] <415-894-2724>