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

> What's the best way to proceed from here for the working group? That's easy: The way to proceed is by describing the actual interoperability problem that came up. In detail. What you have done so far, AFAICT, is propose a change that at most facilities a type of testing decades of experience

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

Hi Seth, Can you describe in detail the fragility you've observed? I saw Peter (sorry for "Paul", it was 4am) upthread somewhere say that a few different projects had various problems found, but I don't recall him saying exactly what they were. -MSK On Fri, Mar 31, 2017 at 11:13 AM, Seth Blank

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

On 3/30/2017 10:41 PM, Seth Blank wrote: If the consensus here is that the matter is not worth pursuing further, that is fine - I just want to make sure we're all talking about the same thing. Except that 'the matter is not worth pursuing' isn't what I heard anyone saying and it definitely

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

t; <superu...@gmail.com>, "dmarc@ietf.org" < > dmarc@ietf.org>, Scott Kitterman <skl...@kitterman.com>, Peter Goldstein < > pe...@valimail.com>, "ned+dm...@mrochek.com" <ned+dm...@mrochek.com> > *Subject: *Re: [dmarc-ietf] indeterminisi

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

ucherawy" <superu...@gmail.com>, "dmarc@ietf.org" <dmarc@ietf.org>, Scott Kitterman <skl...@kitterman.com>, Peter Goldstein <pe...@valimail.com>, "ned+dm...@mrochek.com" <ned+dm...@mrochek.com> Subject: Re: [dmarc-ietf] indeterminisim of AR

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

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

Scott, I will confess to not following all the details on a regular basis, but > doesn't the paragraph you referenced give a required sequence of multiple > header fields? Maybe that's not a problem any more (it's been some years > since I looked), but that definitely used to be something it was

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

I will confess to not following all the details on a regular basis, but doesn't the paragraph you referenced give a required sequence of multiple header fields? Maybe that's not a problem any more (it's been some years since I looked), but that definitely used to be something it was risky to

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

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

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

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

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

Sure, generating the output message requires an ARC implementation. Same as generating a DKIM signature for validation requires an actual DKIM implementation. Or generating an SPF result for a complex situation generally requires an actual SPF implementation. Or generating an ARC-signed input

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

John, > I have to say I don't find that very persuasive. It's not hard to write > test code that checks for the hashes and fields in a signature header > without regard to what order they're in. I would rather write better test > code than add fragile extra cruft to every ARC implementation.

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

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