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

[[e-mail]]

> On Mon, Mar 27, 2017 at 11:49 PM, Scott Kitterman <[e-mail]>
> wrote:

> > What's more difficult to is identify all the ways that things get
> > reordered,
> > mangled, etc as they transit the various elements of the mail architecture.
> > If you over specify the allowed order, aren't you risking increasing the
> > brittleness of the solution.
> >

> I think Peter's proposal (and he can correct me if I'm wrong) is only to
> constrain signers.  Verifiers are still expected to handle everything weird
> that the infrastructure might do.

This proposal creates a situation where verifiers are required to support
something that no compliant signer will generate. The result will be that a
test suite with reasonable coverage cannot be generated using compliant
software.

And since most people are not going to bother to create an incompliant signer
specifically for purposes of testing, if anything this will create, rather than
elimnate, interoperability problems.

> > If test cases are automatically generated, then they are cheap and we
> > shouldn't worry about unduly constraining things to keep the number
> > small.  As
> > long as, at some point, the test cases are validated against multiple
> > implementations, I think it's fine.  If you've got a handful of
> > implementations, then the risk of them all having the same bug is pretty
> > low.
> >

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

				Ned