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

[[e-mail]]

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

> Just to be clear, this is not what I was proposing.  Specifically, I don't
> think the Robustness Principle
> <https://en.wikipedia.org/wiki/Robustness_principle> applies in this case.
> Verification should check the RFC defined spacing, ordering, etc. of the
> tag/value pairs and reject non-compliant values

> As this is a new protocol, and these headers are all new and used
> exclusively for ARC, and for the reasons mentioned by Ned, there's no
> reason to be lenient in what is accepted.

On the contrary, there are very good reasons. People aren't going to magic
up implementations of ARC out of nothing; they will undoubtedly use
existing DKIM code as a starting point. Implementing an ordering
requirement on top of such code could get interesting depending on how
it works.

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.

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


> A few quick comments on this.

> As per my earlier email, I have a lot less confidence in how well this
> 'seemed to work' than some of the other participants in this thread.  One
> of the benefits of DMARC re:DKIM is it has exposed some issues with DKIM
> implementations that were not obvious prior to DMARC evaluation.  Without
> DMARC reporting some of the problems with certain DKIM implementations were
> simply not very visible.  So I don't actually think the DKIM model worked
> as well as is being asserted.

Which of these problems had anything to do with field ordering? Which of
these problems would have been exposed by requiring a specific
order?

> Second, the existence of such a test suite would have had material benefits
> just within the last ~18 months over which ARC implementations have been
> developed.  We know this because of the immediate benefits the current test
> suite (which does impose a canonical ordering, spacing, etc.) yielded
> almost immediately.

> The suite exposed a few minor but significant issues with the Python
> implementation that was submitted to dkimpy.  Similarly, it exposed that
> the current OpenARC signing functionality is in a much less mature state
> than was generally understood.  In terms of RFC definition, it exposed the
> fact that the current RFC as written required support for insecure 512 bit
> keys - and triggered a discussion on this very list.  In our internal
> development it's forced us to look hard at some of the corner cases and
> raise them on this list or at interops.  Note that most of these issues had
> escaped detection through multiple interops.

> None of the above is meant to insult the associated developers or spec
> authors.  Their contributions have been essential, and the skill and
> dedication they've brought to their tasks is greatly appreciated.  It is
> simply meant to demonstrate the material benefit that this kind of testing
> has already brought.  This is what automated tests do - bring problems to
> light quickly.

> So yes, I think this approach works better.  Much better.

Simply put, I don't. I'm strongly opposed to this, to the point where I'm
likely to significantly deprioritize implementation of this proposal because of
it.

I have better things to do that waste my time watching the sorts of bugs this
is going to cause get shaken out.

				Ned