On Mon, 20 Aug 2018, Kurt Andersen (b) wrote:
No, by subsequent I mean intermediaries who handle the message after the
point of initial "oh, this is broken" determination. So if I'm the 5th
intermediary (let's assume that all are ARC participating for this
discussion), and the chain on the messag
On Mon, Aug 20, 2018 at 7:18 PM, John Levine wrote:
> In article gmail.com> you write:
> >My contention to Seth is that in a multi-hop scenario, the *only* report
> >with meaningful data will be the one from the handler who made the "fail"
> >determination and any subsequent reports are untrustw
In article
you write:
>My contention to Seth is that in a multi-hop scenario, the *only* report
>with meaningful data will be the one from the handler who made the "fail"
>determination and any subsequent reports are untrustworthy.
Assuming that "subsequent" means earlier in the chain, I agree.
Seth and I discussed this topic today and I think that the central problem
that is being debated has to do with *generating* the DMARC report content.
Almost everyone agrees that a broken chain is broken and unredeemable -
whether that breakage is structural or whether it is because of
non-validati
Hi,
I agree with your comments.
My input.
Keep in mind, that ignorant (non-supportive) ARC nodes will continue
to process all DKIM-signature(s) found, such as what I see with your
message:
Authentication-Results: dkim.winserver.com;
dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.
(back from vacation and catching up)
On Tue, Aug 14, 2018 at 8:58 PM, Seth Blank wrote:
> There are THREE consumers of ARC data (forgive me for the names, they're
> less specific than I'd like):
>
> 1) The ARC Validator. When the Validator sees a cv=fail, processing stops,
> the chain is dead, a
I'm still at a bit of a loss as to how one can effectively do a "greedy"
seal over a broken chain in a deterministic fashion.
I've been discussing this with Seth. Particularly once we start doing
parallel chains for different algorithms, different implementations will
disagree about what's a
n
> Sr. Engineer, Anti-Abuse
> Comcast
>
>
> -Original Message-
> From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of John R Levine
> Sent: Wednesday, August 15, 2018 3:54 PM
> To: Dave Crocker
> Cc: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] WGLC ARC-16 con
day, August 15, 2018 3:54 PM
To: Dave Crocker
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should
sign greedily
On Wed, 15 Aug 2018, Dave Crocker wrote:
> This is a very different kind and degree of vague (and without
> precedent, I belie
On 8/15/2018 12:54 PM, John R Levine wrote:
Can you explain in words the damage that cv=fail signatures will cause,
and a rough idea of the cost to ARC signers and verifiers? To me the
answers are none, and trivial.
You have the obligations reversed. When adding things -- which adds
overhe
On Wed, 15 Aug 2018, Dave Crocker wrote:
This is a very different kind and degree of vague (and without precedent, I
believe (unless someone can point to operational experience on the net that
is similar?)
I believe there are lots of trace fields that don't have a concrete use.
I am not famil
On 8/15/2018 11:53 AM, John R Levine wrote:
On Wed, 15 Aug 2018, Dave Crocker wrote:
Modest, indeed. Also unknown.
This is building in a permanent behavior, for a use that is, at best,
vague conjecture.
Well, sure, but we could say that about all of ARC.
No we can't.
This is a very diff
On Wed, 15 Aug 2018, Dave Crocker wrote:
Modest, indeed. Also unknown.
This is building in a permanent behavior, for a use that is, at best, vague
conjecture.
Well, sure, but we could say that about all of ARC. As far as I know
nobody has any rules yet for evaluating ARC chains beyond "if
On 8/15/2018 11:30 AM, John Levine wrote:
In article <799c2b18-97fe-6e22-f2cf-49245ae9c...@gmail.com> you write:
So the extra mechanism is intended an efficiency hack.
No, it also documents the fact that the chain was broken when it
arrived at the cv=fail signer. Without it, a subsequent hop
On Wed, Aug 15, 2018 at 11:30 AM, John Levine wrote:
> In article <799c2b18-97fe-6e22-f2cf-49245ae9c...@gmail.com> you write:
> >So the extra mechanism is intended an efficiency hack.
>
> No, it also documents the fact that the chain was broken when it
> arrived at the cv=fail signer. Without it
In article <799c2b18-97fe-6e22-f2cf-49245ae9c...@gmail.com> you write:
>So the extra mechanism is intended an efficiency hack.
No, it also documents the fact that the chain was broken when it
arrived at the cv=fail signer. Without it, a subsequent hop can't
tell. It probably won't make much diff
On Wed, Aug 15, 2018 at 6:33 AM, Dave Crocker wrote:
>
> This doesn't sound like compelling benefit, which is why I suggest
> removing it. Absent compelling benefit, simpler specifications is to be
> preferred, IMO.
Absolutely agreed on simplifying the spec, but the above conversation
misses th
On 8/14/2018 10:28 PM, Kurt Andersen (b) wrote:
The only reason to affix a seal with "cv=fail" on the end of an ARC
chain is to spare all subsequent handlers from having to venture past
step 2 in the validation process. Without that, every intermediary and
the final receiver (at least those whi
On Wed, Aug 15, 2018 at 1:28 AM, Kurt Andersen (b) wrote:
> On Sat, Aug 11, 2018 at 2:31 PM, Dave Crocker wrote:
>
>> On 8/11/2018 2:20 PM, Murray S. Kucherawy wrote:
>>
>>> Sign one" (I think you mean "seal one") remains ambiguous to me, because
>>> as Seth said, once I see "cv=fail", I don't c
On Sat, Aug 11, 2018 at 2:31 PM, Dave Crocker wrote:
> On 8/11/2018 2:20 PM, Murray S. Kucherawy wrote:
>
>> Sign one" (I think you mean "seal one") remains ambiguous to me, because
>> as Seth said, once I see "cv=fail", I don't care about anything else. Now
>> I have a seal nobody cares about,
On Sat, Aug 11, 2018 at 2:31 PM, Dave Crocker wrote:
> If there is a clear and compelling counter-argument of clear benefit that
> can be achieved, will be achieved, and is desired by receivers, what is it?
There are THREE consumers of ARC data (forgive me for the names, they're
less specific t
On 8/11/2018 2:20 PM, Murray S. Kucherawy wrote:
Sign one" (I think you mean "seal one") remains ambiguous to me, because
as Seth said, once I see "cv=fail", I don't care about anything else.
Now I have a seal nobody cares about, which means the sealer shouldn't
be bothered with generating it,
On Tue, Aug 7, 2018 at 3:37 PM, Kurt Andersen (b) wrote:
> On Mon, Aug 6, 2018 at 5:46 PM, Brandon Long ietf.org> wrote:
>
>>
>> Do we actually have consensus on what to do, though?
>>
>> The current proposal seems pretty bad, sign one or all depending on vague
>> things that might be different
On Mon, Aug 6, 2018 at 5:46 PM, Brandon Long <
blong=40google@dmarc.ietf.org> wrote:
>
> Do we actually have consensus on what to do, though?
>
> The current proposal seems pretty bad, sign one or all depending on vague
> things that might be different per impl.
>
It does not seem to me like
On Fri, Aug 3, 2018 at 11:00 AM, Brandon Long <
blong=40google@dmarc.ietf.org> wrote:
> Currently, we don't do anything with failed chains short of keeping
> stats. Everything we've used the chain for so far has been from passing
> chains.
>
Especially as an Experiment, I think it's importan
Currently, we don't do anything with failed chains short of keeping stats.
Everything we've used the chain for so far has been from passing chains.
That said, we still only trust our own chain elements, we haven't seen wide
enough adoption to spend much effort on interpreting chains which
involve
I know I lost the argument on cv (I think cv is entirely superfluous and
there's no point adding/signing a cv=fail header), but it seems the
argument for that is more data. That said, this "either or" signing set
thing on cv=fail seems pretty cumbersome.
You guys have looked at as many ARC sign
I know I lost the argument on cv (I think cv is entirely superfluous and
there's no point adding/signing a cv=fail header), but it seems the
argument for that is more data. That said, this "either or" signing set
thing on cv=fail seems pretty cumbersome.
Brandon
On Mon, Jul 30, 2018 at 5:42 PM J
The working group considered cv=invalid last year, but there was strong
consensus was against it. The guidance for Sealing cv=invalid Chains
somehow made it into this draft applied to all cv=fail Chains. All Chains
should be Sealed in the same fashion (your AS covers the ARC Set you've
added and a
On Mon, Jul 30, 2018 at 3:17 PM, John Levine wrote:
> I think it's fine to sign and hope for the best, but how is a
> validator supposed to tell the difference? Perhaps we need something
> like cv=restart.
>
So that's where this specific thread started if you roll back to the very
first message
In article
you write:
>5.1.2 says when a chain fails, to put cv=fail in the AS and only Seal the
>ARC Set being added.
>
>Per the original message and suggested text, I believe 5.1.2 should only
>provide the above guidance when it is not otherwise possible to sign the
>entire ARC Chain (i.e. when
I've been thinking about this and discussing offline, so to put it
differently:
5.1.2 says when a chain fails, to put cv=fail in the AS and only Seal the
ARC Set being added.
Per the original message and suggested text, I believe 5.1.2 should only
provide the above guidance when it is not otherwi
On Sun, Jul 29, 2018 at 3:59 PM, Bron Gondwana
wrote:
>
> I'm not sure what you mean by "the veracity of the header field data".
> Can you give an example of a cv=fail where there's useful information still
> trustworthy in the message, because I don't see it. To use the "chain of
> custody" anal
On Sun, Jul 29, 2018, at 11:12, Seth Blank wrote:
> On Fri, Jul 27, 2018 at 7:39 PM, Bron Gondwana
> wrote:>> __
>>
>> The only thing your ARC Seal will validate is your own ARC-Authentication-
>> Results header - which isn't nothing (it could contain the IP address
>> that you received this mess
On Fri, Jul 27, 2018 at 7:39 PM, Bron Gondwana
wrote:
> The only thing your ARC Seal will validate is your own
> ARC-Authentication-Results header - which isn't nothing (it could contain
> the IP address that you received this message from) - but if SPF / DKIM and
> ARC are all fails in your Auth
On Sat, Jul 28, 2018, at 03:29, Seth Blank wrote:
> On Fri, Jul 27, 2018 at 10:21 AM, Murray S. Kucherawy
> wrote:>> On Fri, Jul 27, 2018 at 8:35 AM, Seth Blank
>> wrote:>>
>>> The verification algorithm is straightforward. If you receive a
>>> chain that ends with cv=fail stop your evaluation,
On Fri, Jul 27, 2018 at 10:54 AM, Seth Blank wrote:
> On Fri, Jul 27, 2018 at 10:39 AM, Murray S. Kucherawy > wrote:
>>
>> But (and I think this proves my point) I don't know if "cv=fail" refers
>> to an invalid chain or a failed chain. I have to run the verification to
>> figure that out. But
On Fri, Jul 27, 2018 at 10:39 AM, Murray S. Kucherawy
wrote:
>
> But (and I think this proves my point) I don't know if "cv=fail" refers to
> an invalid chain or a failed chain. I have to run the verification to
> figure that out. But you're saying you just stop when you see "cv=fail".
>
> I rem
On Fri, Jul 27, 2018 at 10:29 AM, Seth Blank wrote:
> On Fri, Jul 27, 2018 at 10:21 AM, Murray S. Kucherawy > wrote:
>
>> On Fri, Jul 27, 2018 at 8:35 AM, Seth Blank wrote:
>>
>>> The verification algorithm is straightforward. If you receive a chain
>>> that ends with cv=fail stop your evaluati
On Fri, Jul 27, 2018 at 10:21 AM, Murray S. Kucherawy
wrote:
> On Fri, Jul 27, 2018 at 8:35 AM, Seth Blank wrote:
>
>> The verification algorithm is straightforward. If you receive a chain
>> that ends with cv=fail stop your evaluation, you’re done. There’s no
>> separate validation path here.
>
On Fri, Jul 27, 2018 at 8:35 AM, Seth Blank wrote:
> The verification algorithm is straightforward. If you receive a chain that
> ends with cv=fail stop your evaluation, you’re done. There’s no separate
> validation path here.
>
Then why bother signing anything when you affix "cv=fail"?
-MSK
__
On Fri, Jul 27, 2018 at 08:24 Murray S. Kucherawy
wrote:
> covering the ARC header fields in the failing chain, all the data in the
>> failed chain can be modified as it is not covered under the latest
>> signature.
>>
>
> I think it's weird that the body of content that gets hashed by the seale
On Wed, Jul 25, 2018 at 2:34 PM, Seth Blank wrote:
> When we introduced the concept of cv=invalid last year, the advice was to
> only sign your own ARC Set, because there was no deterministic way to know
> which header fields to sign when those ARC header fields were not properly
> intact (the de
On Wed, Jul 25, 2018 at 2:46 PM, Luis Muñoz wrote:
> There should be clear indication in the ARC-Seal about which of the
> branches above were taken.
>
Agreed, and that was the intent of cv=invalid. However the working group
had strong consensus not to go down that path.
This could be another v
On 25 Jul 2018, at 14:34, Seth Blank wrote:
The proper guidance should be that the ARC-Seal MUST sign the ARC
Chain in
its entirety, unless that is structurally impossible, in which case it
should only sign itself.
There should be clear indication in the ARC-Seal about which of the
branches
https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-16#section-5.1.2
Originally, even in the event of a chain validation failure, the Sealer's
ARC-Seal would sign all ARC header fields on the message.
When we introduced the concept of cv=invalid last year, the advice was to
only sign your o
46 matches
Mail list logo
