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

On Thu, Mar 30, 2017 at 7:35 PM, Dave Crocker wrote: > > So to the extent that you are sure things really are that fragile, the > answer is not going to be a test suite or excessively demanding algorithms, > but a re-thinking of the details, to make the implementation and

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

>My reading of this too-long message thread is that there is essentially >no support for making ARC's header-related issues any different from >DKIM's, so I encourage the chair to shut this thread down. What he said. Can we please limit subsequent discussion of testing about how to test ARC as

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

On 3/30/2017 7:10 PM, Seth Blank wrote: Dave, If we were only talking about ARC Signing messages, I'd generally agree with the comments on this list. However, ARC is fundamentally different. It is about a chain of messages Either you are correct, in which case ARC has been made far too

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

Yes, +1000 to many test suites. But no test suite can function without a deterministic order of fields in the header unless it also includes an ARC implementation for signing/validating, which is where this conversation started and why we care so much about discussing this ordering. On Thu, Mar

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

One of the reasons DKIM was successful in becoming interoperable was not that we had a test suite to force conformance, but instead that we had >multiple< test suites that were able to successfully validate DKIM signatures from multiple implementations. My test suite caught corner cases that

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

Dave, If we were only talking about ARC Signing messages, I'd generally agree with the comments on this list. However, ARC is fundamentally different. It is about a chain of messages that validate each other. And ARC's complexity is not in the signing (where most of this conversation has been

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

On 3/30/2017 12:13 PM, ned+dm...@mrochek.com wrote: And given the relationship with DKIM people are going to expect ARC to work in the same general way, maing such a change a least astonishment principle violation. +10. This thread has been active for 6 days. That is 5.5 days longer than it

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

On Thu, Mar 30, 2017 at 7:01 AM, wrote: > > On Mon, Mar 27, 2017 at 11:49 PM, Scott Kitterman > > That sort of organic validation of implementations seemed to work for > > DKIM. The unknown here is whether ARC will be as successful with that > >

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

> > > > > I think Peter's proposal (and he can correct me if I'm wrong) is only to > > > constrain signers. Verifiers are still expected to handle everything > > weird > > > that the infrastructure might do. > > This proposal creates a situation where verifiers are required to support > >

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

> > > I think Peter's proposal (and he can correct me if I'm wrong) is only to > > constrain signers. Verifiers are still expected to handle everything > weird > > that the infrastructure might do. > This proposal creates a situation where verifiers are required to support > something that no

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

> > 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. Great. :) I wasn't sure there was agreement on that in the wider thread. >

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

> On Mon, Mar 27, 2017 at 11:49 PM, Scott Kitterman > wrote: > > 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,

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

On Mon, Mar 27, 2017 at 11:49 PM, Scott Kitterman wrote: > 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

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

On Mon, Mar 27, 2017 at 1:06 PM, Brandon Long wrote: > What does validating the exact signature generated benefit us over just > verifying that the signature verifies? > The most obvious benefit I can think of is that the output of signing is entirely deterministic. You could

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

On Sun, Mar 26, 2017 at 11:25 PM, Peter Goldstein wrote: > Second, the premise that "it's not hard to write test code..." is simply > not true. What would be required to actually write such code would be > either a) pick a preferred ordering/formatting for these tags, and