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

[Scott Kitterman <[e-mail]>]

What's more difficult to is identify all the ways that things get reordered, 
mangled, etc as they transit the various elements of the mail architecture.  
If you over specify the allowed order, aren't you risking increasing the 
brittleness of the solution.

If test cases are automatically generated, then they are cheap and we 
shouldn't worry about unduly constraining things to keep the number small.  As 
long as, at some point, the test cases are validated against multiple 
implementations, I think it's fine.  If you've got a handful of 
implementations, then the risk of them all having the same bug is pretty low.

In addition to Perl, I'd expect something in Ruby to appear in due course.

Scott K

On Monday, March 27, 2017 07:54:43 PM Peter Goldstein wrote:
> John,
> 
> I'm familiar with the definition of the FWS in the ABNF, as well as the
> generic definition ABNF for message headers.  I'm also aware of the
> challenges with trying to normalize such headers, and how that can impact
> email authentication - breaking forwarded DKIM signatures and such.  But
> none of that is actually relevant here - we are not interested in arbitrary
> messages.
> 
> We are interested in creating a set of valid input messages and ensuring
> that these messages are signed in a consistent, reliable way by any valid
> ARC implementation.  This is an extremely narrow case - so yes, I do think
> the above is basically all it would take to make such signature headers
> identical.  Perhaps I'll be disappointed, but based on the sample messages
> I have on hand from existing implementations, that seems unlikely.
> 
> As for the hypothetical developers who will be adapting DKIM libraries to
> do ARC signing, we've been talking about them since M3AAWG in October
> 2015.  So far they haven't materialized.  Honestly, it's not even clear to
> me that there are that many DKIM libraries out there to adapt.
> 
> Instead we've seen ~5 implementations (Google, AOL, Dkimpy, OpenARC,
> MailerQ), with potential support for implementations in 1-2 additional
> languages (e.g. Perl) probably driven by one or more of the implementers of
> the existing implementations.  It should be relatively easy to coordinate
> such a change across the small number of existing implementations.
> 
> Best,
> 
> Peter
> 
> On Mon, Mar 27, 2017 at 7:21 PM, John R Levine <[e-mail]> wrote:
> > I think tightening up some currently allowed ambiguity in the ARC
> > 
> >> specification is a much simpler and much better solution.  I'm not sure
> >> why
> >> there's such concern about canonicalizing the format and ordering of some
> >> tag/value pairs.
> > 
> > If you think that's all it would take to make signature headers perfectly
> > identical, you will be deeeply disappointed.  (Take a look at FWS in the
> > ABNF and all of the other generic ABNF for message headers.)
> > 
> > I think what we've been saying is that the SMTP mail ecosystem has never
> > tried to make stuff bit-for-bit reproducible, and even if you could hammer
> > on the spec to make super strict rules for one particular header, it's
> > unlikely that the people who are adapting their DKIM code would pay
> > attention.
> > 
> > R's,
> > John