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

[Peter Goldstein <[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.

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

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.

Best,

Peter


>

-- 


[image: logo for sig file.png]

Bringing Trust to Email

Peter Goldstein | CTO & Co-Founder

[e-mail]
+1.415.793.5783