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

[Brandon Long <[e-mail]>]

On Thu, Mar 30, 2017 at 1:21 AM, Murray S. Kucherawy <[e-mail]>
wrote:

> I have to catch up on the rest of this thread still, but I wanted to chime
> in here to get started:
>
> On Sun, Mar 26, 2017 at 5:23 PM, Gene Shuman <[e-mail]> wrote:
>
>> 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.
>>
>
> I agree that it's impossible to design a signer test suite that confirms
> correct output, without doing crytpo checks of its own with a known-good
> verifier, unless we nail down the syntax the output will use.  For this to
> work, we'd have to mandate a lot of things, including at least these:
>
> - the order of the tags as presented to the hash algorithm
>

This could imply two different things, either "alphabetize them in the
header" like was done for the current test suite, or it could imply a
canonicalization step when passing the header to signing. The latter seems
unlikely to be what we'd want, given we have to sign a whole bunch of ARC
headers, we probably don't want to interpret and sign each one, signing the
string is easier.

And I admit that I immediately disliked the alphabetized list upon seeing
it, the main issue I had was with not having i= at the front, the rest just
seemed ugly (ie, the b/bh tend to be at the end in implementations because
they are long).  That's probably not a valid argument against it, though I
do think that i= at the front is useful for visual grouping without having
to scan the full header to find it.


> - which tags will be present (note that many are not required, including
> "t=")
> - the specific values they will all contain
> - for ARC-Message-Signature, which canonicalization will be used
>

Does this also mean that my signer has to support all four combinations of
canonicalization?  Right now, it only does relaxed/relaxed.  I have no
intention of every generating anything with simple, and I could just fail
all of those tests, I guess.


> - the spacing between the tags; since "relaxed" header canonicalization
> compresses spaces but does not add them, "a=foo;b=foo" is not the same as
> "a=foo; b=foo", but "a=foo;\r\n\tb=foo" is
> - similarly, how signature fields will be wrapped (if at all)
>

agreed.  I think some of this also goes to what implementers think look
good.  I also think dkimpy uses certain spacing so that they can wrap it
easier, as opposed to say Google's impl which hard codes most of it and has
more specific or hard coded wrapping.


> - what signing key will be used
> - the body content to be signed
>
- the header content to be signed
>

These are implied by the test already, so no big deal.


> - the set of header fields that will be signed (which becomes "h=")
>

And the order in which they're signed.  Ie, our DKIM impl, because it was
also a DomainKeys impl, could choose headers in either direction, but
actually chooses them "backwards" for DKIM, requiring kind of a nasty loop
that's also worst case (O(n^2)).  For ARC, I chose to choose them bottom
up, which matches the order to search, and means usually the dual loop has
O(n) instead of O(n^2).  Granted, it's a silly optimization, and doesn't
help with other implementations we have to also handle.

dkimpy just has a fixed list of fields, and adds them mostly in order.
There's also the choice of whether to include a header or not, we removed
content-type from our DKIM list at one point trying to work around
Exchange's DKIM breaking behavior, for example.  Some implementations
double add Subject/etc to prevent duplicates, others don't.

We can probably come to agreements on all of these things... well, maybe.
I don't know how many potential implementations we'll curtail by doing so.
Or maybe some of these won't be specified in the spec, but only for the
test suite, so they'll be options to the signers but not required (ie, list
of headers to prevent duplicates should be N for testing).

There's also the fact that the current drafts basically incorporate all of
this from the DKIM without specifying, if we do otherwise, we have to have
a lot more exposition.  We'll also most likely end up with things that
aren't specified in the spec explicitly but are required by the test suite
(which may be better than the alternative, something ambiguous in the spec
without being explicit elsewhere).

Also, I'm not clear on the statement that these aren't relying on dkim
libraries.  The dkimpy arc impl is clearly depending on shared code between
them, I think Paul mentioned that the AOL one re-used code from their Java
DKIM impl, and I know the Google impl shares a bunch of code.  I don't
think any of this precludes these changes, but they aren't free either.

Brandon