Re: [dmarc-ietf] WGLC will be on ARC-16
> I'll bring this up during DNSOP on Wednesday. Thanks, Tim. Barry ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] WGLC will be on ARC-16
Barry I'll bring this up during DNSOP on Wednesday. Any issues we just blame Murray? of course not. Tim DNSOP tri-chair On Mon, Jul 16, 2018 at 4:02 PM, Barry Leiba wrote: > We have a good set of comments on -15, and thanks, everyone, for that. > Kurt and Seth, please make the changes that make sense based on the > discussion, and publish -16 when you've done that. When I see -16 go > up, I'll put it into working-group last call. > > At the same time, I'll also ask the DNS directorate to have a look at > it. As has been noted, we don't think there's an issue here, but I do > agree that it's better to alert the directorate to take a gander. > > Barry, DMARC chair > > ___ > 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
Re: [dmarc-ietf] WGLC on draft-ietf-dmarc-rfc7601bis-02
On Tue, Jul 17, 2018 at 10:49 AM, John Levine wrote: > Try this: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc- > rfc7601bis-02=rfc7601 > > Looks OK to me. I have some minor editorial niggles about the wording > of the EAI advice, but the substance is fine. > > [re-adding dmarc@ietf.org, removing i...@ietf.org] What are they? This is WGLC, now's the time. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] WGLC will be on ARC-16
On Mon, Jul 16, 2018 at 4:02 PM, Barry Leiba wrote: > We have a good set of comments on -15, and thanks, everyone, for that. > Kurt and Seth, please make the changes that make sense based on the > discussion, and publish -16 when you've done that. When I see -16 go > up, I'll put it into working-group last call. > > At the same time, I'll also ask the DNS directorate to have a look at > it. As has been noted, we don't think there's an issue here, but I do > agree that it's better to alert the directorate to take a gander. > I have been advocating for punting some of Jim's points on the basis that we don't want to derail the experiment that is ARC. I believe we punted on some of Bron's points as well early on. I've taken this position because I think the thing that's critical here is to determine if ARC, in operation, provides any meaningful signal (or indeed, any damage) that we need to capture to solve the problem this working group is chartered to address. I'm assuming that we will return and give these deferred points due consideration when we complete the experiment and come back around to doing a standards track version. Note that "due consideration" only guarantees discussion; it does not guarantee that we'll come back and change things. Am I wrong about any of this? Should we be sticking some of these deferred items in to the WG tracker so we don't forget about them later? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
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 thing to do, from the standpoint of both DNS load and also > extra lookups for the verifier. > Jim, what if section 11.3.2 has a specific clause around one output of the experiment being guidance on AS/AMS d=/s= binding language? ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-16.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance WG of the IETF. Title : Authenticated Received Chain (ARC) Protocol Authors : Kurt Andersen Brandon Long Seth Blank Murray Kucherawy Tim Draegen Filename: draft-ietf-dmarc-arc-protocol-16.txt Pages : 35 Date: 2018-07-17 Abstract: The Authenticated Received Chain (ARC) protocol allows Internet Mail Handlers to attach assertions of message authentication state to individual messages. As messages traverse ARC-enabled Internet Mail Handlers, additional ARC assertions can be attached to messages to form ordered sets of ARC assertions that represent authentication state along each step of message handling paths. ARC-enabled Internet Mail Handlers can process sets of ARC assertions to inform message disposition decisions, to identify Internet Mail Handlers that might break existing authentication mechanisms, and to convey original authentication state across trust boundaries. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-16 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-protocol-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-protocol-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] WGLC will be on ARC-16
On Mon, Jul 16, 2018 at 1:02 PM, Barry Leiba wrote: > We have a good set of comments on -15, and thanks, everyone, for that. > Kurt and Seth, please make the changes that make sense based on the > discussion, and publish -16 when you've done that. When I see -16 go > up, I'll put it into working-group last call. > Have at it - I've just posted -16: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance WG of the IETF. Title : Authenticated Received Chain (ARC) Protocol Filename: draft-ietf-dmarc-arc-protocol-16.txt Pages : 35 Date: 2018-07-17 The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-16 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-protocol-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-protocol-16 --Kurt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Partial Review of: draft-ietf-dmarc-arc-protocol-16
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 the -16 draft and see some basic and pervasive language problems that are serious enough to make it likely that a reader will misunderstand core ARC concepts. I've suggested alternative language, where I could. d/ Detail: Abstract The Authenticated Received Chain (ARC) protocol allows Internet Mail Handlers to attach assertions of message authentication state to individual messages. As messages traverse ARC-enabled Internet Mail Handlers, additional ARC assertions can be attached to messages to form ordered sets of ARC assertions that represent authentication state along each step of message handling paths. ARC-enabled Internet Mail Handlers can process sets of ARC assertions to inform message disposition decisions, to identify Internet Mail Handlers that might break existing authentication mechanisms, and to convey original authentication state across trust boundaries. My review of -14 noted problems with the abstract. While there have been some changes, the Abstract remains too... abstract. While the current text is better it really does not provide simple, direct statements about the problem(s) ARC is addressing nor the solution or benefit that it enables. Text like this needs to be written for people who are not trained in theoretical computer science and are not already deeply enmeshed in this work. For convenience, here's what I wrote in the -14 review, for a suggested change: I suggest adding this existing, excellent sentence from the Intro: ARC provides an authenticated "chain of custody" for a message, allowing each entity that handles the message to see what entities handled it before, and to see what the authentication status of the message was at each step in the handling. (I added 'authenticated'.) Note also that while typical discussion of ARC refers to it as establishing a chain of custody, no language like that is in the Abstract. I think that's a serious omission. Consider the 'general concepts' section, below and the sub-topics. Note that nothing like 'assertions of message authentication state' shows up there. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. General Concepts . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Evidence . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Custody . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Chain of Custody . . . . . . . . . . . . . . . . . . . . 5 2.4. Validation of Chain of Custody . . . . . . . . . . . . . 5 3. Terminology and Definitions . . . . . . . . . . . . . . . . . 5 3.1. ARC Set . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Authenticated Received Chain (ARC) . . . . . . . . . . . 6 3.3. Sealer . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Validator . . . . . . . . . . . . . . . . . . . . . . . . 7 3.5. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . 7 3.6. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . 7 4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 7 4.1. ARC Headers . . . . . . . . . . . . . . . . . . . . . . . 7 4.1.1. ARC-Authentication-Results (AAR) . . . . . . . . . . 8 4.1.2. ARC-Message-Signature (AMS) . . . . . . . . . . . . . 8 4.1.3. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . 9 4.2. ARC Set . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2.1. Instance Tags . . . . . . . . . . . . . . . . . . . . 10 4.3. Authenticated Received Chain . . . . . . . . . . . . . . 11 4.4. Chain Validation Status . . . . . . . . . . . . . . . . . 11 5. Protocol Actions . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Sealer Actions . . . . . . . . . . . . . . . . . . . . . 12 5.1.1. Header Fields To Include In ARC-Seal Signatures . . . 13 5.1.2. Marking and Sealing "cv=fail" (Invalid) Chains . . . 13 5.1.3. Only One Authenticated Received Chain Per Message . . 13 5.1.4. Broad Ability to Seal . . . . . . . . . . . . . . . . 14 5.1.5. Sealing is Always Safe . . . . . . . . . . . . . . . 14 5.1.6. Signing vs Sealing . . . . . . . . . . . . . . . . . 14 5.2. Validator Actions . . . . . . . . . . . . . . . . . . . . 14 Andersen, et al.Expires January 18, 2019[Page 2] Internet-DraftARC-Protocol July 2018 5.2.1. All Failures Are Permanent . . . . . . . . . . . . . 16 5.2.2. Responding to ARC Validation Failures During the SMTP Transaction . .
Re: [dmarc-ietf] WGLC on draft-ietf-dmarc-rfc7601bis-02
https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-rfc7601bis-02=rfc7601 Looks OK to me. I have some minor editorial niggles about the wording of the EAI advice, but the substance is fine. In section 5: For messages that are EAI-formatted messages, this test is done after converting A-labels into U-labels. -> In authentication service identifiers in EAI-formatted messages, a U-label and its equivalent A-label are considered to be the same. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
