> 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 ha
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
Thank you, Dave.
What's the best way to proceed from here for the working group?
On Fri, Mar 31, 2017 at 8:55 AM, Dave Crocker wrote:
> 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 sur
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 w
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 deployment
> issues simpl
>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
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 fragil
n
>
>
>
> *From: *dmarc on behalf of Seth Blank <
> s...@valimail.com>
> *Date: *Thursday, March 30, 2017 at 8:10 PM
> *To: *"dcroc...@bbiw.net"
> *Cc: *"Murray S. Kucherawy" , "dmarc@ietf.org" <
> dmarc@ietf.org>, Scott Kitterm
, "ned+dm...@mrochek.com"
Subject: 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
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 focu
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
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
> > model.
>
> Exactly. And given the success of the
> >
> > > 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
> > somethin
>
> > 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 comp
>
> 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.
> Fo
> 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 risking increasin
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 risking increasing the
> brit
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 test it with strcm
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 only
> have the tests p
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 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
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
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
Scott,
Header reordering is irrelevant to this discussion - the ARC RFC specifies
in some detail how to construct the ARC Seal from the AMS and AAR headers -
https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-02#section-5.2 .
And the AMS headers have the same behavior as DKIM - header order
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 generat
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
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
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 me
Brandon,
How do you validate that the signature verifies? To do that you need an
entire ARC implementation that is packaged within the test suite (and the
ability for it to run as a service, or make it available in some way to
implementations being tested that are written in different languages).
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.
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
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
In article
you write:
>The issue is that its possible for two separate arc implementations, given
>the exact same message inputs, keys, timestamps, etc to be generating two
>different, but equally valid ARC seal hashes.
DKIM does the same thing. The order of fields in a DKIM-Signature
header is
Hi All,
Based on a conversation I had with Murray the other day, I'd like to revive
a conversation I'd started on the ARC discuss forum a few months back.
Basically there is a subtle issue present in the current ARC draft that
doesn't exist with DKIM that I don't think most people are aware of tha
33 matches
Mail list logo
