Re: [dmarc-ietf] ARC draft questions (speak up!): Experimental Status and Considerations
On Tue, Jan 2, 2018 at 12:57 PM, Kurt Andersen (b) wrote: > While John Levine cited the benefits of the "experimental" approach taken > for EAI (https://mailarchive.ietf.org/arch/msg/dmarc/ > gvUecJuYLT9GIh5zbcZ_U9CgNkw), I'm also biased by the "let's all just play > nice" mess that came from designating incompatible "versions" of SPF as > competing experiments (see https://tools.ietf.org/html/rfc6686 for the > eventual outcome of that six year long experiment). > I'm not sure I understand the comparison. ARC, as far as I know, doesn't have two factions attempting to advance their own agendas in a common space. We have just one protocol here. Instead, the bulk of the debate has been about whether this WG is prepared to stand behind its processing via the standards track, and I thought we were leaning toward the answer to that being "no" right now, and the core issue is whether we want it to be standards track first or have an RFC number first. If getting it published in some state is more critical than having it on the standards track, then "experimental" is, to me, the only option right now. And that's what I think I said in Singapore. I think that any protocol which has not already been widely implemented is, > in some sense, experimental - if you are looking at it from the perspective > of hind-sight, you might have done some things differently/more > efficiently/etc. One might not have called IPv6 "IP"-anything or may have > chosen a longer address space for IPv4 for instance. > > I'm willing to go along with the consensus of the group, but wanted to > (re)express my continued opposition to the experimental track for this. > Dave Crocker can probably articulate this better than me, but I'll take a run at it. There are two primary drivers for this decision for me: 1) ARC is trying to do something that's different enough from DKIM (i.e., recording some kind of handling chain) that we really should have some deployment and impact experience before we can say we have enough confidence to call it a proposed standard; and 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 real-world experiments, which to my knowledge haven't happened. Unless I've somehow missed a change in posture either by him or by the specification (which is entirely possible), we're not done enough to say it ought to be on the standards track. The counter-argument to (1) is that Proposed Standard really is only a proposal, but I think our goals are loftier than that here. Then again DKIM went out PS, right? Well yes, it did, but we weren't in any perceived hurry that I can recall. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Clarifying the value of arc.closest-fail
On Wed, Jan 3, 2018 at 12:39 AM, Bron Gondwana wrote: > On Wed, 3 Jan 2018, at 04:34, Kurt Andersen (b) wrote: > > As I went through the edits for https://tools.ietf.org/htm > l/draft-ietf-dmarc-arc-protocol-10#section-5.2.1 I was unable to > understand the value added by having the "arc.closest-fail" listed in the > AAR. > > Without a closest-fail from each step, or a similar way to determine > changes, information about abuses gets lost along the chain, and the final > receiver can't tell who modified the message along the way. > So, if we have a message that goes through four mailing lists before final delivery, each of which modify the subject and everyone is "doing the right thing" (I know that's not exactly an abuse scenario), we would expect: * ARC 1: cv=none, closest-fail=0 * ARC 2: cv=pass, closest-fail=0 * ARC 3: cv=pass, closest-fail=1 * ARC 4: cv=pass, closest-fail=2 * final recipient ADMD ARC verifier would find cv=pass and evaluate closest-fail at 3 Is that what you have in mind? --Kurt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Section 5.2.1, header.ds considered confusing
In article you write: >header.s is NOT defined: https://www.iana.org/assignments/email-auth/email- >auth.xhtml Quite right, need to put it in the IANA considerations of something. FWIW, I added header.s to my SMTP daemon this afternoon. It took about 10 minuutes. I'm a pretty good programmer, but I'm not *that* good. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Clarifying the value of arc.closest-fail
On Wed, 3 Jan 2018, at 04:34, Kurt Andersen (b) wrote: > As I went through the edits for > https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10#section-5.2.1 > I was unable to understand the value added by having the "arc.closest- > fail" listed in the AAR. Please read my examples again if the problem wasn't clear, because you don't get security by imagining the best cases where everyone behaves themselves, you get security by imagining that everybody is trying to get away with the worst abuses they can without being detected. Without a closest-fail from each step, or a similar way to determine changes, information about abuses gets lost along the chain, and the final receiver can't tell who modified the message along the way. > Looking back through the list archives, the idea for this pvalue seems > to have come up in mid-August, captured in this snippet:> > On Wed, Sep 6, 2017 at 4:02 AM, Bron Gondwana > wrote:>> __ >> >> On Wed, 6 Sep 2017, at 07:52, Seth Blank wrote: >>> On Mon, Aug 14, 2017 at 5:12 PM, Bron Gondwana >>> wrote:>>> > That seems like it would be enough to >>> fix that objection. An >>> > additional "first AMS failure" header at each hop would give you a >>> > list of who actually modified the message.>>> >>> arc.closest_fail has been defined to accomplish this. >> >> That looks great. It adds enough information that my other questions >> are basically efficiency concerns, which are not nothing, but at >> least ARC signing doesn't make things worse...> > It seems that Bron is advocating a change in the verify process where > by all AMS signatures would have to be checked rather than just the > most recent one. Going through the archives showed me that the > language in 5.2.1 should say "...the most recent AMS that fails to > validate..." rather than "...the most recent AS that fails to > validate..." but then the verifier actions would also need to be > updated in section 6 (steps 3+). Yes, it should say most recent AMS, not AS. All AS should always validate. > If we are only concerned with changes in the body of the message > which are being introduced by intermediaries, it seems like we could > just check for changes in the bh value between hops rather than > requiring each verifier to walk (possibly) the whole list of AMS > headers. No, that's bogus. The message is not the body, the message is body+subject+from+to. In particular, a bad actor intermediate could totally change the meaning of a message by changing the subject. Messages where the majority of meaning is in the subject definitely exist. Subject: Please clean out your stuff from the fridge Body: Thanks, Bron. vs Subject: URGENT: your need to paypal $5000 to f...@bar.com TODAY or we will lose $IMPORTANT_CONTRACT Body: Thanks, Bron. Both have the same bh=, but they're very different messages. > Does this provide enough "bang for the buck" to make it worthwhile? or > should we cut out this field? If we cut the field, then ARC usage guidelines need to say "don't seal if you didn't change the message" or we're breaking the value of the chain. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd br...@fastmailteam.com ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Section 5.2.1, header.ds considered confusing
On Tue, Jan 2, 2018 at 9:44 PM, Seth Blank wrote: > 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 note from earlier this morning. header.s is >> already defined for 7601, we just need to indicate that it needs to be >> added into the A-R and AAR rather than leaving it to chance. >> > > header.s is NOT defined: https://www.iana.org/ > assignments/email-auth/email-auth.xhtml > > That's why I explicitly mentioned in the earlier thread about IANA > registrations (https://mailarchive.ietf.org/arch/msg/dmarc/72GKJ1mMd6Pc5_D > WYGgnLE-Uzxw) that we'd need to add it after 7601bis. > > To John's point, this is why I've been pushing hard for 7601bis, adding > header.s to DKIM is far cleaner than trying to do header.ds in arc > directly. This is why I asked question #2 in this thread: > https://mailarchive.ietf.org/arch/msg/dmarc/xUUbT15vqoBmH7RraJ_pesrd9z0 > I'm just not getting (from reading the text of 7601 several times today) how including an extra ptype makes a "normative redefinition" of 7601. RFC7001 clearly says that additional ptypes are expected over time. If anything, we're considering a "normative redefinition" of 6008 which talks about listing info for more than one DKIM header, but I think the term is a misnomer. It appears to me that the "7601 replaces all former definitions" work was just incompletely implemented by IANA. We can certainly patch over those gaps as we care about the data for ARC within our spec, but it seems like having an IANA errata for 7601 would be a cleaner and more apropos vehicle. --Kurt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
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 note from earlier this morning. header.s is > already defined for 7601, we just need to indicate that it needs to be > added into the A-R and AAR rather than leaving it to chance. > header.s is NOT defined: https://www.iana.org/assignments/email-auth/email- auth.xhtml That's why I explicitly mentioned in the earlier thread about IANA registrations (https://mailarchive.ietf.org/arch/msg/dmarc/72GKJ1mMd6Pc5_ DWYGgnLE-Uzxw) that we'd need to add it after 7602bis. To John's point, this is why I've been pushing hard for 7601bis, adding header.s to DKIM is far cleaner than trying to do header.ds in arc directly. This is why I asked question #2 in this thread: https://mailarchive.ietf.org/arch/msg/dmarc/xUUbT15vqoBmH7RraJ_pesrd9z0 Seth ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Section 5.2.1, header.ds considered confusing
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 note from earlier this morning. header.s is already defined for 7601, we just need to indicate that it needs to be added into the A-R and AAR rather than leaving it to chance. --Kurt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Section 5.2.1, header.ds considered confusing
I don't see the point of the header.ds field. We already have header.d, so why not just add header.s? If there are two DKIM validations, the A-R header will look like this, no confusion I can see: Authentication-Results: example.com; ... dkim=pass header.d=foo.com header.s=abc; header.b="A9hX4wGQ"; dkim=none header.d=bar.com header.s=def; header.b="4icXsmdd"; ... Bonus question: so what would this mean? Authentication-Results: example.com; ... dkim=pass header.d=foo.com header.ds=bar.com,abc; header.b="A9hX4wGQ"; ... Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ARC draft-10 Section 10 - Algorithm Rotation - can we address separately?
On Tue, 2 Jan 2018, Kurt Andersen (b) wrote: I don't think this will be super complicated, but I do think it would be a mistake to try and publish now and then retrofit rather than adding it before we publish. I agree (which is why I started off with the first draft that is currently found in https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10#section-10). The mechanics of one doc, two docs, three docs more (can you tell that I've been cleaning out Dr. Seuss from my bookshelves over the break?) is less important to me than having a workable strategy. Migrations are always the hardest part of an implementation. Oh, good. For reasons outlined in previous messages, I'm pretty sure that without some changes to the current spec, the only way to do a migration will be to invent new headers (ARC-2-Seal: ARC-2-Message-Signature: ...) which would look awfully silly. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ARC draft-10 protocol elements section and question about reducing section 8
On Fri, Dec 29, 2017 at 12:44 AM, Seth Blank wrote: > 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) > > This also opens the question of where Section 8 ( > https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10#section-8) > belongs. This section now feels more like a kitchen sink and implementation > guidance. > Both section changes noted in my edits-in-progress for -11. --Kurt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ARC draft-10 Section 10 - Algorithm Rotation - can we address separately?
On Fri, Dec 29, 2017 at 6:36 PM, John R Levine wrote: > I still don't understand why we need to say more than DKIM did on this >> topic. > > > I don't think this will be super complicated, but I do think it would be a > mistake to try and publish now and then retrofit rather than adding it > before we publish. > I agree (which is why I started off with the first draft that is currently found in https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10#section-10). The mechanics of one doc, two docs, three docs more (can you tell that I've been cleaning out Dr. Seuss from my bookshelves over the break?) is less important to me than having a workable strategy. Migrations are always the hardest part of an implementation. --Kurt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ARC draft: Call for ARC Implementations to be included
On Fri, Dec 29, 2017 at 1:23 AM, Seth Blank wrote: > The Implementation Status section of the draft ( > https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10#section-14) > feels out of date. > Yes - I forgot to update that in the -10 version. I've added in information about MessageSystems Momentum, Oracle, MAIL::DKIM. I've also incorporated Murray's note and an update for OpenARC. I'll reach out to contacts at Cloudmark/Proofpoint to see what their status might be for the various MTA systems that they support. --Kurt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ARC draft questions (speak up!): Experimental Status and Considerations
On Fri, Dec 29, 2017 at 12:15 AM, Seth Blank wrote: > 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, > https://mailarchive.ietf.org/arch/msg/dmarc/4Gu1EErK4iuo9pQnZ-uJ2tKpMDQ, > https://mailarchive.ietf.org/arch/msg/dmarc/X-3nVPUQgIy-AGt4tJfkbPZZTjI), > I was under the impression that working group consensus was that ARC would > be submitted as an Experimental draft. > > I know Kurt has very strong opinions that we NOT proceed as Experimental, > and I wanted to make sure he got to state his case. > > 1) Unless a chair speaks up that consensus is already Experimental, we > should have the conversation now and nail this down. > Citing from https://datatracker.ietf.org/doc/minutes-99-dmarc/: Barry: When ready for WGLC? > Kurt: New draft tomorrow, hope to be ready for LC in a week. > 4a. Document status discussion > Dave Crocker: Suggest experimental for now because the operational issues > associated with the chain of signing aren't known. Revisit when ready for > a BCP. Kurt: Have enough implementations to make a proposed standard. Murray: If it's WGLC in a week, I'd prefer experimental. If we take more > time, then proposed standard. Decision: We will continue discussing on the list, and will not hold up > WGLC for this issue. We need to have a working group decision by the time > we request publication (after WGLC). It's quite clear that my assertion of being ready for LC before the end of July 2017 was a wild flight of fancy; but I'm glad to see that I didn't entirely invent the interpretation of continuing on a "proposed standard" path. While John Levine cited the benefits of the "experimental" approach taken for EAI ( https://mailarchive.ietf.org/arch/msg/dmarc/gvUecJuYLT9GIh5zbcZ_U9CgNkw), I'm also biased by the "let's all just play nice" mess that came from designating incompatible "versions" of SPF as competing experiments (see https://tools.ietf.org/html/rfc6686 for the eventual outcome of that six year long experiment). I think that any protocol which has not already been widely implemented is, in some sense, experimental - if you are looking at it from the perspective of hind-sight, you might have done some things differently/more efficiently/etc. One might not have called IPv6 "IP"-anything or may have chosen a longer address space for IPv4 for instance. I'm willing to go along with the consensus of the group, but wanted to (re)express my continued opposition to the experimental track for this. --Kurt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Clarifying the value of arc.closest-fail
As I went through the edits for https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10#section-5.2.1 I was unable to understand the value added by having the "arc.closest-fail" listed in the AAR. Looking back through the list archives, the idea for this pvalue seems to have come up in mid-August, captured in this snippet: On Wed, Sep 6, 2017 at 4:02 AM, Bron Gondwana wrote: > On Wed, 6 Sep 2017, at 07:52, Seth Blank wrote: > > On Mon, Aug 14, 2017 at 5:12 PM, Bron Gondwana > wrote: > > That seems like it would be enough to fix that objection. An additional > "first AMS failure" header at each hop would give you a list of who > actually modified the message. > > arc.closest_fail has been defined to accomplish this. > > That looks great. It adds enough information that my other questions are > basically efficiency concerns, which are not nothing, but at least ARC > signing doesn't make things worse... > It seems that Bron is advocating a change in the verify process where by all AMS signatures would have to be checked rather than just the most recent one. Going through the archives showed me that the language in 5.2.1 should say "...the most recent AMS that fails to validate..." rather than "...the most recent AS that fails to validate..." but then the verifier actions would also need to be updated in section 6 (steps 3+). If we are only concerned with changes in the body of the message which are being introduced by intermediaries, it seems like we could just check for changes in the bh value between hops rather than requiring each verifier to walk (possibly) the whole list of AMS headers. Does this provide enough "bang for the buck" to make it worthwhile? or should we cut out this field? --Kurt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ARC spec clean up if 7601bis proceeds
On Fri, Dec 29, 2017 at 12:58 AM, Seth Blank wrote: > 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. > Yes > Section 5.2.1 is stricken. > No - the instance variable is still germane. We may choose to move it elsewhere, but the info needs to stay. > New IANA registrations (I'm pretty certain this is wrong!): > authentication-results methods: dkim header.s > header.s is already defined in RFC6376 section 7.2 so I don't think that it needs further citation. > authentication-results methods: arc smtp.client-id > Should be smtp.client-ip no "id". > authentication-results methods: arc chain.closest-fail > See separate thread (Clarifying the value of arc.closest-fail) that I'm about to spin up. > authentication-results results: arc pass|fail|none|policy > Reading this, and initially conflating it with the cv values, I think that we should work on clarifying the wording to distinguish between the purely mechanical "did you check the ARC chain and, if so, is it valid?" vs the what did you do as a result of said information. Currently, this information is not called for in the A-R or AAR, just in the modified DMARC report to senders. Would we want to add it to the A-R/AAR as arc.effect? We could then have arc.cv for the mechanical result and arc.effect (none|pass|fail|other) for the policy-mediated impact on processing the message. > After this, I believe most of section 9 (except 9.3) can be stricken or > greatly reduced into verifier actions. > We can see. It may take a bit more work on the verifier section or better clarity/organization. --Kurt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ARC draft-10 protocol elements section and question about reducing section 8
> On Dec 29, 2017, at 12:29 PM, Murray S. Kucherawy wrote: > > Chairs, should we start using the WG's issue tracker for this stuff? Speaking as an observer, I personally would find that helpful. Thanks, Stan >> On Thu, Dec 28, 2017 at 4:44 PM, Seth Blank wrote: >> 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 have been an oversight. >> >> To be clear about the protocol elements section, I've cribbed it from DKIM >> and proposed it to: >> a) provide context for the entire ARC Chain >> b) define protocol components that are not specific to only sealing or >> validating the chain >> >> As such, I believe both the concept of chain validation status and the >> ordering of hops belong in protocol elements. > > +1. > >> This also opens the question of where Section 8 >> (https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10#section-8) >> belongs. This section now feels more like a kitchen sink and implementation >> guidance. >> >> I would suggest: >> >> 8.1 be stricken as it's a normative modification of DKIM, or replaced with >> language to the effect of "ARC MUST be the last signer of the message; >> otherwise it cannot be validated on receipt." which can go in signer actions >> >> 8.2 should be moved to protocol elements >> >> 8.3 to signer actions >> >> 8.4 to verifier actions > > +1 to all of those. > >> 8.5 should be stricken (this is bad advice that could result in backscatter, >> and I'm unsure where it came from, I can find no working group conversation >> around this) > > It is a reasonable choice, however. That is: If you're going to give an SMTP > reply, this is the right one to use, but maybe warn that backscatter (and > provide or reference a definition of that term) can result. > > -MSK > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
