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

[Seth Blank <[e-mail]>]

Dave, 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 is not finalized, this is the perfect time to set a
deterministic order for headers that no one has even seen before.

Seth


On Thu, Mar 30, 2017 at 4:15 PM, Dave Crocker <[e-mail]> wrote:

> On 3/30/2017 12:13 PM, [e-mail] wrote:
>
>> And given the relationship with DKIM people are going to expect ARC
>> to work in the same general way, maing such a change a least astonishment
>> principle violation.
>>
>
>
> +10.
>
> This thread has been active for 6 days.  That is 5.5 days longer than it
> should have lasted, and I'm being generous.
>
> Internet technologies succeed through interoperability testing, not
> conformance tests, or the like.  Conformance testing, and the like, are
> useful for early-stage bug-finding, but not for 'certification'.  This
> point has been a distinguishing feature of Internet technical work since
> before the Internet.
>
> ARC is a small re-casting of DKIM.  DKIM has worked for quite a few
> years.  Some details of ARC need to be different from DKIM, but the basic
> paradigm -- including the model of achieving field operation through
> interoperability testing -- should be the same.
>
> My reading of this too-long message thread is that there is essentially no
> support for making ARC's header-related issues any different from DKIM's,
> so I encourage the chair to shut this thread down.
>
> d/
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
>
>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>



-- 

[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>