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

[Gene Shuman <[e-mail]>]

Ah that had slipped my mind & is a good point.  However, I think the issue
here is generally that ARC is more complex protocol than DKIM and therefore
it's more important to reduce ambiguity & increase standardization while we
have the chance.  I think this is generally a good idea from a security
perspective, however this is mostly relevant with respect to testing &
validation, as ensuring cross-compatibility is a much bigger challenge.
It's even more important than it was with DKIM to have a test suite that
can verify signing behavior.  If we don't agree on any sort of standard, a
test suite will need to select a preferred format for the ARC headers &
will fail all implementations that don't meet this form.  We've discussed
this with Murray, and he agrees with this conclusion.

Our belief is that, given this is a new standard and all of the
implementors are on this list, it makes the most sense to define the
tag/value behavior strictly in the RFC.

Thoughts?

On Fri, Mar 24, 2017 at 2:23 PM, John Levine <[e-mail]> wrote:

> In article <CANtLugO_D1Mz_v_341pc5O1mZ7RhOTrFA3+Ob5-onp72+
> [e-mail]> you write:
> >The issue is that its possible for two separate arc implementations, given
> >the exact same message inputs, keys, timestamps, etc to be generating two
> >different, but equally valid ARC seal hashes.
>
> DKIM does the same thing.  The order of fields in a DKIM-Signature
> header is arbitrary, and the b= hash includes that header, so there
> are lots of different equivalent DKIM signatures for the same message
> and same selector and key.  Verifiers use the DKIM-Signature header in
> the message so they get the same answer as the signer, which I would
> think would work the same way in ARC-Seal.
>
> Can you explain why you think this is a problem?
>
> R's,
> John
>