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

mpose some order that isn't necessary for DKIM but is critical when we're talking about multiple operators working together over multiple hops as part of a chain of trust. Seth -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for

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

air to shut this thread down. > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- [image: logo for sig f

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

de. 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. Seth On Thu, Mar 30, 2017 at 7:35 PM, Dave Crocker <dcroc...@bbiw.net> wrote: > On 3/30/2017 7:10 PM, Seth Blank wrote: > >&

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

ite and can be used to test against. > > > > I’m all for you, Seth and Peter, to write a test suite. But nothing you’ve > said so far has convinced me that a predetermined header order or a single > conformance test suite is worth pursuing. One of many, sure. > > > >

Re: [dmarc-ietf] How are ARC results processed, relative to DMARC?

I'm on the same page as Brandon. Additionally, earlier on the list and also in Prague, it was discussed formalizing DMARC reporting for ARC in a separate document, which would extend/override 9.6.2 of the current spec. On Tue, Aug 15, 2017 at 3:18 PM, Brandon Long wrote: >

Re: [dmarc-ietf] ARC-Seal is meaningless security theatre

On Mon, Aug 14, 2017 at 6:31 PM, Bron Gondwana wrote: > Do we, though? ARC has NOT ever been about localizing or understanding > changes to a message, it has been about understanding *actors* who may have > modified the message. > > > Sure, but knowing which actors may

Re: [dmarc-ietf] ARC-Seal is meaningless security theatre

On Wed, Aug 16, 2017 at 5:21 PM, Bron Gondwana wrote: > > The only way you could even hope (as a mailing list) to avoid rewriting > the sender is for every site that currently has DMARC p=reject to change > that to a new policy which explicitly means "only reject if no ARC

Re: [dmarc-ietf] ARC-Seal is meaningless security theatre

On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana wrote: > > While there exists A SINGLE SITE which is ARC-unaware and DMARC p=reject > aware, you can't use ARC on a DMARC p=reject domain without rewriting the > sender. Otherwise that site will bounce the email. > > You

Re: [dmarc-ietf] using selectors to identify sources

which key was used at the beginning of an ARC flow is impossible without transmitting the selector. On Fri, Jul 7, 2017 at 2:35 PM, Scott Kitterman <skl...@kitterman.com> wrote: > On Friday, July 07, 2017 01:33:58 PM Seth Blank wrote: > > On Fri, Jul 7, 2017 at 7:11 AM, Scott

Re: [dmarc-ietf] using selectors to identify sources

On Fri, Jul 7, 2017 at 11:29 PM, Murray S. Kucherawy <superu...@gmail.com> wrote: > On Fri, Jul 7, 2017 at 11:12 PM, Seth Blank <s...@sethblank.com> wrote: > >> Or maybe, put a different way, the question is: what's the simplest way, >> with the least

Re: [dmarc-ietf] Question for Thursday's meeting consideration: extending DMARC DNS record to cover ARC

On Tue, Jul 18, 2017 at 4:34 AM, Kurt Andersen wrote: > > Let's take ietf.org as an example. There are @ietf.org individuals and > then there are all the mailing lists. If IETF wished to assert to receivers > that all their mail was either mediated or came from designated

Re: [dmarc-ietf] Question for Thursday's meeting consideration: extending DMARC DNS record to cover ARC

On Tue, Jul 18, 2017 at 4:00 AM, Kurt Andersen wrote: > During today's lunch conversation, the question of how we can reasonably > scale recipients being able to identify mediators came up. > I don't understand. Mediators ARC sign, the header is everything you need for this

Re: [dmarc-ietf] Draft minutes from DMARC session at IETF 99 (Prague)

One correction: Point 4, settled issues: - AAR need not be signed *by AMS* On Thu, Jul 20, 2017 at 2:55 AM, Barry Leiba wrote: > The minutes are uploaded to the meeting materials manager, here: > https://www.ietf.org/proceedings/99/minutes/minutes-99-dmarc-02.txt > >

Re: [dmarc-ietf] selectors in AAR.

On Wed, Jul 5, 2017 at 3:33 PM, Murray S. Kucherawy wrote: > On Fri, Jun 23, 2017 at 3:17 PM, Brandon Long wrote: > >> On Wed, May 31, 2017 at 10:07 PM, Murray S. Kucherawy < >> superu...@gmail.com> wrote: >> >>> On Thu, May 4, 2017 at 4:19 PM, Peter

Re: [dmarc-ietf] selectors in AAR.

On Thu, Jul 6, 2017 at 6:05 PM, Murray S. Kucherawy wrote: > > I think this presupposes that there's some connective tissue between, but > distinct from, the DMARC report generator and the ARC implementation. Do > we have to presume that, or is it enough to make space for it

Re: [dmarc-ietf] ARC-Seal is meaningless security theatre

On Thu, Aug 17, 2017 at 11:46 PM, Kurt Andersen wrote: > So I was able to retrace our design steps which led to the 3-piece model > (AAR + AMS + AS) and the reasoning for the AS, signing just the ARC header > sequence was to provide the verifiable chain of custody trace

Re: [dmarc-ietf] ARC-Seal is meaningless security theatre

On Fri, Aug 18, 2017 at 10:08 AM, Dave Crocker <dcroc...@gmail.com> wrote: > On 8/18/2017 10:00 AM, Seth Blank wrote: > >> >> Right now, we've got deployed code that we know works and improves the >> landscape. Everything else is - rightly or wrongly - conjecture. &g

Re: [dmarc-ietf] ARC-Seal is meaningless security theatre

On Thu, Aug 17, 2017 at 1:09 AM, Bron Gondwana wrote: > > I laugh as well, but it's more than p=reject isn't enough in the ARC > world, because it doesn't distinguish between: > a) I'm OK with email from my domain being sent via mailing lists; and > b) no, this domain is

Re: [dmarc-ietf] Alternative draft text for draft-ietf-dmarc-arc-protocol

cise for me. >>> >>> I offer it here to the WG as a contribution; the WG of course is free to >>> use some, all, or none of it as it wishes. >>> >>> http://blackops.org/~msk/draft-kucherawy-dmarc-arc-base.txt >>> >>> If it would be more he

Re: [dmarc-ietf] ARC cv=invalid

> our new AAR then, which is worth something? > I also don't have any better ideas. > > =Gene > > On Tue, Jun 20, 2017 at 1:44 PM, Seth Blank <s...@sethblank.com> wrote: > >> On Tue, Jun 20, 2017 at 1:18 PM, Brandon Long <bl...@google.com> wrote: >> &g

Re: [dmarc-ietf] ARC cv=invalid

On Tue, Jun 20, 2017 at 1:18 PM, Brandon Long wrote: > The google implementation pre-dates cv=invalid, and when I went to > implement it, I couldn't find a good reason to do so, nor a great > bright-line rule for how to differentiate the two. > > I don't see the point of trying

[dmarc-ietf] Guidance around constructing an AAR when multiple AR headers are present?

receiver, then it seems like: 1) there needs to be a discussion on how to handle multiple AR headers 2) this guidance is needed in spec Is this a problem the group thinks needs discussion? -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source

[dmarc-ietf] Does the concept of an ARC tempfail make any sense?

] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols s...@valimail.com +1-415-894-2724 <415-894-2724> ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] signing keys for arc-seal/arc-message-signature

he hop >> for each a in transition... >> >> So: >> Should we require d= to be the same? Should we specify it only once? If >> not, why not? >> >> Brandon >> >> ___ >> dmarc mailing list >>

Re: [dmarc-ietf] Guidance around constructing an AAR when multiple AR headers are present?

mes the only possible solution allowed per spec. Thoughts? -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols s...@valimail.com +1-415-894-2724 <415-894-2724> ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] Clarifying question: AAR coverage by AMS

signed by AS[n], so whether or not it is in AMS[n] shouldn't matter), the spec leaves room for confusion about the right thing to do. What was the original intention here and does this need clarification? -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product

Re: [dmarc-ietf] Authentication-Results stamp for ARC

On Tue, May 30, 2017 at 11:43 AM, Scott Kitterman <skl...@kitterman.com> wrote: > On Tuesday, May 30, 2017 10:14:08 AM Seth Blank wrote: > > The current spec defines an arc authres method ( > https://tools.ietf.org/html/ > > draft-ietf-dmarc-arc-protocol-03#section-

Re: [dmarc-ietf] Authentication-Results stamp for ARC

erman <skl...@kitterman.com> > wrote: > >> On Tuesday, May 30, 2017 01:34:50 PM Seth Blank wrote: >> > On Tue, May 30, 2017 at 11:43 AM, Scott Kitterman <skl...@kitterman.com >> > >> > >> > wrote: >> > > On Tuesday, May 30, 2017 10

[dmarc-ietf] Authentication-Results stamp for ARC

, and welcome discussion on what's best to track within an AR header as arc status. I'm happy to suggest language once there's rough consensus in the group. Seth -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols s

Re: [dmarc-ietf] Meeting in Prague (IETF 99)

[Taking my reply to the initial thread so not to clog this one] On Tue, May 30, 2017 at 9:39 AM, Scott Kitterman <skl...@kitterman.com> wrote: > On Tuesday, May 30, 2017 09:34:49 AM Seth Blank wrote: > > Resolved items: > > - Handling of multiple incoming AR headers (r

Re: [dmarc-ietf] Clarifying question: AAR coverage by AMS

ble. And if a malicious use arises, then receivers are still in their right to shut those chains down and might already be doing so by default. Seth -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols s...@valimail.com +1

Re: [dmarc-ietf] Valimail and DMARC

Replying from my personal account as requested: On Fri, Jun 2, 2017 at 8:08 AM, Barry Leiba wrote: > The valimail.com domain appears to have recently (it looks like it > started 1 June) set a restrictive DMARC policy, and that's caused a > valimail.com has been at

Re: [dmarc-ietf] Authentication-Results stamp for ARC

- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols s...@valimail.com +1-415-894-2724 <415-894-2724> ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Clarifying question: AAR coverage by AMS

DMD, I think it's reasonable for > that ADMD to identify itself in a singular manner, though I suppose we > could have recourse to our favorite "org domain" alignment instead of > strict matching if you think that's better. I think that strict d= matching > is simpler and

Re: [dmarc-ietf] reporting arc local_policy to dmarc rua

ndon > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols s...@va

Re: [dmarc-ietf] reporting arc local_policy to dmarc rua

On Fri, May 5, 2017 at 6:13 PM, Kurt Andersen (b) <kb...@drkurt.com> wrote: > On Fri, May 5, 2017 at 2:30 PM, Seth Blank <s...@valimail.com> wrote: > >> >> At the end of an ARC chain, we’re generally left with an i=1 AAR with >> only SPF, DKIM, and DMARC pass/

Re: [dmarc-ietf] Meeting in Prague (IETF 99)

gt; > > -- > > Dave Crocker > > Brandenburg InternetWorking > > bbiw.net > > > > ___ > > dmarc mailing list > > dmarc@ietf.org > > https://www.ietf.org/mailman/listinfo/dmarc > > __

Re: [dmarc-ietf] Guidance around constructing an AAR when multiple AR headers are present?

On Tue, May 30, 2017 at 9:39 AM, Scott Kitterman <skl...@kitterman.com> wrote: > On Tuesday, May 30, 2017 09:34:49 AM Seth Blank wrote: > > Resolved items: > > - Handling of multiple incoming AR headers (resolved, but language not yet > > in spec) > > If this is

Re: [dmarc-ietf] Meeting in Prague (IETF 99)

___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols s...@valimail.com +1-415-894-2724 <415-894-2724> _

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-09.txt

On Wed, Sep 13, 2017 at 8:39 AM, Murray S. Kucherawy wrote: > > The way those fields are added seems wrong to me. RFC7601 spells all of > that out in terms of distinct (but related) ptypes and properties, which > are separate things. Adding "header.ds" as a single thing

Re: [dmarc-ietf] ARC draft-08 updates to section 5.1 and WG questions

Questions 1, 2, and 4 as they relate to the text I suggested are still open - and I don't believe the text that was pulled into -09 is correct until these questions are answered. On Tue, Sep 5, 2017 at 5:52 PM, Seth Blank <s...@sethblank.com> wrote: > There have been substantial comm

[dmarc-ietf] ARC draft-08 updates to section 5.1 and WG questions

There have been substantial comments both on and off list about section 5.1.1. I've suggested new language for all of 5.1, below, to remove normative modification of 7601, and address several other issues. There are questions for the WG below the suggested text. === Replace 5.1 with:

[dmarc-ietf] ARC draft-08 spec section 9.4

https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-08#section-9.4 There was an earlier thread about the proper way to handle this ( https://mailarchive.ietf.org/arch/msg/dmarc/Mz3xIgdB_OuBUqt9OlaZ9_feUpI). I want to suggest a different direction: Section 9.4 should be removed in its

Re: [dmarc-ietf] Proposed ARC "Experimental Considerations" section

On Fri, Nov 24, 2017 at 4:39 PM, Hector Santos wrote: > > Fwiw . > > DMARC is an DKIM Author Domain Policy System. A DMARC > (p=reject/quarantine) policy failure is Author Domain defined. Hence an > ARC "signal" to correct this failure must also be Author Domain defined, >

[dmarc-ietf] Proposed ARC "Protocol Elements" section

All- there has been back and forth about the current draft ( https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-09) missing context for a new reader to understand the purpose of ARC and how the components fit together. Cribbing from DKIM, I'm proposing a Protocol Elements section, which

Re: [dmarc-ietf] ARC draft-08 updates to section 5.1 and WG questions

Bumping this, too. All items below are still open. On Fri, Oct 6, 2017 at 8:27 PM, Seth Blank <s...@sethblank.com> wrote: > Questions 1, 2, and 4 as they relate to the text I suggested are still > open - and I don't believe the text that was pulled into -09 is correct > until

Re: [dmarc-ietf] ARC draft feedback

Hi Erik, Thank you very much for this feedback. We'll incorporate it into the next revision of the draft. Seth On Mon, May 7, 2018 at 2:57 PM, Erik Lax wrote: > We've been looking at implementing ARC in our MTA (Halon) and DKIM library > and wanted to share the following

Re: [dmarc-ietf] Binding Operational Directive 18-01 require agencies to implement STARTTLS, SPF and DMARC

The directive site has a pretty comprehensive overview of email authentication in general (cyber.dhs.gov/intro/) and actually has a section on negative side effects of DMARC that also references this working group's efforts on ARC:

Re: [dmarc-ietf] ARC draft-10 Section 10 - Algorithm Rotation - can we address separately?

> > Regards, > John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dmarc-rfc7601bis-00.txt

On Fri, Jan 19, 2018 at 1:41 PM, Kurt Andersen (b) wrote: > If I missed this, I apologize, but would it be possible to post a message >> which summarizes the nature/goals of the changes that are planned? >> >> I'm not challenging the work, but just wanting to make sure the wg

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-rfc7601bis-00.txt

Looks great to me. This allows us to simplify several pieces of ARC and make the draft easier to follow. Thank you! On Wed, Feb 7, 2018 at 21:11 Murray S. Kucherawy wrote: > On Wed, Feb 7, 2018 at 7:59 PM, wrote: > >> >> A New Internet-Draft is

[dmarc-ietf] ARC spec clean up if 7601bis proceeds

If 7601bis proceeds to allow content for filters in addition to humans, then I believe the actions in the ARC draft ( https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10) are as follows: Section 5.2 is cleaned up to inherit AAR ABNF from 7601bis. Section 5.2.1 is stricken. New IANA

Re: [dmarc-ietf] ARC draft-10 Section 10 - Algorithm Rotation - can we address separately?

And to be clear - I volunteer to write these documents and drive them to completion. On Thu, Dec 28, 2017 at 8:32 PM, Seth Blank <s...@sethblank.com> wrote: > On Thu, Dec 28, 2017 at 7:57 PM, John Levine <jo...@taugh.com> wrote: > >> I understand the motivation, b

[dmarc-ietf] ARC draft-10 protocol elements section and question about reducing section 8

Sections 4.7 and 4.8 from my proposal ( https://mailarchive.ietf.org/arch/msg/dmarc/yl1HWdNbmQR1wHlCvG3eRl9ph5E) were not moved into the protocol elements section of the latest draft ( https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10#section-4) I spoke with Kurt, and this appears to

[dmarc-ietf] ARC draft-10 Section 10 - Algorithm Rotation - can we address separately?

This got buried in two other threads ( https://mailarchive.ietf.org/arch/msg/dmarc/E9fOn8dIEiFqQJBz1GyFUimWVcM, https://mailarchive.ietf.org/arch/msg/dmarc/Bv55cS12p41j3XhWzuu5RybvzTA) so I'm just raising it to the top level. Algorithm rotation is clearly more complex in ARC where you only have a

[dmarc-ietf] ARC draft-10 Security Considerations - questions and request

https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10#section-13 Beyond my notes below, the Security Considerations section feels weak, and like it should at least inherit DKIM's security considerations. Additionally, there have definitely been items called out on this list (like the

[dmarc-ietf] ARC draft questions (speak up!): Experimental Status and Considerations

I'm beginning a new thread to explicitly address some differences of opinion in the working group. Coming out of IETF99 and surrounding working group conversations ( https://mailarchive.ietf.org/arch/msg/dmarc/5_OP8lVi-a3yHMS0hqs1clyLWj4,

[dmarc-ietf] ARC draft: Call for ARC Implementations to be included

The Implementation Status section of the draft ( https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10#section-14) feels out of date. If you're working on an implementation, please speak up so that we can include you! ___ dmarc mailing list

Re: [dmarc-ietf] ARC draft-10 Section 10 - Algorithm Rotation - can we address separately?

On Thu, Dec 28, 2017 at 7:57 PM, John Levine wrote: > I understand the motivation, but I think that if we do that, it makes > it a lot less likely that people will actually implement the > rotation stuff. > Since there are only a handful of major implementations right now, all

Re: [dmarc-ietf] ARC draft questions (speak up!): Experimental Status and Considerations

On Tue, Jan 2, 2018 at 11:05 PM, Murray S. Kucherawy wrote: > > 2) The advice that all handlers need to apply a seal to the message, to > which Bron previously and rather strenuously voiced opposition. I believe > the decision was to defer on that issue until we've run some

Re: [dmarc-ietf] Clarifying the value of arc.closest-fail

On Wed, Jan 3, 2018 at 3:28 PM, Kurt Andersen (b) wrote: > > Very helpful - thanks. I think that expressing it in the positive > "oldest-pass" form makes the point much clearer. Unless there is an outcry > from the rest of the group, I'd like to change to this terminology. > No

Re: [dmarc-ietf] Clarifying the value of arc.closest-fail

On Wed, Jan 3, 2018 at 14:50 Kurt Andersen (b) wrote: > I'm uncomfortable with the terminology implied by the term > "arc.closest-fail". I think that it is more "ams.closest-fail" or > "arc.ams-broken". AMS is expected to not verify except in the most recent > ARC set. Doing so

Re: [dmarc-ietf] Section 5.2.1, header.ds considered confusing

On Tue, Jan 2, 2018 at 12:45 PM, Kurt Andersen (b) wrote: > On Tue, Jan 2, 2018 at 7:38 PM, John R. Levine wrote: > >> I don't see the point of the header.ds field. We already have header.d, >> so why not just add header.s? >> > > Yes, quite so. Please see my

Re: [dmarc-ietf] Clarifying the value of arc.closest-fail

On Wed, Jan 3, 2018 at 12:48 PM, John Levine wrote: > > Seems to me this makes some assumptions about the way ARC consumers > will use ARC chains to decide whether to ignore a DMARC failure. > Personally, I think the most likely scenario is that they'll look at > all of the

Re: [dmarc-ietf] Additional review of draft-ietf-dmarc-arc-protocol-16

On Thu, Aug 2, 2018 at 6:43 AM, Dave Crocker wrote: > Continuing my review of: draft-ietf-dmarc-arc-protocol-16 > > NB: These are comments, not demands. Use however is helpful... Dave, thanks for these comments. I've quickly scanned your notes and nearly everything makes sense. I'll go

Re: [dmarc-ietf] WGLC on draft-ietf-dmarc-arc-protocol-16

On Wed, Aug 1, 2018 at 8:53 AM, A. Schulze wrote: > - section-2.1 introduce "AMDM" defined later in section-3 > Great catch. Based on Dave Crocker's feedback, we've defined the term "Authentication Assessment" and moved the entire second paragraph of 2.1 into this definition, which ends up

Re: [dmarc-ietf] WGLC on draft-ietf-dmarc-rfc7601bis-02

On Fri, Aug 3, 2018 at 7:25 AM, John Levine wrote: > > > To the rest of the WG: Is there consensus to make this change or the > >others being proposed? > > Not that I've seen. I thought we agreed to make changes to support ARC, to > handle EAI, and to fix any actual errors. Other than that,

Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily

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

Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily

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

Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily

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"

Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily

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

[dmarc-ietf] WGLC ARC-16 minor change to Section 7.2.2 for DMARC Reporting

https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-16#section-7.2.2 The example comment arc=pass ams[2].d=d2.example ams[2].s=s1 as[2].d=d2.example as[2].s=s2 as[1].d=d1.example as[1].s=s3 client-ip[1]=10.10.10.13 Doesn't match the descriptive text before it. To fix

Re: [dmarc-ietf] Comments on certain drafts

On Mon, Jul 23, 2018 at 2:33 AM, Peter Occil wrote: > draft-ietf-dmarc-arc-protocol > > > > The production “arc-info” includes a semicolon after “instance”, which in > turn has a semicolon at the end. However, a great number of > Arc-Authentication-Results header fields I’ve seen in practice

[dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily

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

[dmarc-ietf] WGLC ARC-16 section 5.2.2 should be stricken

https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-16#section-5.2.2 I am confused as to where this section comes from. It was never discussed on list, and I believe it should be stricken. https://mailarchive.ietf.org/arch/browse/dmarc/?q=5.7.7 has no results except for Dave Crocker's

Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily

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

Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily

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 >> separ

Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily

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

Re: [dmarc-ietf] ARC-16 and EAI messages

sider the environment before reading this e-mail. https://jl.ly > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- Seth Blank | Director of Industry Initiatives E: s...@valimail.com | P: 415.273.8818 _

Re: [dmarc-ietf] ARC-16 and EAI messages

On Tue, Jul 31, 2018 at 3:13 PM, John Levine wrote: > It doesn't say that in 4.1.2, even though it's sort of implicit since > i= means something else. I'd say so explicitly in a fifth bullet > after where it says "three (3) differences." > One of those differences says: * the presence of the

Re: [dmarc-ietf] ARC-16 and EAI messages

On Tue, Jul 31, 2018 at 1:48 PM, John Levine wrote: > >So the only wording consideration under WGLC is the ABNF import with > >respect to DKIM and draft-levine-appsarea-eaiauth? > > Yes, although it's probably worth reminding people where things are > different in EAI messages. > The

Re: [dmarc-ietf] ARC-16 and EAI messages

I've added the following text as Section 4.1.4 (note fixed typos and removal of the i= section, which is removed from ARC explicitly): 4.1.4: Internationalized mail considerations In internationalized messages [RFC 6532] many header fields can contain UTF-8 as well as ASCII text. The changes

Re: [dmarc-ietf] ARC-16 and EAI messages

well. > > Please do. Experience tells us that the more clearly you lay something > out, the > less likely we are to screw it up. I don't remember what AUID is without > looking > it up but i= is obvious. Done. > > PS: There's still four bullets aft

Re: [dmarc-ietf] Additional review of draft-ietf-dmarc-arc-protocol-16

On Fri, Aug 3, 2018 at 11:04 AM, Dave Crocker wrote: > > At a minimum, I suggest clear and relatively forceful language, making > clear the privacy concerns. (Privacy is new enough and, frankly, fuzzy > enough as a technical topic, to warrant the redundancy I usually argue > against...) > What

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-16.txt

On Wed, Aug 1, 2018 at 10:14 AM, Ken O'Driscoll wrote: > > Apologies if this has already been caught by others. > > Just spotted some small typos in section 8. Was reading this specific > section in connection with something GDPR (the fun!) related. > > 8. Privacy Considerations > >The

Re: [dmarc-ietf] ARC-16 signature domains

This was just discussed in a thread with Jim Fenton last week (although from the DNS angle). The tl;dr is that we don't believe they'll ever be different, but there's no technical reason to require d=/s= alignment between AS/AMS for the same i=. We can foresee places where separate signing

Re: [dmarc-ietf] ARC-16 signature domains

On Fri, Jul 27, 2018 at 11:15 AM, John R Levine wrote: > > I'd say that all signatures in a seal SHOULD have the same domain, to make > them easier to evaluate. > So the Usage Guide will (does?) say that. Earlier consensus was to keep that out of the normative document because a) it doesn't

Re: [dmarc-ietf] WGLC ARC-16 section 5.2.2 should be stricken

On Fri, Jul 27, 2018 at 10:41 AM, Scott Kitterman wrote: > And if you don't want to make a new one, 5.7.26 (Multiple authentication > checks failed) seems at least not wrong. To get to this point DKIM, > DMARC, > and ARC have failed. > Is this better moved into Experimental Considerations? We

Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily

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

Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily

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

Re: [dmarc-ietf] Additional review of draft-ietf-dmarc-arc-protocol-16

As stated previously, I've made all stated changes, with the exception of the below, for further discussion: On Thu, Aug 2, 2018 at 6:43 AM, Dave Crocker wrote: > 4. Protocol Elements >> > > > I keep thinking that it would help to have some summary text, possibly > with a figure, that shows

Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily

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

Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily

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

Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily

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

Re: [dmarc-ietf] ARC protocol-15 posted

On Tue, Jul 17, 2018 at 8:01 AM, Jim Fenton wrote: > It wasn't meant as a restriction. I was trying to decide on the right > normative word to use here, and the IETF usage of SHOULD is probably too > strong. I'd be happy with a MAY there; I don't think it hurts to point out > that it's a good

Re: [dmarc-ietf] Partial Review of: draft-ietf-dmarc-arc-protocol-16

On Tue, Jul 17, 2018 at 4:59 PM, Dave Crocker wrote: > Review of:draft-ietf-dmarc-arc-protocol-16 (partial) > Date: 17 Jul 18 > Reviewed by: D. Crocker > > > Summary: > > I gave a review for -14 and will skip the pro forma functional summary. > > I reviewed the initial portions of

Re: [dmarc-ietf] ARC protocol-15 posted

On Mon, Jul 16, 2018 at 7:06 AM, Jim Fenton wrote: > 9.2 describes the problem, but it's expressed in terms of a DoS attack on > (primarily) validators. The DNS folk will be more concerned with the > overall load on the infrastructure caused by ARC, not specifically on > attack scenarios. So in

Re: [dmarc-ietf] WGLC on draft-ietf-dmarc-rfc7601bis-02

I've reviewed. All the technical matters look good, and earlier comments have all been addressed. I have two final comments: 1) Section 6.4 mentions changes to section 2.3 which include slightly different language than in 7601. I see no difference whatsoever (walking back diffs 02-01, 01-00)

Re: [dmarc-ietf] WGLC on draft-ietf-dmarc-rfc7601bis-02

Excellent. Then all my comments have been addressed and I have nothing further. On Mon, Jul 16, 2018 at 2:48 PM, Murray S. Kucherawy wrote: > On Mon, Jul 16, 2018 at 4:56 PM, Seth Blank wrote: > >> I've reviewed. All the technical matters look good, and earlier comments >

Re: [dmarc-ietf] ARC protocol-15 posted

On Wed, Jul 11, 2018 at 4:41 AM, Kurt Andersen (b) wrote: > I think that there is a bit of a difference here and terminology is not > being used precisely. The "seal" (AS) is not invalidated when someone > changes the content. The "signature" (AMS) is. The "seal" (aka AS) remains > valid as

  1   2   3   >