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

[Gene Shuman <[e-mail]>]

Hi All,

Based on a conversation I had with Murray the other day, I'd like to revive
a conversation I'd started on the ARC discuss forum a few months back.
Basically there is a subtle issue present in the current ARC draft that
doesn't exist with DKIM that I don't think most people are aware of that
gives implementor a large degree of control over ARC-Seal b= values

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.  Basically, the ARC-seal b=
tag *is not deterministic* based on the incoming message.  This hash value
is *implementation dependent.*  I think that we want to think about this,
as this state of affairs does not exist in DKIM.  In DKIM(for a given set
of headers to sign, etc), there are only one valid b= & bh= hashes.

Here are some details.  Message 1 comes in with no arc signature.  The
implementation creates an ARC-Message-Signature tag, which is basically
just a DKIM signature.  Given, timestamps, header list, selector, domain,
etc, there is exactly one way to compute both the b= & bh= tags.  However, *the
*implementation* is free to vary the text representation of this signature*.
There is no sort of canonicalization happening here.  The implementation is
free to order tags arbitrarily, and things like add additional tags &
whitespace.

The reason this matters is because the textual representation of this
signature is used in the ARC-Seal's b= computation, making this value
*arbitrarily
implementation dependent.  *The implementation has a very large degree of
control over the actual value of the ARC-Seal b= hash, and this seems like
a non-trivial security risk.

The obvious solution I see here is to canonicalize the headers going into
the the AS computation.  There are some pretty sensible ways to do this.