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

["Murray S. Kucherawy" <[e-mail]>]

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
- 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
- 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)
- what signing key will be used
- the body content to be signed
- the header content to be signed
- the set of header fields that will be signed (which becomes "h=")

It certainly removes many variables to nail down a test in this way, and
it's faster to run tests that don't require crypto functions or a
known-good verifier to confirm.  To be honest, I can't remember if we ever
considered this sort of approach during the development of DKIM.  I don't
think we did, and after an admittedly brief search I couldn't find anything
in the archives.  I think when canonicalization was developed, it was plain
that tag order wouldn't matter to the verifier, and that was sort of the
end of it.

The obvious counter-argument here is that DKIM has been successful without
ever being strict about what a signature looks like.  Our interop event in
Dallas way-back-when consisted solely of implementer "A" sending mail at
implementer "B" and seeing what passed and what failed, and digging into
the failure cases to see if they're bugs in code or bugs in the
specification.  Independent of interop events, various implementers also
set up auto-responders that would verify an arriving message, then re-sign
it and send it back so the originator can test its verification.  Any
failure compelled us to implement debugging tools and exchange information
so we could work out the kinks, either in the spec or in the
implementation(s), until all participants were consistent.  We reached a
point where we had organically developed a bunch of "good" implementations
based on the fact that they all appeared to agree with each other.

Since the canonicalization algorithms in ARC are the same as the ones in
DKIM, and the tag=value and key syntaxes are also the same, we've got a lot
of concepts and code being recycled here.  I'm not sure how much new
fragility we should really be concerned about.  I'll know more as I
complete my implementation.

Paul's point that video and security protocols are traditionally much more
rigid is of course quite true, and I presume he's thinking of things like
the headers of DNS, IP, TCP, etc.  But I note that those are based on a
different model where fields have fixed sizes and predictable positions.
That's antithetical to email, however, where the fields come in arbitrary
order, and the only way you know what a given header means is that its name
precedes its value.  There can even be duplication.  And from one MTA to
another, header fields can be added, removed, or rearranged.  That's
impossible in a rigid header definition, so it's perhaps no surprise that
this community isn't exactly warm to the idea.

The question, then, is whether this is a desirable path to follow: Is the
value of a quick evaluation of a deterministic signer high enough to
surrender the flexibility of DKIM style of tag spacing and ordering?  And,
perhaps more importantly, what's the cost of being wrong later?

-MSK