From nobody Tue Jul 3 09:06:27 2018 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BD09D1310C1; Tue, 3 Jul 2018 09:00:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: dmarc@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153063362576.4893.17537500720791344211.idtracker@ietfa.amsl.com> Date: Tue, 03 Jul 2018 09:00:25 -0700 Archived-At: Subject: [dmarc-ietf] dmarc - Requested session has been scheduled for IETF 102 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.26 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 16:00:36 -0000 Dear Barry Leiba, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. dmarc Session 1 (1:00 requested) Thursday, 19 July 2018, Morning Session I 0930-1200 Room Name: Saint-Paul/Sainte-Catherine size: 100 --------------------------------------------- Special Note: 1100 - 1200 iCalendar: https://datatracker.ietf.org/meeting/102/sessions/dmarc.ics Request Information: --------------------------------------------------------- Working Group Name: Domain-based Message Authentication, Reporting & Conformance Area Name: Applications and Real-Time Area Session Requester: Barry Leiba Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 30 Conflicts to Avoid: First Priority: artarea dcrup dispatch iasa2 cfrg jmap saag cbor People who must be present: Ned Freed Barry Leiba Alexey Melnikov Tim Draegen Resources Requested: Experimental Room Setup (U-Shape and classroom, subject to availability) Special Requests: Chair has to leave Thursday night, so please avoid Friday --------------------------------------------------------- From nobody Mon Jul 9 15:01:34 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9747D13108B for ; Mon, 9 Jul 2018 15:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UFe8j2qNMps for ; Mon, 9 Jul 2018 15:01:30 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74CFC13107D for ; Mon, 9 Jul 2018 15:01:30 -0700 (PDT) Received: from steel.local (sfosf0017s350801.wiline.com [64.71.6.2] (may be forged)) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id w69M1Rtx013712 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 9 Jul 2018 15:01:29 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1531173689; bh=wyKxRJRnwx95OwqRzgop42UvXVMMemFl1bNVwOZUn24=; h=Subject:References:From:To:Date:In-Reply-To; b=jQ1fT20ogCjhNxS56C1damsgUwAlnS6z0sPgixuxvP58303r7nodF9tP3SCDVaRM9 3as6cia0mqQDu6e8s+MP1Og+nbmtg9brquQaxOLBchofDtxgIRNqrTTmeBaioS7WwN L5tMRacG6PeMpLynYoX2xsYbQyc2J2tbFi2sUbEo= References: From: Jim Fenton To: dmarc@ietf.org Message-ID: <96be85f9-dd0e-4259-47f4-2e7c425c404c@bluepopcorn.net> Date: Mon, 9 Jul 2018 15:01:21 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC protocol-15 posted X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 22:01:33 -0000 On 6/24/18 9:27 PM, Kurt Andersen wrote: > I've now posted draft 15 of the ARC protocol. It should be ready for > last call - please review with that in mind. Note that the XML was a > little wacky in the Implementation Status section. I'll fix that > formatting in the next rev. I'm very late in reviewing the ARC protocol, and I apologize for that, as well as for not keeping up with the discussions on this list. So please consider the below to be a "external review" -- I suspect that other reviewers outside the WG will have many of the same questions/comments. Substantive issues: General: I see lots of references to "authentication state", beginning with two references in the abstract, but I don't see the term defined anywhere. Perhaps add to the general concepts (section 2). 2.1: "modify message content": Might not be clear whether this includes the message header or only the body. 4. Protocol elements: It's not immediately evident to me why we need new header fields here rather than extensions to existing header fields: - AAR is basically an Authentication-Results with an added instance tag; why not just do that? - AMS says that it's basically a DKIM-Signature header field with an instance tag and no version. Why not just add an optional instance tag to DKIM-Signature? But I do see a semantic difference that isn't listed in 4.1.2. The order of inclusion of "instanced" header fields is based on the instance number, not simply bottom-up as in DKIM. I can see why this is done, since header field ordering isn't guaranteed to be preserved. But I haven't found anything that fully orders the header fields in this case; do the "instanced" header fields go before the others, after the others, or some other way? Note that even if distinct header field names are used, the h= value in the DKIM-Signature specifies what's included, not the order. - AS: I'm having trouble understanding what this is for. Why do we need another layer of signature on top of that in the AMS? In the ABNF for the AMS header field (and others), where is "instance" defined? "Authentication-Results header fields MUST NOT be included in AMS signatures": This seems harsh, especially since Section 5 of 7601bis (cited, also RFC 7601) make inclusion of Authentication-Results a MAY. Is there a reason for the much more restrictive wording here? 4.2.1: Instance tag value range: Why 50? That seems like an arbitrary choice; is there some other basis for it? Informational paragraph: Since the cited DCRUP work has passed IESG approval (just got a state update to "Waiting on RFC Editor" as I type this), it sounds like the ARC-MULTI stuff ought to be here rather than in a separate document. But there are other reasons for having multiple DKIM-Signatures on a message, such as key rotation. ARC needs to be able to deal with this; perhaps it's all covered in ARC-MULTI which I haven't read yet. 5.1.1: As noted above, needs to completely specify the order in which header fields are supplied to the hash function (both ARC and non-ARC header fields). 5.2 step 5 et seq: Are some of the following steps sub-steps to 5 (done repeatedly for each ARC set)? There's a colon there but not sure how far it goes. 5.2.2 conflicts with the second to last paragraph in 5.2 that a message with a failing ARC MUST be treated the same as one with no ARC. 9.1 is not a security consideration, or at least it's not in expressed in terms of how an attacker might exploit ARC to cause problems with header size. 10. I don't see any other reference to header.s so I'm not sure what the bracketed comment at the beginning is referring to. 10.2 I'm not clear on why there is an IANA consideration for the "s" signature tag (perhaps this is the header.s above). 13.2 Not clear to me why previous revisions of this draft are included as informative references. ARC-MULTI (IMO) should be included in this draft. ENHANCED-STATUS looks like a normative reference to me. Some of the references to 7601bis might also be normative; can these be changed to 7601 (non-bis)? Appendix B: It would be really, really helpful to have at least one example here. ===== Nits: 1. paragraph 3, "each individual processing results" -> "each individual processing result" 3. paragraph 3, "is directly relevant" -> "are directly relevant" 3.5 (imported ABNF tokens) looks like it would go better being adjacent to the imported terms in section 3. 4.1.2 second bullet "AMS header" -> "AMS header field" 4.1.2 first bullet of second group "should" -> "SHOULD" 4.1.3 second bullet "Section" is repeated 4.1.3 fifth bullet "h" header -> "h" tag Might want to run idnits on the draft; it especially doesn't like the URIs in 13.3 (perhaps just include needed URIs inline in the text). ===== -Jim From nobody Mon Jul 9 19:28:29 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F09AF1310A9 for ; Mon, 9 Jul 2018 19:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vrGyVDnTQ-g for ; Mon, 9 Jul 2018 19:28:24 -0700 (PDT) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11E85130DD5 for ; Mon, 9 Jul 2018 19:28:24 -0700 (PDT) Received: by mail-ed1-x534.google.com with SMTP id x5-v6so11738957edr.0 for ; Mon, 09 Jul 2018 19:28:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=LZKhfDzc0bMmSGivPrOTQpS3m1ZA0mw+jI5V9EYwloQ=; b=L1R+hq+/uVg9vikwzkQk/COeMWut+hIGZGzKUgUP30tGvao3WdaCcUe/v43G+BBJwi Na26LMPyt8o0I/+Mgk8NI/xB0hNTlQ07JElDzSdATVVsW+2qjdhZosJrGw3p09ofWbHZ sTyi0R+/amz1+45KwyFD8wN/JwemqP9Sp4QCc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=LZKhfDzc0bMmSGivPrOTQpS3m1ZA0mw+jI5V9EYwloQ=; b=MrMIQ/AkhxoIJvAh3LDyFQ8hnV+t5Lx2TvzqnzL6FNrjhSmHqFh5kK8CjNFE45yj8H gJuDRAhcm0tz9tM3VmALqZi2YLuvbiyj1D0VXxBNHs2Os8QA5bEWhX46cygLTdZf4n71 /NvdCwgXTuoiRyhXZkCjXAswiYC4Yr+MBDlJM7lQ7r3VwOPp3BRKVzKSxOscOVz5hERg yQoxAOl5dz5dWlT2t68a+a+Ll8DXnBLQBvnwiJKICBngckkFsRzCNa8cpHeZQQmA89GP pWkX+K3rsrbhPtMrw8Shw/YZhvOiq/t+4MzmeL3DH8EX3G5K9Ri3uiWc8EvO8vpvCnlr ooQw== X-Gm-Message-State: AOUpUlHsoAaUID8A52WChRT2obeMRFXwv34FdVifYwNgB30k6kygtH6X Lv2cqosdgCgM6NIJSBHHfmbn8tHlUhBE6N4TTFE4OsX1 X-Google-Smtp-Source: AAOMgpfcSuzbbzSmspbGpjlH3c/RZ7RL02ToBEqXjp+CneTl9uvKhUYIGKjisOvoeqtFrnwR07m2e2WsWCzgiN1+Hls= X-Received: by 2002:aa7:d993:: with SMTP id u19-v6mr10378694eds.125.1531189702466; Mon, 09 Jul 2018 19:28:22 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 2002:aa7:da87:0:0:0:0:0 with HTTP; Mon, 9 Jul 2018 19:28:21 -0700 (PDT) In-Reply-To: <96be85f9-dd0e-4259-47f4-2e7c425c404c@bluepopcorn.net> References: <96be85f9-dd0e-4259-47f4-2e7c425c404c@bluepopcorn.net> From: "Kurt Andersen (b)" Date: Mon, 9 Jul 2018 19:28:21 -0700 X-Google-Sender-Auth: NjfgypFgrvnexLo5E5631zL549U Message-ID: To: Jim Fenton Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000004caf7d05709be2de" Archived-At: Subject: Re: [dmarc-ietf] ARC protocol-15 posted X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 02:28:27 -0000 --0000000000004caf7d05709be2de Content-Type: text/plain; charset="UTF-8" On Mon, Jul 9, 2018 at 3:01 PM, Jim Fenton wrote: > On 6/24/18 9:27 PM, Kurt Andersen wrote: > >> I've now posted draft 15 of the ARC protocol. It should be ready for last >> call - please review with that in mind. Note that the XML was a little >> wacky in the Implementation Status section. I'll fix that formatting in the >> next rev. >> > > I'm very late in reviewing the ARC protocol, and I apologize for that, as > well as for not keeping up with the discussions on this list. So please > consider the below to be a "external review" -- I suspect that other > reviewers outside the WG will have many of the same questions/comments. > Terrific - thanks for going through it. Responses to your questions inline below. > Substantive issues: > > General: I see lots of references to "authentication state", beginning > with two references in the abstract, but I don't see the term defined > anywhere. Perhaps add to the general concepts (section 2). > While I understand your question, is the combination of the two terms not self-evident? Is it something that needs to be further expanded upon? If so, can you suggest some language which might have satisfied your uncertainty? > 2.1: "modify message content": Might not be clear whether this includes > the message header or only the body. > Intended in the most broad sense: header, body, or both. We can add a parenthetical comment to clarify. > 4. Protocol elements: It's not immediately evident to me why we need new > header fields here rather than extensions to existing header fields: > > - AAR is basically an Authentication-Results with an added instance tag; > why not just do that? > Because A-R is ephemeral and, per 7601 both can and should be deleted at will. > - AMS says that it's basically a DKIM-Signature header field with an > instance tag and no version. Why not just add an optional instance tag to > DKIM-Signature? But I do see a semantic difference that isn't listed in > 4.1.2. The order of inclusion of "instanced" header fields is based on the > instance number, not simply bottom-up as in DKIM. I can see why this is > done, since header field ordering isn't guaranteed to be preserved. But I > haven't found anything that fully orders the header fields in this case; do > the "instanced" header fields go before the others, after the others, or > some other way? Note that even if distinct header field names are used, the > h= value in the DKIM-Signature specifies what's included, not the order. > The ordering is clearly defined - when "h=" cites (using abbreviated header names) "DKIM:DKIM:Date:AAR:AMS:AAR:AMS:AAR:AMS" that would be AAR[1]:AMS[1]:AAR[2]:AMS[2]" per the definition. - AS: I'm having trouble understanding what this is for. Why do we need > another layer of signature on top of that in the AMS? > Because the AS, signing only the ARC chain headers, provides a less fragile/more resilient mechanism for chain continuity. By scoping to just the ARC chain, we expect less collateral breakage than any signature which covers arbitrary headers and body. > In the ABNF for the AMS header field (and others), where is "instance" > defined? > instance is defined in section 3.6 > "Authentication-Results header fields MUST NOT be included in AMS > signatures": This seems harsh, especially since Section 5 of 7601bis > (cited, also RFC 7601) make inclusion of Authentication-Results a MAY. Is > there a reason for the much more restrictive wording here? > Yes, and it goes back to the "ephemerality" of A-R headers. We want to avoid signing any content which downstream handlers can arbitrarily delete. > 4.2.1: Instance tag value range: Why 50? That seems like an arbitrary > choice; is there some other basis for it? > The choice of 50 is somewhat arbitrary, in that it could equally well be 49 or 75. Early versions specified values up to 1024 would be legal, but since the working group felt that handling chains over 10 ADMDs to be fairly unlikely, we thought that a 5x margin should be sufficient without allowing completely ridiculous header bloat. > Informational paragraph: Since the cited DCRUP work has passed IESG > approval (just got a state update to "Waiting on RFC Editor" as I type > this), it sounds like the ARC-MULTI stuff ought to be here rather than in a > separate document. But there are other reasons for having multiple > DKIM-Signatures on a message, such as key rotation. ARC needs to be able to > deal with this; perhaps it's all covered in ARC-MULTI which I haven't read > yet. > Yes, it's the ARC-MULTI doc. We split them so that we can get the basic protocol through WGLC before wrestling through multiple algorithms and algorithm migration. > 5.1.1: As noted above, needs to completely specify the order in which > header fields are supplied to the hash function (both ARC and non-ARC > header fields). > Will review the text to clarify. > 5.2 step 5 et seq: Are some of the following steps sub-steps to 5 (done > repeatedly for each ARC set)? There's a colon there but not sure how far it > goes. > The colon is a typo, should be a period. > 5.2.2 conflicts with the second to last paragraph in 5.2 that a message > with a failing ARC MUST be treated the same as one with no ARC. > Not really, but the process is not clearly spelled out. If an incoming message fails to have a passing DMARC result and the ARC chain does not provide sufficient information (or trusted information) to mitigate a resulting "REJECT" policy, then a message can be REJECTed during the SMTP transaction with this extended result. No ARC chain would have the same result as a failing one in such a case. > 9.1 is not a security consideration, or at least it's not in expressed in > terms of how an attacker might exploit ARC to cause problems with header > size. > I agree that this is not really a security issue - but it is a potential operational one. Where should this caution be moved do? > 10. I don't see any other reference to header.s so I'm not sure what the > bracketed comment at the beginning is referring to. > > 10.2 I'm not clear on why there is an IANA consideration for the "s" > signature tag (perhaps this is the header.s above). > Yes, the "s" tag is the "header.s" ptype when more fully specified. I'll clarify the note to the editor. > 13.2 Not clear to me why previous revisions of this draft are included as > informative references. ARC-MULTI (IMO) should be included in this draft. > ENHANCED-STATUS looks like a normative reference to me. Some of the > references to 7601bis might also be normative; can these be changed to 7601 > (non-bis)? > The previous versions are cited because some of the implementations listed in section 12 were built to earlier versions and have not necessarily been vetted against the current version. With the removal of section 12 upon publication, those earlier versions can also be dropped. The references to 7601bis will be normative, but only once the updated document number is issued. I don't think that we can cite a "bis" as a normative reference. > Appendix B: It would be really, really helpful to have at least one > example here. > Yes, planning to...up until version -13, we had carried some very old examples which were now causing more confusion as people looked at the examples rather than the text. > ===== > Nits: > Thanks again! --Kurt --0000000000004caf7d05709be2de Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Jul 9, 2018 at 3:01 PM, Jim Fenton <fenton@bluepopcorn.net>= ; wrote:
On 6/24/= 18 9:27 PM, Kurt Andersen wrote:
I've now posted draft 15 of the ARC protocol. It should be ready for la= st call - please review with that in mind. Note that the XML was a little w= acky in the Implementation Status section. I'll fix that formatting in = the next rev.

 I'm very late in reviewing the ARC protocol, and I apologize for that, = as well as for not keeping up with the discussions on this list. So please = consider the below to be a "external review" -- I suspect that ot= her reviewers outside the WG will have many of the same questions/comments.=

Terrific - thanks for going through it= . Responses to your questions inline below.
=C2=A0
Substantive issues:

General: I see lots of references to "authentication state", begi= nning with two references in the abstract, but I don't see the term def= ined anywhere. Perhaps add to the general concepts (section 2).

While I understand your question, is the combinati= on of the two terms not self-evident? Is it something that needs to be furt= her expanded upon? If so, can you suggest some language which might have sa= tisfied your uncertainty?
=C2=A0
2.1: "modify message content": Might not be clear whether thi= s includes the message header or only the body.

Intended in the most broad sense: header, body, or both. We can ad= d a parenthetical comment to clarify.
=C2=A0
4. Protocol elements: It's not immediately evident to m= e why we need new header fields here rather than extensions to existing hea= der fields:

- AAR is basically an Authentication-Results with an added instance tag; wh= y not just do that?

Because A-R is ephe= meral and, per 7601 both can and should be deleted at will.
=C2= =A0
- AMS says that it's basically a DKIM-Signature header field with an in= stance tag and no version. Why not just add an optional instance tag to DKI= M-Signature? But I do see a semantic difference that isn't listed in 4.= 1.2. The order of inclusion of "instanced" header fields is based= on the instance number, not simply bottom-up as in DKIM. I can see why thi= s is done, since header field ordering isn't guaranteed to be preserved= . But I haven't found anything that fully orders the header fields in t= his case; do the "instanced" header fields go before the others, = after the others, or some other way? Note that even if distinct header fiel= d names are used, the h=3D value in the DKIM-Signature specifies what's= included, not the order.

The ordering = is clearly defined - when "h=3D" cites (using abbreviated header = names) "DKIM:DKIM:Date:AAR:AMS:AAR:AMS:AAR:AMS" that would be AAR= [1]:AMS[1]:AAR[2]:AMS[2]" per the definition.

- AS: I'm having trouble understanding what this is for. Why do we need= another layer of signature on top of that in the AMS?

Because the AS, signing only the ARC chain headers, provide= s a less fragile/more resilient mechanism for chain continuity. By scoping = to just the ARC chain, we expect less collateral breakage than any signatur= e which covers arbitrary headers and body.
=C2=A0
In the ABNF for the AMS header field (and others), whe= re is "instance" defined?

ins= tance is defined in section 3.6
=C2=A0
"Authentication-Results header fields MUST NOT be included in AMS sign= atures": This seems harsh, especially since Section 5 of 7601bis (cite= d, also RFC 7601) make inclusion of Authentication-Results a MAY. Is there = a reason for the much more restrictive wording here?
<= br>
Yes, and it goes back to the "ephemerality" of A-R = headers. We want to avoid signing any content which downstream handlers can= arbitrarily delete.
=C2=A0
4= .2.1: Instance tag value range: Why 50? That seems like an arbitrary choice= ; is there some other basis for it?

The= choice of 50 is somewhat arbitrary, in that it could equally well be 49 or= 75. Early versions specified values up to 1024 would be legal, but since t= he working group felt that handling chains over 10 ADMDs to be fairly unlik= ely, we thought that a 5x margin should be sufficient without allowing comp= letely ridiculous header bloat.
=C2=A0
Informational paragraph: Since the cited DCRUP work has passed IESG approva= l (just got a state update to "Waiting on RFC Editor" as I type t= his), it sounds like the ARC-MULTI stuff ought to be here rather than in a = separate document. But there are other reasons for having multiple DKIM-Sig= natures on a message, such as key rotation. ARC needs to be able to deal wi= th this; perhaps it's all covered in ARC-MULTI which I haven't read= yet.

Yes, it's the ARC-MULTI doc. = We split them so that we can get the basic protocol through WGLC before wre= stling through multiple algorithms and algorithm migration.
=C2= =A0
5.1.1: As noted above, needs to com= pletely specify the order in which header fields are supplied to the hash f= unction (both ARC and non-ARC header fields).

Will review the text to clarify.=C2=A0
=C2=A0
5.2 step 5 et seq: Are some of the following steps = sub-steps to 5 (done repeatedly for each ARC set)? There's a colon ther= e but not sure how far it goes.

The col= on is a typo, should be a period.=C2=A0
=C2=A0
5.2.2 conflicts with the second to last paragraph in 5.2 = that a message with a failing ARC MUST be treated the same as one with no A= RC.

Not really, but the process is not = clearly spelled out. If an incoming message fails to have a passing DMARC r= esult and the ARC chain does not provide sufficient information (or trusted= information) to mitigate a resulting "REJECT" policy, then a mes= sage can be REJECTed during the SMTP transaction with this extended result.= No ARC chain would have the same result as a failing one in such a case.
=C2=A0
9.1 is not a security consideration, or at least it's not in expressed = in terms of how an attacker might exploit ARC to cause problems with header= size.

I agree that this is not really = a security issue - but it is a potential operational one. Where should this= caution be moved do?
=C2=A0
10. I don't see any other reference to header.s so I'm not sure wha= t the bracketed comment at the beginning is referring to.

10.2 I'm not clear on why there is an IANA consideration for the "= s" signature tag (perhaps this is the header.s above).

Yes, the "s" tag is the "header.s"= ptype when more fully specified. I'll clarify the note to the editor.<= /div>
=C2=A0
13.2 Not clear to me w= hy previous revisions of this draft are included as informative references.= ARC-MULTI (IMO) should be included in this draft. ENHANCED-STATUS looks li= ke a normative reference to me. Some of the references to 7601bis might als= o be normative; can these be changed to 7601 (non-bis)?

The previous versions are cited because some of the implem= entations listed in section 12 were built to earlier versions and have not = necessarily been vetted against the current version. With the removal of se= ction 12 upon publication, those earlier versions can also be dropped.

The references to 7601bis will be normative, but only = once the updated document number is issued. I don't think that we can c= ite a "bis" as a normative reference.
=C2=A0
Appendix B: It would be really, really helpful to= have at least one example here.

Yes, p= lanning to...up until version -13, we had carried some very old examples wh= ich were now causing more confusion as people looked at the examples rather= than the text.
=C2=A0
=3D=3D= =3D=3D=3D
Nits:

<eliding here - updates noted = for the next version of the spec>

Thanks again!=

--Kurt=C2=A0
--0000000000004caf7d05709be2de-- From nobody Tue Jul 10 12:18:48 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1FF1311A2 for ; Tue, 10 Jul 2018 12:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3aaBFHDNX0N for ; Tue, 10 Jul 2018 12:18:42 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5AFE131169 for ; Tue, 10 Jul 2018 12:18:41 -0700 (PDT) Received: from steel.local (sfosf0017s350801.wiline.com [64.71.6.2] (may be forged)) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id w6AJDCWc032191 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 10 Jul 2018 12:13:18 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1531249998; bh=qf8MWTJCfkikZm1cABXQWhl74eFPStZKf8pahbl1bfw=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=bi1uKopHBXMWFfp4Sd2azD/w43XR67KejtO4uZGz0jITharydcN2TQKkFX4Q+RYQM ht3eZfRtCBMQwRYwkQJQw5dtRxQi+nFRFo82x3Ylphv6H6Y+ksY3EilbapczMb8xAQ AADYqBA7dcyc+LWi2luDQhSUD5OQBLfv57dZoo5U= To: "Kurt Andersen (b)" Cc: "dmarc@ietf.org" References: <96be85f9-dd0e-4259-47f4-2e7c425c404c@bluepopcorn.net> From: Jim Fenton Message-ID: <968bd954-34a8-05ed-ceec-d4274107a773@bluepopcorn.net> Date: Tue, 10 Jul 2018 12:13:01 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------3A82F4B3CDFF272B79C125AA" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC protocol-15 posted X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 19:18:46 -0000 This is a multi-part message in MIME format. --------------3A82F4B3CDFF272B79C125AA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 7/9/18 7:28 PM, Kurt Andersen (b) wrote: > On Mon, Jul 9, 2018 at 3:01 PM, Jim Fenton > wrote: > > Substantive issues: > > General: I see lots of references to "authentication state", > beginning with two references in the abstract, but I don't see the > term defined anywhere. Perhaps add to the general concepts > (section 2). > > > While I understand your question, is the combination of the two terms > not self-evident? Is it something that needs to be further expanded > upon? If so, can you suggest some language which might have satisfied > your uncertainty? I wasn't clear on what all is included in authentication state. Is it just the question of whether the message currently passes an authentication check, or whether authentication is asserted by a third party through an ARC seal? While I think of it, I'm wondering if ARC covers message authentication via SPF or DKIM only. Presumably only the first hop from the originating ADMD would pass SPF, and then DKIM is used after that? It might be good to mention relationship with non-DKIM authentication somewhere. > > 4. Protocol elements: It's not immediately evident to me why we > need new header fields here rather than extensions to existing > header fields: > > - AAR is basically an Authentication-Results with an added > instance tag; why not just do that? > > > Because A-R is ephemeral and, per 7601 both can and should be deleted > at will. I'm fine with deleting clearly fraudulent A-R (spoofed A-R claiming to be from the receiving MTA's own ADMD). But IMO it's really unfortunate that 7601 is so free about (and even encourages) deleting A-R header fields, because in this case it means that they need to be, essentially, duplicated for ARC, with the message header bloat that entails. Is it possible for this spec to update 7601 by saying something like, "MTAs implementing ARC MUST NOT delete A-R header fields containing instance tags"? I need to think more about message paths containing a mixture of ARC-aware and ARC-unaware MTAs and whether there are any issues there, and would need to consider this as well. > - AMS says that it's basically a DKIM-Signature header field with > an instance tag and no version. Why not just add an optional > instance tag to DKIM-Signature? But I do see a semantic difference > that isn't listed in 4.1.2. The order of inclusion of "instanced" > header fields is based on the instance number, not simply > bottom-up as in DKIM. I can see why this is done, since header > field ordering isn't guaranteed to be preserved. But I haven't > found anything that fully orders the header fields in this case; > do the "instanced" header fields go before the others, after the > others, or some other way? Note that even if distinct header field > names are used, the h= value in the DKIM-Signature specifies > what's included, not the order. > > > The ordering is clearly defined - when "h=" cites (using abbreviated > header names) "DKIM:DKIM:Date:AAR:AMS:AAR:AMS:AAR:AMS" that would be > AAR[1]:AMS[1]:AAR[2]:AMS[2]" per the definition. OK; my recollection of how the DKIM h= tag/value works was incorrect. So the first DKIM picks up the bottommost signature and the second one picks up the second from the bottom, but the selection of AAR and AMS is based on instance number, not position. That's not ambiguous, but it would be good to point the header field ordering out as an additional (fourth) difference between AMS and DKIM-Signature in 4.1.2. > > - AS: I'm having trouble understanding what this is for. Why do we > need another layer of signature on top of that in the AMS? > > > Because the AS, signing only the ARC chain headers, provides a less > fragile/more resilient mechanism for chain continuity. By scoping to > just the ARC chain, we expect less collateral breakage than any > signature which covers arbitrary headers and body. The point of signing the body in DKIM was to make sure that there was no opportunity to splice a different body onto a validly signed message. This was considered important when we discussed the l= (length) tag/value on DKIM signatures, because there was concern that an attacker could append content to a message with a valid signature. My concern with this is that since AS isn't signing the body but is being depended upon for message handling decisions, this might be exploited by an attacker. This needs, at a minimum, to be a security consideration. > > In the ABNF for the AMS header field (and others), where is > "instance" defined? > > > instance is defined in section 3.6 Thanks; don't know how I missed it. It uses i=, which is already a DKIM tag. In describing the differences between AMS and DKIM-Signature, 4.1.2 should prohibit the DKIM use of i= in AMS. Or it should use a different tag letter. > > "Authentication-Results header fields MUST NOT be included in AMS > signatures": This seems harsh, especially since Section 5 of > 7601bis (cited, also RFC 7601) make inclusion of > Authentication-Results a MAY. Is there a reason for the much more > restrictive wording here? > > > Yes, and it goes back to the "ephemerality" of A-R headers. We want to > avoid signing any content which downstream handlers can arbitrarily > delete. OK; see above comment re 7601. > > 4.2.1: Instance tag value range: Why 50? That seems like an > arbitrary choice; is there some other basis for it? > > > The choice of 50 is somewhat arbitrary, in that it could equally well > be 49 or 75. Early versions specified values up to 1024 would be > legal, but since the working group felt that handling chains over 10 > ADMDs to be fairly unlikely, we thought that a 5x margin should be > sufficient without allowing completely ridiculous header bloat. Makes sense. Maybe include something informational to that effect? > > Informational paragraph: Since the cited DCRUP work has passed > IESG approval (just got a state update to "Waiting on RFC Editor" > as I type this), it sounds like the ARC-MULTI stuff ought to be > here rather than in a separate document. But there are other > reasons for having multiple DKIM-Signatures on a message, such as > key rotation. ARC needs to be able to deal with this; perhaps it's > all covered in ARC-MULTI which I haven't read yet. > > > Yes, it's the ARC-MULTI doc. We split them so that we can get the > basic protocol through WGLC before wrestling through multiple > algorithms and algorithm migration. I disagree with the split. I don't think this spec is complete without guidance on how to handle multiply-signed messages, which will become sharply more prevalent with the DCRUP work. > 5.1.1: As noted above, needs to completely specify the order in > which header fields are supplied to the hash function (both ARC > and non-ARC header fields). > > > Will review the text to clarify. > > 5.2 step 5 et seq: Are some of the following steps sub-steps to 5 > (done repeatedly for each ARC set)? There's a colon there but not > sure how far it goes. > > > The colon is a typo, should be a period. Please double-check this; step 6 at least reads like it's something done iteratively as introduced in step 5. > > 5.2.2 conflicts with the second to last paragraph in 5.2 that a > message with a failing ARC MUST be treated the same as one with no > ARC. > > > Not really, but the process is not clearly spelled out. If an incoming > message fails to have a passing DMARC result and the ARC chain does > not provide sufficient information (or trusted information) to > mitigate a resulting "REJECT" policy, then a message can be REJECTed > during the SMTP transaction with this extended result. No ARC chain > would have the same result as a failing one in such a case. 5.2.2 refers to an ARC validation failure, not a DMARC policy action. If a rejection occurs, it's DMARC that is doing that, not ARC. Perhaps there will need to be an update to DMARC to describe how it processes ARC results? > > 9.1 is not a security consideration, or at least it's not in > expressed in terms of how an attacker might exploit ARC to cause > problems with header size. > > > I agree that this is not really a security issue - but it is a > potential operational one. Where should this caution be moved do? I'm not sure there is a defined place. Perhaps an informational note in 4.3 where it's describing the chain as a whole would be an appropriate place for this. > 10. I don't see any other reference to header.s so I'm not sure > what the bracketed comment at the beginning is referring to. > > 10.2 I'm not clear on why there is an IANA consideration for the > "s" signature tag (perhaps this is the header.s above). > > > Yes, the "s" tag is the "header.s" ptype when more fully specified. > I'll clarify the note to the editor. > > 13.2 Not clear to me why previous revisions of this draft are > included as informative references. ARC-MULTI (IMO) should be > included in this draft. ENHANCED-STATUS looks like a normative > reference to me. Some of the references to 7601bis might also be > normative; can these be changed to 7601 (non-bis)? > > > The previous versions are cited because some of the implementations > listed in section 12 were built to earlier versions and have not > necessarily been vetted against the current version. With the removal > of section 12 upon publication, those earlier versions can also be > dropped. > > The references to 7601bis will be normative, but only once the updated > document number is issued. I don't think that we can cite a "bis" as a > normative reference. At publication, you shouldn't cite an Internet Draft at all since it will expire. Whether references are normative or informative doesn't depend on the status of the document, but on the nature of the reference. I'm under the impression that this document is ahead of 7601bis for publication. If it depends on things that are new in 7601bis, then it will need to wait for 7601bis to be published. Otherwise, suggest you make the references to 7601 instead. > > Appendix B: It would be really, really helpful to have at least > one example here. > > > Yes, planning to...up until version -13, we had carried some very old > examples which were now causing more confusion as people looked at the > examples rather than the text. Making sure that the example(s) is/are correct is an important thing to have reviewed carefully. This would be great to have before Last Call. -Jim --------------3A82F4B3CDFF272B79C125AA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 7/9/18 7:28 PM, Kurt Andersen (b) wrote:

On Mon, Jul 9, 2018 at 3:01 PM, Jim Fenton <fenton@bluepopcorn.net> wrote:
Substantive issues:

General: I see lots of references to "authentication state", beginning with two references in the abstract, but I don't see the term defined anywhere. Perhaps add to the general concepts (section 2).

While I understand your question, is the combination of the two terms not self-evident? Is it something that needs to be further expanded upon? If so, can you suggest some language which might have satisfied your uncertainty?

I wasn't clear on what all is included in authentication state. Is it just the question of whether the message currently passes an authentication check, or whether authentication is asserted by a third party through an ARC seal?

While I think of it, I'm wondering if ARC covers message authentication via SPF or DKIM only. Presumably only the first hop from the originating ADMD would pass SPF, and then DKIM is used after that? It might be good to mention relationship with non-DKIM authentication somewhere.
 
4. Protocol elements: It's not immediately evident to me why we need new header fields here rather than extensions to existing header fields:

- AAR is basically an Authentication-Results with an added instance tag; why not just do that?

Because A-R is ephemeral and, per 7601 both can and should be deleted at will.

I'm fine with deleting clearly fraudulent A-R (spoofed A-R claiming to be from the receiving MTA's own ADMD). But IMO it's really unfortunate that 7601 is so free about (and even encourages) deleting A-R header fields, because in this case it means that they need to be, essentially, duplicated for ARC, with the message header bloat that entails.

Is it possible for this spec to update 7601 by saying something like, "MTAs implementing ARC MUST NOT delete A-R header fields containing instance tags"? I need to think more about message paths containing a mixture of ARC-aware and ARC-unaware MTAs and whether there are any issues there, and would need to consider this as well.

 
- AMS says that it's basically a DKIM-Signature header field with an instance tag and no version. Why not just add an optional instance tag to DKIM-Signature? But I do see a semantic difference that isn't listed in 4.1.2. The order of inclusion of "instanced" header fields is based on the instance number, not simply bottom-up as in DKIM. I can see why this is done, since header field ordering isn't guaranteed to be preserved. But I haven't found anything that fully orders the header fields in this case; do the "instanced" header fields go before the others, after the others, or some other way? Note that even if distinct header field names are used, the h= value in the DKIM-Signature specifies what's included, not the order.

The ordering is clearly defined - when "h=" cites (using abbreviated header names) "DKIM:DKIM:Date:AAR:AMS:AAR:AMS:AAR:AMS" that would be AAR[1]:AMS[1]:AAR[2]:AMS[2]" per the definition.

OK; my recollection of how the DKIM h= tag/value works was incorrect. So the first DKIM picks up the bottommost signature and the second one picks up the second from the bottom, but the selection of AAR and AMS is based on instance number, not position. That's not ambiguous, but it would be good to point the header field ordering out as an additional (fourth) difference between AMS and DKIM-Signature in 4.1.2.

- AS: I'm having trouble understanding what this is for. Why do we need another layer of signature on top of that in the AMS?

Because the AS, signing only the ARC chain headers, provides a less fragile/more resilient mechanism for chain continuity. By scoping to just the ARC chain, we expect less collateral breakage than any signature which covers arbitrary headers and body.

The point of signing the body in DKIM was to make sure that there was no opportunity to splice a different body onto a validly signed message. This was considered important when we discussed the l= (length) tag/value on DKIM signatures, because there was concern that an attacker could append content to a message with a valid signature.

My concern with this is that since AS isn't signing the body but is being depended upon for message handling decisions, this might be exploited by an attacker. This needs, at a minimum, to be a security consideration. 
 
In the ABNF for the AMS header field (and others), where is "instance" defined?

instance is defined in section 3.6

Thanks; don't know how I missed it. It uses i=, which is already a DKIM tag. In describing the differences between AMS and DKIM-Signature, 4.1.2 should prohibit the DKIM use of i= in AMS. Or it should use a different tag letter.
 
"Authentication-Results header fields MUST NOT be included in AMS signatures": This seems harsh, especially since Section 5 of 7601bis (cited, also RFC 7601) make inclusion of Authentication-Results a MAY. Is there a reason for the much more restrictive wording here?

Yes, and it goes back to the "ephemerality" of A-R headers. We want to avoid signing any content which downstream handlers can arbitrarily delete.

OK; see above comment re 7601.
 
4.2.1: Instance tag value range: Why 50? That seems like an arbitrary choice; is there some other basis for it?

The choice of 50 is somewhat arbitrary, in that it could equally well be 49 or 75. Early versions specified values up to 1024 would be legal, but since the working group felt that handling chains over 10 ADMDs to be fairly unlikely, we thought that a 5x margin should be sufficient without allowing completely ridiculous header bloat.

Makes sense. Maybe include something informational to that effect?
 
Informational paragraph: Since the cited DCRUP work has passed IESG approval (just got a state update to "Waiting on RFC Editor" as I type this), it sounds like the ARC-MULTI stuff ought to be here rather than in a separate document. But there are other reasons for having multiple DKIM-Signatures on a message, such as key rotation. ARC needs to be able to deal with this; perhaps it's all covered in ARC-MULTI which I haven't read yet.

Yes, it's the ARC-MULTI doc. We split them so that we can get the basic protocol through WGLC before wrestling through multiple algorithms and algorithm migration.

I disagree with the split. I don't think this spec is complete without guidance on how to handle multiply-signed messages, which will become sharply more prevalent with the DCRUP work.

 
5.1.1: As noted above, needs to completely specify the order in which header fields are supplied to the hash function (both ARC and non-ARC header fields).

Will review the text to clarify. 
 
5.2 step 5 et seq: Are some of the following steps sub-steps to 5 (done repeatedly for each ARC set)? There's a colon there but not sure how far it goes.

The colon is a typo, should be a period.

Please double-check this; step 6 at least reads like it's something done iteratively as introduced in step 5.
 
5.2.2 conflicts with the second to last paragraph in 5.2 that a message with a failing ARC MUST be treated the same as one with no ARC.

Not really, but the process is not clearly spelled out. If an incoming message fails to have a passing DMARC result and the ARC chain does not provide sufficient information (or trusted information) to mitigate a resulting "REJECT" policy, then a message can be REJECTed during the SMTP transaction with this extended result. No ARC chain would have the same result as a failing one in such a case.

5.2.2 refers to an ARC validation failure, not a DMARC policy action. If a rejection occurs, it's DMARC that is doing that, not ARC. Perhaps there will need to be an update to DMARC to describe how it processes ARC results?
 
9.1 is not a security consideration, or at least it's not in expressed in terms of how an attacker might exploit ARC to cause problems with header size.

I agree that this is not really a security issue - but it is a potential operational one. Where should this caution be moved do?

I'm not sure there is a defined place. Perhaps an informational note in 4.3 where it's describing the chain as a whole would be an appropriate place for this.

 
10. I don't see any other reference to header.s so I'm not sure what the bracketed comment at the beginning is referring to.

10.2 I'm not clear on why there is an IANA consideration for the "s" signature tag (perhaps this is the header.s above).

Yes, the "s" tag is the "header.s" ptype when more fully specified. I'll clarify the note to the editor.
 
13.2 Not clear to me why previous revisions of this draft are included as informative references. ARC-MULTI (IMO) should be included in this draft. ENHANCED-STATUS looks like a normative reference to me. Some of the references to 7601bis might also be normative; can these be changed to 7601 (non-bis)?

The previous versions are cited because some of the implementations listed in section 12 were built to earlier versions and have not necessarily been vetted against the current version. With the removal of section 12 upon publication, those earlier versions can also be dropped.

The references to 7601bis will be normative, but only once the updated document number is issued. I don't think that we can cite a "bis" as a normative reference.

At publication, you shouldn't cite an Internet Draft at all since it will expire. Whether references are normative or informative doesn't depend on the status of the document, but on the nature of the reference. I'm under the impression that this document is ahead of 7601bis for publication. If it depends on things that are new in 7601bis, then it will need to wait for 7601bis to be published. Otherwise, suggest you make the references to 7601 instead.
 
Appendix B: It would be really, really helpful to have at least one example here.

Yes, planning to...up until version -13, we had carried some very old examples which were now causing more confusion as people looked at the examples rather than the text.

Making sure that the example(s) is/are correct is an important thing to have reviewed carefully. This would be great to have before Last Call.

-Jim

--------------3A82F4B3CDFF272B79C125AA-- From nobody Tue Jul 10 12:43:19 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7EB513104C for ; Tue, 10 Jul 2018 12:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSOQMd8d3P0C for ; Tue, 10 Jul 2018 12:43:15 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74DE5130DF7 for ; Tue, 10 Jul 2018 12:43:14 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id t21-v6so17635707lji.0 for ; Tue, 10 Jul 2018 12:43:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7gBbxe2NDVaTnzE3HKpkNAuujkQhlUB/Mt1tOa8vKWA=; b=qDRfL5jTCnyFw9Xm//6846X9VVhQwqnROQYKTrTPfUtcW74NQULwG66lWtj3kIx0wi YCz55WuqGJjtaXFiMmD33pDsKNBaeS8gqQD69c464xAkhRChZ7giKGJ1gvyQPEpvKdee fKqWpoFVMTElw9xAkzuTmG+rhKzear5LgjhOabrM1q4ARhrMY1HoTD4wWauuC1c6GdUk 0GVOEe7UYQRA1ck/vv5r/8iXjLseVqqK5xMJXy8j08pYLagWxIjGLSnqKYmimJ/Sb/QQ liXMRZBIErU97myDIOFRK3zYF+/9sDSfEDfslDwnPnneMShw6DnU0nKGflqkwlw8Sbvn iP5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7gBbxe2NDVaTnzE3HKpkNAuujkQhlUB/Mt1tOa8vKWA=; b=AT5bd7faHI/YNQzo6Qhto/ID0qfDJGUZlTcbpd47KAbTutbJcE8ru3fc8kZ36PeBKY DPdEi2mCuEEme+Iz+7mc3e8Wf0On6JQPc5bBluxZhD4nP1o36mrq3FLWk29/ghvkrn3o x+kbQk/mZMYVuYf7E4jXQGuK8/AMJFXH5od+Gmdd3NN8lsndwG38bV4b/ru4NyWejMqI 0eGp4HhqYwQsZcJKv9xnNyqMam+BUWYVBsxUKB7iWZcuLfAnV3hGOblmGA/hi5KB97k8 6vC3ql3JALV0BaCoHX29Z26H/z8AfRupxMBkKuBigWvrLYPIX7/n1KqoPPaqMglgFYXZ i2MQ== X-Gm-Message-State: APt69E1quoLOhtZtdbt1G1rnqlrL23qIIGZVw3SwiD8xXE5ULXTgtGMV 1amk3vuqiKP20Ar9dlrPiKkPaaSgIL/zc9W72+kzRg== X-Google-Smtp-Source: AAOMgpdvZH27n2ZI7SZpHO2pchKzQNFYNS/8Q4AnnaEFzjFBA6epVVBXTqa6irgYh2hGuGbiwe485CHqmCkJUTrAyac= X-Received: by 2002:a2e:9004:: with SMTP id h4-v6mr15615253ljg.44.1531251792549; Tue, 10 Jul 2018 12:43:12 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:3a13:0:0:0:0:0 with HTTP; Tue, 10 Jul 2018 12:43:11 -0700 (PDT) In-Reply-To: <968bd954-34a8-05ed-ceec-d4274107a773@bluepopcorn.net> References: <96be85f9-dd0e-4259-47f4-2e7c425c404c@bluepopcorn.net> <968bd954-34a8-05ed-ceec-d4274107a773@bluepopcorn.net> From: "Murray S. Kucherawy" Date: Tue, 10 Jul 2018 12:43:11 -0700 Message-ID: To: Jim Fenton Cc: "Kurt Andersen (b)" , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000281c830570aa57fc" Archived-At: Subject: Re: [dmarc-ietf] ARC protocol-15 posted X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 19:43:18 -0000 --000000000000281c830570aa57fc Content-Type: text/plain; charset="UTF-8" On Tue, Jul 10, 2018 at 12:13 PM, Jim Fenton wrote: > On 7/9/18 7:28 PM, Kurt Andersen (b) wrote: > > On Mon, Jul 9, 2018 at 3:01 PM, Jim Fenton > wrote: > >> Substantive issues: >> >> General: I see lots of references to "authentication state", beginning >> with two references in the abstract, but I don't see the term defined >> anywhere. Perhaps add to the general concepts (section 2). >> > > While I understand your question, is the combination of the two terms not > self-evident? Is it something that needs to be further expanded upon? If > so, can you suggest some language which might have satisfied your > uncertainty? > > > I wasn't clear on what all is included in authentication state. Is it just > the question of whether the message currently passes an authentication > check, or whether authentication is asserted by a third party through an > ARC seal? > Since this is a general question, a general reply: What ARC seeks to do is capture what the sealer saw in terms of authentication results at the time it handled the message, and attach those results to the message in a way that they cannot later be falsified. That collection of results coupled with the identity of the sealer is what I think is meant by "authentication state". While I think of it, I'm wondering if ARC covers message authentication via > SPF or DKIM only. Presumably only the first hop from the originating ADMD > would pass SPF, and then DKIM is used after that? It might be good to > mention relationship with non-DKIM authentication somewhere. > I think ARC is agnostic about particular methods. It just records all of that state and passes it forward. It's up to the receiver (mainly a DMARC processor) to decide what to do with it. > > >> 4. Protocol elements: It's not immediately evident to me why we need new >> header fields here rather than extensions to existing header fields: >> >> - AAR is basically an Authentication-Results with an added instance tag; >> why not just do that? >> > > Because A-R is ephemeral and, per 7601 both can and should be deleted at > will. > > > I'm fine with deleting clearly fraudulent A-R (spoofed A-R claiming to be > from the receiving MTA's own ADMD). But IMO it's really unfortunate that > 7601 is so free about (and even encourages) deleting A-R header fields, > because in this case it means that they need to be, essentially, duplicated > for ARC, with the message header bloat that entails. > RFC7601 doesn't require or encourage deletion of A-R fields in general. (The strongest word is "could".) If it's valid and possibly useful downstream, you can certainly keep it. It only says you have to delete stuff that's clearly a forgery. > Is it possible for this spec to update 7601 by saying something like, > "MTAs implementing ARC MUST NOT delete A-R header fields containing > instance tags"? I need to think more about message paths containing a > mixture of ARC-aware and ARC-unaware MTAs and whether there are any issues > there, and would need to consider this as well. > It could. > > > > - AS: I'm having trouble understanding what this is for. Why do we need >> another layer of signature on top of that in the AMS? >> > > Because the AS, signing only the ARC chain headers, provides a less > fragile/more resilient mechanism for chain continuity. By scoping to just > the ARC chain, we expect less collateral breakage than any signature which > covers arbitrary headers and body. > > > The point of signing the body in DKIM was to make sure that there was no > opportunity to splice a different body onto a validly signed message. This > was considered important when we discussed the l= (length) tag/value on > DKIM signatures, because there was concern that an attacker could append > content to a message with a valid signature. > > My concern with this is that since AS isn't signing the body but is being > depended upon for message handling decisions, this might be exploited by an > attacker. This needs, at a minimum, to be a security consideration. > AMS is basically the same as DKIM-Signature, and so it covers body modifications. When you verify the seal, you must also verify the latest AMS, which in turn means the seal is invalidated as soon as someone changes the content. > > > 5.2.2 conflicts with the second to last paragraph in 5.2 that a message >> with a failing ARC MUST be treated the same as one with no ARC. >> > > Not really, but the process is not clearly spelled out. If an incoming > message fails to have a passing DMARC result and the ARC chain does not > provide sufficient information (or trusted information) to mitigate a > resulting "REJECT" policy, then a message can be REJECTed during the SMTP > transaction with this extended result. No ARC chain would have the same > result as a failing one in such a case. > > > 5.2.2 refers to an ARC validation failure, not a DMARC policy action. If a > rejection occurs, it's DMARC that is doing that, not ARC. Perhaps there > will need to be an update to DMARC to describe how it processes ARC results? > I agree that this needs to be said somewhere. One of the work items of this WG is a standards track update to DMARC, so it could be punted to there as well. > >> 9.1 is not a security consideration, or at least it's not in expressed in >> terms of how an attacker might exploit ARC to cause problems with header >> size. >> > > I agree that this is not really a security issue - but it is a potential > operational one. Where should this caution be moved do? > > > I'm not sure there is a defined place. Perhaps an informational note in > 4.3 where it's describing the chain as a whole would be an appropriate > place for this. > I disagree. If I can cause your MTA to crash because of oversized header fields, that's at least a denial of service attack. If I can cause your filter to crash because of oversized header fields and your MTA fails open, I can bypass whatever protections the filter offers. > > >> 10. I don't see any other reference to header.s so I'm not sure what the >> bracketed comment at the beginning is referring to. >> >> 10.2 I'm not clear on why there is an IANA consideration for the "s" >> signature tag (perhaps this is the header.s above). >> > > Yes, the "s" tag is the "header.s" ptype when more fully specified. I'll > clarify the note to the editor. > > The formatting in there is broken. It'll be easier to see what's going on when that gets fixed. But still, something needs to register "header.s". If these two documents go to the editor together, we'll jsut have to pick one to contain the registration and remove it from the other one. > >> 13.2 Not clear to me why previous revisions of this draft are included as >> informative references. ARC-MULTI (IMO) should be included in this draft. >> ENHANCED-STATUS looks like a normative reference to me. Some of the >> references to 7601bis might also be normative; can these be changed to 7601 >> (non-bis)? >> > > The previous versions are cited because some of the implementations listed > in section 12 were built to earlier versions and have not necessarily been > vetted against the current version. With the removal of section 12 upon > publication, those earlier versions can also be dropped. > > The references to 7601bis will be normative, but only once the updated > document number is issued. I don't think that we can cite a "bis" as a > normative reference. > > > At publication, you shouldn't cite an Internet Draft at all since it will > expire. Whether references are normative or informative doesn't depend on > the status of the document, but on the nature of the reference. I'm under > the impression that this document is ahead of 7601bis for publication. If > it depends on things that are new in 7601bis, then it will need to wait for > 7601bis to be published. Otherwise, suggest you make the references to 7601 > instead. > I disagree. I've had RFCs published that reference in-progress drafts, in one case one that never got published. But in this case, they would just hold this until 7601bis was also ready, and publish them as a cluster. -MSK --000000000000281c830570aa57fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 10, 2018 at 12:13 PM, Jim Fenton <fenton= @bluepopcorn.net> wrote:
=20 =20 =20

On 7/9/18 7:28 PM, Kurt Andersen (b) wrote:

=20
On Mon, Jul 9, 2018 a= t 3:01 PM, Jim Fenton <fenton@bluepopcorn.net> wrote:
Substant= ive issues:

General: I see lots of references to "authentication state", beginning with two references in the abstract, b= ut I don't see the term defined anywhere. Perhaps add to the general concepts (section 2).

While I understand your question, is the combination of the two terms not self-evident? Is it something that needs to be further expanded upon? If so, can you suggest some language which might have satisfied your uncertainty?

I wasn't clear on what all is included in authentication state. Is it just the question of whether the message currently passes an authentication check, or whether authentication is asserted by a third party through an ARC seal?

<= div>Since this is a general question, a general reply: What ARC seeks to do= is capture what the sealer saw in terms of authentication results at the t= ime it handled the message, and attach those results to the message in a wa= y that they cannot later be falsified.=C2=A0 That collection of results cou= pled with the identity of the sealer is what I think is meant by "auth= entication state".

While I think of it, I'm wondering if ARC covers message authentication via SPF or DKIM only. Presumably only the first hop from the originating ADMD would pass SPF, and then DKIM is used after that? It might be good to mention relationship with non-DKIM authentication somewhere.

I think= ARC is agnostic about particular methods.=C2=A0 It just records all of tha= t state and passes it forward.=C2=A0 It's up to the receiver (mainly a = DMARC processor) to decide what to do with it.


=C2=A0
4. Protocol elements: It's not immediately evident to me why we need new header fields here rather than extensions to existing header fields:

- AAR is basically an Authentication-Results with an added instance tag; why not just do that?

Because A-R is ephemeral and, per 7601 both can and should be deleted at will.

I'm fine with deleting clearly fraudulent A-R (spoofed A-R claiming to be from the receiving MTA's own ADMD). But IMO it's really unfortunate that 7601 is so free about (and even encourages) deleting A-R header fields, because in this case it means that they need to be, essentially, duplicated for ARC, with the message header bloat that entails.

RFC7601 d= oesn't require or encourage deletion of A-R fields in general.=C2=A0 (T= he strongest word is "could".)=C2=A0 If it's valid and possib= ly useful downstream, you can certainly keep it.=C2=A0 It only says you hav= e to delete stuff that's clearly a forgery.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
Is it possible for this spec to update 7601 by saying something like, "MTAs implementing ARC MUST NOT delete A-R header fields containing instance tags"? I need to think more about message path= s containing a mixture of ARC-aware and ARC-unaware MTAs and whether there are any issues there, and would need to consider this as well.

It could.


=C2=A0

- AS: I'm having trouble understanding what this is for. Why do we need another layer of signature on top of that in the AMS?

Because the AS, signing only the ARC chain headers, provides a less fragile/more resilient mechanism for chain continuity. By scoping to just the ARC chain, we expect less collateral breakage than any signature which covers arbitrary headers and body.

 The point of signing the body in DKIM was to make sure that there was no opportunity to splice a different body onto a validly signed message. This was considered important when we discussed the l=3D (length) tag/value on DKIM signatures, because there was concern that an attacker could append content to a message with a valid signature.

My concern with this is that since AS isn't signing the body but is being depended upon for message handling decisions, this might be exploited by an attacker. This needs, at a minimum, to be a security consideration.=C2=A0

AMS is = basically the same as DKIM-Signature, and so it covers body modifications.= =C2=A0 When you verify the seal, you must also verify the latest AMS, which= in turn means the seal is invalidated as soon as someone changes the conte= nt.
=C2=A0
=C2=A0
=
5.2.2 conflicts with the second to last paragraph in 5.2 that a message with a failing ARC MUST be treated the same as one with no ARC.

Not really, but the process is not clearly spelled out. If an incoming message fails to have a passing DMARC result and the ARC chain does not provide sufficient information (or trusted information) to mitigate a resulting "REJECT" policy, then a message can be RE= JECTed during the SMTP transaction with this extended result. No ARC chain would have the same result as a failing one in such a case.

5.2.2 refers to an ARC validation failure, not a DMARC policy action. If a rejection occurs, it's DMARC that is doing that, not ARC. Perhaps there will need to be an update to DMARC to describe how it processes ARC results?

I agree that this needs to be said somewhere.=C2= =A0 One of the work items of this WG is a standards track update to DMARC, = so it could be punted to there as well.

=C2=A0
9.1 is not a security consideration, or at least it's not in expressed in terms of how an attacker might exploit ARC to cause problems with header size.

I agree that this is not really a security issue - but it is a potential operational one. Where should this caution be moved do?

 I'm not sure there is a defined place. Perhaps an informational not= e in 4.3 where it's describing the chain as a whole would be an appropriate place for this.

I disagree.=C2=A0 If I can cause your MTA to crash b= ecause of oversized header fields, that's at least a denial of service = attack.=C2=A0 If I can cause your filter to crash because of oversized head= er fields and your MTA fails open, I can bypass whatever protections the fi= lter offers.


=C2=A0
10. I don't see any other reference to header.s so I'= m not sure what the bracketed comment at the beginning is referring to.

10.2 I'm not clear on why there is an IANA consideration for the "s" signature tag (perhaps this is the head= er.s above).

Yes, the "s" tag is the "header.s" pty= pe when more fully specified. I'll clarify the note to the editor.

<= div>The formatting in there is broken.=C2=A0 It'll be easier to see wha= t's going on when that gets fixed.=C2=A0 But still, something needs to = register "header.s".=C2=A0 If these two documents go to the edito= r together, we'll jsut have to pick one to contain the registration and= remove it from the other one.

=C2=A0
13.2 Not clear to me why previous revisions of this draft are included as informative references. ARC-MULTI (IMO) should be included in this draft. ENHANCED-STATUS looks like a normative reference to me. Some of the references to 7601bis might also be normative; can these be changed to 7601 (non-bis)?

The previous versions are cited because some of the implementations listed in section 12 were built to earlier versions and have not necessarily been vetted against the current version. With the removal of section 12 upon publication, those earlier versions can also be dropped.

The references to 7601bis will be normative, but only once the updated document number is issued. I don't think that we can cite a "bis" as a normative reference.<= /div>

At publication, you shouldn't cite an Internet Draft at all since i= t will expire. Whether references are normative or informative doesn'= t depend on the status of the document, but on the nature of the reference. I'm under the impression that this document is ahead of 7601bis for publication. If it depends on things that are new in 7601bis, then it will need to wait for 7601bis to be published. Otherwise, suggest you make the references to 7601 instead.

I disagree.=C2=A0 I= 've had RFCs published that reference in-progress drafts, in one case o= ne that never got published. =C2=A0 But in this case, they would just hold = this until 7601bis was also ready, and publish them as a cluster.

-MSK
--000000000000281c830570aa57fc-- From nobody Tue Jul 10 13:24:42 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A3F1311B5 for ; Tue, 10 Jul 2018 13:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0V4aAnTj0Sg4 for ; Tue, 10 Jul 2018 13:24:37 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16DF0130E73 for ; Tue, 10 Jul 2018 13:24:36 -0700 (PDT) Received: from steel.local (sfosf0017s350801.wiline.com [64.71.6.2] (may be forged)) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id w6AKOUO6003481 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 10 Jul 2018 13:24:31 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1531254273; bh=FL05O78i5pGH79f/JZNrhszTPgW+Ol2dmHsI/Awbw4E=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=OFw2eIM7oVpCgzDEW8r4157BsYltUB/x7n08SS+iq8zU2sBWciJkyeI7H+s1tabzf pNKakyuLaEPri3163fVW3OUUQvWgjMnVe10pDtMyyDT0R87+kWGLFWDtmf/aj+wY3h svagBX4lwKZqFr0YxGmNx77z/ZSeZyuy8X4XpsLg= To: "Murray S. Kucherawy" Cc: "Kurt Andersen (b)" , "dmarc@ietf.org" References: <96be85f9-dd0e-4259-47f4-2e7c425c404c@bluepopcorn.net> <968bd954-34a8-05ed-ceec-d4274107a773@bluepopcorn.net> From: Jim Fenton Message-ID: Date: Tue, 10 Jul 2018 13:24:25 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5EC755452C16B3BEDE5D624F" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC protocol-15 posted X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 20:24:40 -0000 This is a multi-part message in MIME format. --------------5EC755452C16B3BEDE5D624F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 7/10/18 12:43 PM, Murray S. Kucherawy wrote: > RFC7601 doesn't require or encourage deletion of A-R fields in > general.  (The strongest word is "could".)  If it's valid and possibly > useful downstream, you can certainly keep it.  It only says you have > to delete stuff that's clearly a forgery. I didn't go back and check the wording used in 7601 obviously. I was inferring from the language in 4.1.2, "are likely to be deleted". > >> - AS: I'm having trouble understanding what this is for. Why >> do we need another layer of signature on top of that in the AMS? >> >> >> Because the AS, signing only the ARC chain headers, provides a >> less fragile/more resilient mechanism for chain continuity. By >> scoping to just the ARC chain, we expect less collateral breakage >> than any signature which covers arbitrary headers and body. > > The point of signing the body in DKIM was to make sure that there > was no opportunity to splice a different body onto a validly > signed message. This was considered important when we discussed > the l= (length) tag/value on DKIM signatures, because there was > concern that an attacker could append content to a message with a > valid signature. > > My concern with this is that since AS isn't signing the body but > is being depended upon for message handling decisions, this might > be exploited by an attacker. This needs, at a minimum, to be a > security consideration. > > > AMS is basically the same as DKIM-Signature, and so it covers body > modifications.  When you verify the seal, you must also verify the > latest AMS, which in turn means the seal is invalidated as soon as > someone changes the content. Which goes back to my original question. If you need to check the AMS anyway, what additional purpose does the AS serve? >> 9.1 is not a security consideration, or at least it's not in >> expressed in terms of how an attacker might exploit ARC to >> cause problems with header size. >> >> >> I agree that this is not really a security issue - but it is a >> potential operational one. Where should this caution be moved do? > > I'm not sure there is a defined place. Perhaps an informational > note in 4.3 where it's describing the chain as a whole would be an > appropriate place for this. > > > I disagree.  If I can cause your MTA to crash because of oversized > header fields, that's at least a denial of service attack.  If I can > cause your filter to crash because of oversized header fields and your > MTA fails open, I can bypass whatever protections the filter offers. In that case, I'm fine if this is expressed in terms of a security threat. But any ARC-specific nature to this threat is a marginal case; an attacker could do the same in most cases by just adding lots of garbage header fields. >> 13.2 Not clear to me why previous revisions of this draft are >> included as informative references. ARC-MULTI (IMO) should be >> included in this draft. ENHANCED-STATUS looks like a >> normative reference to me. Some of the references to 7601bis >> might also be normative; can these be changed to 7601 (non-bis)? >> >> >> The previous versions are cited because some of the >> implementations listed in section 12 were built to earlier >> versions and have not necessarily been vetted against the current >> version. With the removal of section 12 upon publication, those >> earlier versions can also be dropped. >> >> The references to 7601bis will be normative, but only once the >> updated document number is issued. I don't think that we can cite >> a "bis" as a normative reference. > > At publication, you shouldn't cite an Internet Draft at all since > it will expire. Whether references are normative or informative > doesn't depend on the status of the document, but on the nature of > the reference. I'm under the impression that this document is > ahead of 7601bis for publication. If it depends on things that are > new in 7601bis, then it will need to wait for 7601bis to be > published. Otherwise, suggest you make the references to 7601 instead. > > > I disagree.  I've had RFCs published that reference in-progress > drafts, in one case one that never got published.   But in this case, > they would just hold this until 7601bis was also ready, and publish > them as a cluster. OK, it's possible that this has been done. But the important question is, does this draft need to wait for 7602bis to be published? -Jim --------------5EC755452C16B3BEDE5D624F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 7/10/18 12:43 PM, Murray S. Kucherawy wrote:
RFC7601 doesn't require or encourage deletion of A-R fields in general.  (The strongest word is "could".)  If it's valid and possibly useful downstream, you can certainly keep it.  It only says you have to delete stuff that's clearly a forgery.

I didn't go back and check the wording used in 7601 obviously. I was inferring from the language in 4.1.2, "are likely to be deleted".

- AS: I'm having trouble understanding what this is for. Why do we need another layer of signature on top of that in the AMS?

Because the AS, signing only the ARC chain headers, provides a less fragile/more resilient mechanism for chain continuity. By scoping to just the ARC chain, we expect less collateral breakage than any signature which covers arbitrary headers and body.

 The point of signing the body in DKIM was to make sure that there was no opportunity to splice a different body onto a validly signed message. This was considered important when we discussed the l= (length) tag/value on DKIM signatures, because there was concern that an attacker could append content to a message with a valid signature.

My concern with this is that since AS isn't signing the body but is being depended upon for message handling decisions, this might be exploited by an attacker. This needs, at a minimum, to be a security consideration. 

AMS is basically the same as DKIM-Signature, and so it covers body modifications.  When you verify the seal, you must also verify the latest AMS, which in turn means the seal is invalidated as soon as someone changes the content.

Which goes back to my original question. If you need to check the AMS anyway, what additional purpose does the AS serve?

 
9.1 is not a security consideration, or at least it's not in expressed in terms of how an attacker might exploit ARC to cause problems with header size.

I agree that this is not really a security issue - but it is a potential operational one. Where should this caution be moved do?

 I'm not sure there is a defined place. Perhaps an informational note in 4.3 where it's describing the chain as a whole would be an appropriate place for this.

I disagree.  If I can cause your MTA to crash because of oversized header fields, that's at least a denial of service attack.  If I can cause your filter to crash because of oversized header fields and your MTA fails open, I can bypass whatever protections the filter offers.

In that case, I'm fine if this is expressed in terms of a security threat. But any ARC-specific nature to this threat is a marginal case; an attacker could do the same in most cases by just adding lots of garbage header fields.

 
13.2 Not clear to me why previous revisions of this draft are included as informative references. ARC-MULTI (IMO) should be included in this draft. ENHANCED-STATUS looks like a normative reference to me. Some of the references to 7601bis might also be normative; can these be changed to 7601 (non-bis)?

The previous versions are cited because some of the implementations listed in section 12 were built to earlier versions and have not necessarily been vetted against the current version. With the removal of section 12 upon publication, those earlier versions can also be dropped.

The references to 7601bis will be normative, but only once the updated document number is issued. I don't think that we can cite a "bis" as a normative reference.

 At publication, you shouldn't cite an Internet Draft at all since it will expire. Whether references are normative or informative doesn't depend on the status of the document, but on the nature of the reference. I'm under the impression that this document is ahead of 7601bis for publication. If it depends on things that are new in 7601bis, then it will need to wait for 7601bis to be published. Otherwise, suggest you make the references to 7601 instead.

I disagree.  I've had RFCs published that reference in-progress drafts, in one case one that never got published.   But in this case, they would just hold this until 7601bis was also ready, and publish them as a cluster.

OK, it's possible that this has been done. But the important question is, does this draft need to wait for 7602bis to be published?

-Jim

--------------5EC755452C16B3BEDE5D624F-- From nobody Tue Jul 10 22:48:25 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D2C130E02 for ; Tue, 10 Jul 2018 22:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBc2woYqfJwX for ; Tue, 10 Jul 2018 22:48:17 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41C12130DE9 for ; Tue, 10 Jul 2018 22:48:17 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id v9-v6so8120092ljk.4 for ; Tue, 10 Jul 2018 22:48:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QBrHsZwDdziNbzGjRj+tZkIPybb78wxo9ZQI1NuKE3s=; b=d8lFaxQ5w1PAjb5Jti5C1BU3wWppi6Y0EVgdcGppL1OG8Byj9bDShEXED2/6qE9uIX JeFGagy7I030MlhloMruIqe6t8yH8j8YyQCRw4RPkx8Qg8yp14FwFMJ0Eabw2mnO9b9I zwe7IUmF0MghcxPLLt4tG+XuRM7sq43Oiw7lStn4mvOUCVN1syoUzqzlN7Yo8NG+FtJU b5pp0GuAguP9Sd0EK5sg9Hc/Z58EagoWmZ3pnsX71uvBQeHfq71wl0OJFy+cB7UAimsI ZTTxcSR7yCzfhyI9uHa0PCfk7TRJTaAwrRbcrcsPXAnqe2O9uK8yaQSdBevfvXQdtGQg tMlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QBrHsZwDdziNbzGjRj+tZkIPybb78wxo9ZQI1NuKE3s=; b=O5IM5h+dzKVCiLf/r1dZvNVFKiZ4SsIoMYJ7SBQM7AZN0Xm/mpMynk0wR/9xAi30Lz vCOlvpfMc1/gRHvJBBlFS4fWjnghe2W7+s3FfzWjbBXcb7LJxPzA+t4gKFRokAVt/afo cHyemqE9yOS+m0jOOjkw39Ez643PB+C03GkPPlaii1y+rsd+3ub8wYn8q9GP/qWjPjBg hxJrLWPkhNfTEbXcV4hLGYmh31SfBeLVLRM1Ya5duudA2g1y0z4x/LHXZzC/w6HyCwvg duXk9+bZCXWye6TA46j+kdgva1c+JDOFoEA1rOQu5g6MSbXWIYX/E1WpB9VRdvunTO7P ltJw== X-Gm-Message-State: APt69E1NDD5+r+Zm3ZQl4HbfE1A2eZRtZFsaBnr4EdLeJt1MzdbxvhM+ NkIvwTl1ioZRXfiL3gcvf/YvrWI8EYQqCC4tfldSNQ== X-Google-Smtp-Source: AAOMgpdGi0ZzyFBO+H2Llbdxrfm+WV4RHTySjPExv9Lcaje8Oceaq5TbF84xm4/m+eV/cnqyl3Rg4/QQoUhaVKPmt9E= X-Received: by 2002:a2e:4186:: with SMTP id d6-v6mr16303917ljf.36.1531288095337; Tue, 10 Jul 2018 22:48:15 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:3a13:0:0:0:0:0 with HTTP; Tue, 10 Jul 2018 22:48:14 -0700 (PDT) In-Reply-To: References: <96be85f9-dd0e-4259-47f4-2e7c425c404c@bluepopcorn.net> <968bd954-34a8-05ed-ceec-d4274107a773@bluepopcorn.net> From: "Murray S. Kucherawy" Date: Tue, 10 Jul 2018 22:48:14 -0700 Message-ID: To: Jim Fenton Cc: "Kurt Andersen (b)" , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f8b0640570b2cacd" Archived-At: Subject: Re: [dmarc-ietf] ARC protocol-15 posted X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 05:48:20 -0000 --000000000000f8b0640570b2cacd Content-Type: text/plain; charset="UTF-8" On Tue, Jul 10, 2018 at 1:24 PM, Jim Fenton wrote: > On 7/10/18 12:43 PM, Murray S. Kucherawy wrote: > > > AMS is basically the same as DKIM-Signature, and so it covers body > modifications. When you verify the seal, you must also verify the latest > AMS, which in turn means the seal is invalidated as soon as someone changes > the content. > > > Which goes back to my original question. If you need to check the AMS > anyway, what additional purpose does the AS serve? > It's an interesting question. I imagine it's similar in nature to the fact that the crypto part of a DKIM-Signature will still pass for a message with a modified body; you have to then check that "bh=" matches the current content before you can truly assert that the signature is valid. > I disagree. If I can cause your MTA to crash because of oversized header > fields, that's at least a denial of service attack. If I can cause your > filter to crash because of oversized header fields and your MTA fails open, > I can bypass whatever protections the filter offers. > > > In that case, I'm fine if this is expressed in terms of a security threat. > But any ARC-specific nature to this threat is a marginal case; an attacker > could do the same in most cases by just adding lots of garbage header > fields. > True, but I think the nature of the beast here is that this is a non-garbage addition to the email infrastructure that will certainly bloat headers, and participants (and maybe even non-participants) need to be able to deal with it. OK, it's possible that this has been done. But the important question is, > does this draft need to wait for 7602bis to be published? > This draft, as I recall, is trying to register some things into the authentication method registries that the prose of 7601 didn't allow. So, yes. I had thought that we planned to do them as a cluster anyway, and that 7601bis was ready for WGLC ahead of this one, but I've forgotten where we are with it now. -MSK --000000000000f8b0640570b2cacd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 10, 2018 at 1:24 PM, Jim Fenton <fenton@= bluepopcorn.net> wrote:
=20 =20 =20
On 7/10/18 12:43 PM, Murray S. Kucherawy wrote:

AMS is basically the same as DKIM-Signature, and so it covers body modifications.=C2=A0 When you verify the seal, yo= u must also verify the latest AMS, which in turn means the seal is invalidated as soon as someone changes the content.

 Which goes back to my original question. If you need to check the AMS anyway, what additional purpose does the AS serve?
=

It's an interesting question.=C2= =A0 I imagine it's similar in nature to the fact that the crypto part o= f a DKIM-Signature will still pass for a message with a modified body; you = have to then check that "bh=3D" matches the current content befor= e you can truly assert that the signature is valid.
=
I disagree.=C2=A0 If I can cause your MTA to cra= sh because of oversized header fields, that's at least a denial of service attack.=C2=A0 If I can cause your filter to crash because of oversized header fields and your MTA fails open, I can bypass whatever protections the filter offers.

In that case, I'm fine if this is expressed in terms of a security threat. But any ARC-specific nature to this threat is a marginal case; an attacker could do the same in most cases by just adding lots of garbage header fields.
=
True, but I think the nature of the beast here is that this = is a non-garbage addition to the email infrastructure that will certainly b= loat headers, and participants (and maybe even non-participants) need to be= able to deal with it.

<= div text=3D"#000000" bgcolor=3D"#FFFFFF"> OK, it's possible that this has been done. But the important question is, does this draft need to wait for 7602bis to be published?

This draft, as I recal= l, is trying to register some things into the authentication method registr= ies that the prose of 7601 didn't allow.=C2=A0 So, yes.=C2=A0 I had tho= ught that we planned to do them as a cluster anyway, and that 7601bis was r= eady for WGLC ahead of this one, but I've forgotten where we are with i= t now.

-MSK
=C2=A0
= --000000000000f8b0640570b2cacd-- From nobody Wed Jul 11 04:42:05 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A72130EF7 for ; Wed, 11 Jul 2018 04:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hj1dkAv2ZIYn for ; Wed, 11 Jul 2018 04:42:01 -0700 (PDT) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B41F130DDE for ; Wed, 11 Jul 2018 04:42:01 -0700 (PDT) Received: by mail-ed1-x532.google.com with SMTP id x5-v6so15308474edr.0 for ; Wed, 11 Jul 2018 04:42:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=SNclGBzq4K/oqnUEZ3PXbjyQzSSRE3k+sD9dNSR320Q=; b=AM09yjsvoidzELMWy5S2wGT5ka+K3ebDkKP6pthmePcWyep+emwN9hQ8PI+UF0iWWU sJe2Cf7pyXzSr3ZCvfI6M7hTm+nXH9gwHPZ/T8v2tFARGohznUWr8TtOeZcaFaG2lC1n fdXom5FezVduYRPkxNjEhisxLzRf63b2VxYSE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=SNclGBzq4K/oqnUEZ3PXbjyQzSSRE3k+sD9dNSR320Q=; b=sJkAIVL1HeodmtIIzu4kmUK/PwFnYPh7eWtDg++VACBnPwvxSMfBULmT7PkcAwuAC0 L11KKxMNu5AsyfAnsUTIytETQ6YtnBNkJ3HUHQQ3Pi48wD0nY3iA3811xL1hkG+9OfuI b90lW8cCggjmS7miHHhABHliN45chQVUz//txNkIClqfWAeNrmQ6fUE3rPYZsFkj9Nnd 9pKR9yk8NLYmTUifPMRXcWd9xEFr6LR2j3YW/aNKYo6jbthYVZNLvULShubTvhbMvn5f DGr/0cAadRmE70Km5aDCJ4TIHXH6dFvhd64veZFAsDhufKzRIUHS2sjLm+pCfcQLbncT 6JiA== X-Gm-Message-State: APt69E1GR7e08rr2I0YID7k9xn7kDAj3elupxBWfqUJiqXMoc6ji5pSK 6c08RjSU19Ap+/p8xxY+yEh+0UH4bmUwTMUiJGghrg== X-Google-Smtp-Source: AAOMgpcBpUgQboFJ28SOrGAznCl1PTrWBNisG76w0sZEwh9ju8e5+GiKtTKBWWcZXvhaEz/oIiSxbrKc+Kc1Zg+5y+Y= X-Received: by 2002:a50:a3ce:: with SMTP id t14-v6mr31090360edb.227.1531309319719; Wed, 11 Jul 2018 04:41:59 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 2002:aa7:da87:0:0:0:0:0 with HTTP; Wed, 11 Jul 2018 04:41:58 -0700 (PDT) In-Reply-To: References: <96be85f9-dd0e-4259-47f4-2e7c425c404c@bluepopcorn.net> <968bd954-34a8-05ed-ceec-d4274107a773@bluepopcorn.net> From: "Kurt Andersen (b)" Date: Wed, 11 Jul 2018 04:41:58 -0700 X-Google-Sender-Auth: YS3UiKZJ9vjdLcD2Hh3IVEBVt_A Message-ID: To: "Murray S. Kucherawy" Cc: Jim Fenton , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000000b16e40570b7bc52" Archived-At: Subject: Re: [dmarc-ietf] ARC protocol-15 posted X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 11:42:04 -0000 --0000000000000b16e40570b7bc52 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 10, 2018 at 10:48 PM, Murray S. Kucherawy wrote: > On Tue, Jul 10, 2018 at 1:24 PM, Jim Fenton > wrote: > >> On 7/10/18 12:43 PM, Murray S. Kucherawy wrote: >> >> >> AMS is basically the same as DKIM-Signature, and so it covers body >> modifications. When you verify the seal, you must also verify the latest >> AMS, which in turn means the seal is invalidated as soon as someone changes >> the content. >> >> >> Which goes back to my original question. If you need to check the AMS >> anyway, what additional purpose does the AS serve? >> > > It's an interesting question. I imagine it's similar in nature to the > fact that the crypto part of a DKIM-Signature will still pass for a message > with a modified body; you have to then check that "bh=" matches the current > content before you can truly assert that the signature is valid. > 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 long as someone doesn't tamper with the chain (consisting of the triplet ARC header fields). That allows intermediaries to change the content and then attest to their changes within the scope of a still valid chain. AMS (at least the most recent one) tells you about the general headers (covered by the signature) and the body. AS is used to string the chain together and avoid having modifications break the chain. --Kurt --0000000000000b16e40570b7bc52 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 10, 2018 at 10:48 PM, Murray S. Kucherawy <superuser@gmail.com> wrote:
On Tue, Jul 10, 2018 at 1:24 PM, Jim Fenton <fenton@blu= epopcorn.net> wrote:
=20 =20 =20
On 7/10/18 12:43 PM, Murray S. Kucherawy wrote:

AMS is basically the same as DKIM-Signature, and so it covers body modifications.=C2=A0 When you verify the seal, yo= u must also verify the latest AMS, which in turn means the seal is invalidated as soon as someone changes the content.

 Which goes back to my original question. If you need to check the AMS anyway, what additional purpose does the AS serve?
=

It's an interesting quest= ion.=C2=A0 I imagine it's similar in nature to the fact that the crypto= part of a DKIM-Signature will still pass for a message with a modified bod= y; you have to then check that "bh=3D" matches the current conten= t before you can truly assert that the signature is valid.

I think that there is a bit of a di= fference here and terminology is not being used precisely. The "seal&q= uot; (AS) is not invalidated when someone changes the content.=C2=A0 The &q= uot;signature" (AMS) is. The "seal" (aka AS) remains valid a= s long as someone doesn't tamper with the chain (consisting of the trip= let ARC header fields). That allows intermediaries to change the content an= d then attest to their changes within the scope of a still valid chain.

AMS (at least the most recent one) tells you about th= e general headers (covered by the signature) and the body. AS is used to st= ring the chain together and avoid having modifications break the chain.

--Kurt

--0000000000000b16e40570b7bc52-- From nobody Wed Jul 11 08:20:13 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85DD6130DFC for ; Wed, 11 Jul 2018 08:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dmarcanalyzer.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rowTiSWnIopk for ; Wed, 11 Jul 2018 08:20:01 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7A0812F18C for ; Wed, 11 Jul 2018 08:20:01 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id l25-v6so23946491ioh.12 for ; Wed, 11 Jul 2018 08:20:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dmarcanalyzer.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Rgm91MbZEMeDX8wZL/k1AQ9ZI0wI0rRbsf2/Y0ev3T4=; b=CcJJPQsO10s4y3QvwjLOz87Q970xKVAOaDI8VnkUzRQv5HUIL9eX4YDStkNRKbENTn hXD62CB7tTOZxx2q2GVKp8uxaGUxy7ZDgy9qPTwt6mev+17YsIPF8KVzCPScjNS6znep BXVMYGQyHagIniMJQ2J69j9aywxYHNLU30rDk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=Rgm91MbZEMeDX8wZL/k1AQ9ZI0wI0rRbsf2/Y0ev3T4=; b=sqYp4jf8MRcvrm+XCga1I0KJCtuZe7e4y8yHnUcv4ny8X6oN4yIId1tnqKt8KyxaF0 YXulR5pYeyp/JjUI9Yp5/ye3uIu+nlE1EpZQ9B2kSVS/YBtN6G64+yIk22lHhtLHj4+2 0m/U/gWzs3vL7WaI8SuyCsYvdekJQPel5X3gY/ETLAtF9XA63Hg3Z0WzM4w620OhbgJm b/iLkosRIO0ZQbH3J9CZVg/EeVsqHT+PxAIrejw6TTyJ+mQiQ6Uh4w6zEVmcv/8png+L dQ2nfuNfjLzpehoCOpf9OubfxkSc29aTcZLQdvEmhlOMwxANSaP1+VL2jxPXx9bdF7lI NAtw== X-Gm-Message-State: APt69E11j/nheJ2g2Vg+43CO7zLcNTz+LSzvwAJNeKIzQzlBrduxstrI hEKDCeCbKOYrYTE1kgLPi49xUKih7UrK4UdvThuZwYPHe+4= X-Google-Smtp-Source: AAOMgpf1rEEMwcWqHMz/b3TSw3aEh+xLIwQb46hv+gGya/Ed4iUa2js4t4aZHn0M92uYGVsHE5Em5XhNilh83/tDTEw= X-Received: by 2002:a6b:ed0:: with SMTP id 199-v6mr25436837ioo.69.1531322400336; Wed, 11 Jul 2018 08:20:00 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:3057:0:0:0:0:0 with HTTP; Wed, 11 Jul 2018 08:19:19 -0700 (PDT) In-Reply-To: <02a23bd0-bada-8b67-7cac-7698df4af4fe@wizmail.org> References: <02a23bd0-bada-8b67-7cac-7698df4af4fe@wizmail.org> From: Martijn van der Lee Date: Wed, 11 Jul 2018 17:19:19 +0200 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="000000000000b57f810570bac720" Archived-At: Subject: Re: [dmarc-ietf] ARC protocol-15 posted X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 15:20:10 -0000 --000000000000b57f810570bac720 Content-Type: text/plain; charset="UTF-8" Hi all, In 5.1.1. (Header Fields To Include In ARC-Seal Signatures) he text states to include the ARC Set currently being added. However, the signature cannot include the current ARC-Seal header, as it's full contents are not yet known at the time (for obvious reasons). Should the current ARC-Seal be excluded from the hash or should some part of it be included? I'm assuming the former, but regardless I can find no text to make this explicit. Is such text missing or am I simply overlooking it? -- Best regards, Martijn van der Lee Software developer DMARC Analyzer - Trusted. Email. Delivered. Stationsplein 12 | 1211 EX | Hilversum | The Netherlands www.dmarcanalyzer.com | +31 (0) 85 13 00 788 We are accredited on security and privacy by the DDMA Privacy Authority. --000000000000b57f810570bac720 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

In 5.1.1. (Header Fields T= o Include In ARC-Seal Signatures) he text states to include the ARC Set cur= rently being added.
However, the signature cannot include the cur= rent ARC-Seal header, as it's full contents are not yet known at the ti= me (for obvious reasons).
Should the current ARC-Seal be excluded= from the hash or should some part of it be included?
I'm ass= uming the former, but regardless I can find no text to make this explicit.<= /div>
Is such text missing or am I simply overlooking it?
--=C2=A0
Best regards,

Martijn van der Lee
Softw= are developer



DMARC Analyzer - Trusted. Email= . Delivered.

Stationsplein 12 | 1211 EX | Hilversum |=C2=A0The Net= herlands
www.dmarcanalyzer.com=C2=A0|=C2=A0+31 (0)= 85 13 00 788

=C2=A0=C2= =A0=C2=A0
We are accredited on security and privacy by the DDMA Privacy Authority.<= /span>
--000000000000b57f810570bac720-- From nobody Wed Jul 11 08:29:24 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1703130DFD for ; Wed, 11 Jul 2018 08:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WR15nSaroDD for ; Wed, 11 Jul 2018 08:29:21 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00693130DE5 for ; Wed, 11 Jul 2018 08:29:20 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id j8-v6so21625583lfb.4 for ; Wed, 11 Jul 2018 08:29:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dymqULi6/FaFJHkK7MJ39xkrfY8WysKKqLt1SmaS/8s=; b=LglYJ9BWb97pBKizt1JDChIGk5UNjGeHcg1HzFsZSTvhHU0iIP+QUyXfDy9fc7We/5 1FDJCZYk0nZKJEu6QrKD2yd3e4x25UKcfCk6Mhan29/eSjX2H5fy4xKjymqT/WxdOfQV fdsiSIs298oYJ9dccLfaKh312OuhLkxgpoJs63SQeAKl1szMuC1z0nAzUso4kvxqXG7M RDY7HsC3QLvlLRefPmMh/irez5fPoXK6UhQ1J44Th9nK9eSJmZlNICcILz68mh31iJHS UH9q0JI8iRi+z/UeeWkSOu/8jI1YJ/zypf/gGntn+bEoQ4aIFAbNFVsydoxvHX0H6DYK CiJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dymqULi6/FaFJHkK7MJ39xkrfY8WysKKqLt1SmaS/8s=; b=Gc0wiqH56dQaKV9tLrkStjVEI+4JIwUMM0oPwUEzgk6lheBO8yE0BWLJfv15jh+osJ CnXhNiK3L2pW23jb0E265ZyZAmfRkhx47Mt5cs6ncReG0kD5k07qcYkPgizT0UaXlAj9 tg/W4DBMUrCnsgk+/f98TA+LpS6RJKHtqdXXVLstfJaGQNihYx0OB45DqgYd1oBi8n2B 7DUVIHT/sBsuWc3p2q6uGITwR24vGFGCY/P97/ATd6IUGOssdr3QknaBYchG+DXtHvus yFou7kqcGn0Q6Ji6vgwDjLwNP4ZgJRV0DZIN8cgB5vqIgVlkuV9FMSmJQIP827BLmD8a tPXA== X-Gm-Message-State: APt69E2hcVMxQpguY0r3lNREULjI+H2XxEPI5VfG59L+5xzDk+mU1a2P /mWVRU5Iam0u1zn5nSSP8TFwVKhANBBZ97FlEcI= X-Google-Smtp-Source: AAOMgpdQwYeFesPtpHYREgpGifRbG2YHbaKxK3JTkqsUH32coTMpAOsc5U4Hz3SJfFp0XcczM2uUmMtSWhYmBkvMDnw= X-Received: by 2002:a19:eb1b:: with SMTP id j27-v6mr6575516lfh.0.1531322959083; Wed, 11 Jul 2018 08:29:19 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:3a13:0:0:0:0:0 with HTTP; Wed, 11 Jul 2018 08:29:18 -0700 (PDT) In-Reply-To: References: <02a23bd0-bada-8b67-7cac-7698df4af4fe@wizmail.org> From: "Murray S. Kucherawy" Date: Wed, 11 Jul 2018 08:29:18 -0700 Message-ID: To: Martijn van der Lee Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="000000000000033d830570bae977" Archived-At: Subject: Re: [dmarc-ietf] ARC protocol-15 posted X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 15:29:23 -0000 --000000000000033d830570bae977 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 11, 2018 at 8:19 AM, Martijn van der Lee < martijn=40dmarcanalyzer.com@dmarc.ietf.org> wrote: > In 5.1.1. (Header Fields To Include In ARC-Seal Signatures) he text states > to include the ARC Set currently being added. > However, the signature cannot include the current ARC-Seal header, as it's > full contents are not yet known at the time (for obvious reasons). > Should the current ARC-Seal be excluded from the hash or should some part > of it be included? > I'm assuming the former, but regardless I can find no text to make this > explicit. > Is such text missing or am I simply overlooking it? > If there's a question here, then there's probably room for improvement in the text. The way I read this and implemented it, the AMS and AAR are fully generated before the AS is, so you have the entire ARC Set except for the "b=" part of the AS available, and that's what gets fed to the hash function. It's the same way DKIM works, really. -MSK --000000000000033d830570bae977 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 11, 2018 at 8:19 AM, Martijn van der Lee <martijn=3D40dmarcanalyzer.com@dmarc.ietf.org>= ; wrote:
In 5.1.1. (Header Fields To I= nclude In ARC-Seal Signatures) he text states to include the ARC Set curren= tly being added.
However, the signature cannot include the current= ARC-Seal header, as it's full contents are not yet known at the time (= for obvious reasons).
Should the current ARC-Seal be excluded fro= m the hash or should some part of it be included?
I'm assumin= g the former, but regardless I can find no text to make this explicit.
Is such text missing or am I simply overlooking it?
=

If there's a question here, then there= 's probably room for improvement in the text.

= The way I read this and implemented it, the AMS and AAR are fully generated= before the AS is, so you have the entire ARC Set except for the "b=3D= " part of the AS available, and that's what gets fed to the hash f= unction.=C2=A0 It's the same way DKIM works, really.

=
-MSK
--000000000000033d830570bae977-- From nobody Wed Jul 11 10:12:25 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE683130E58 for ; Wed, 11 Jul 2018 10:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jayAS_c4WIG for ; Wed, 11 Jul 2018 10:12:21 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6856126CC7 for ; Wed, 11 Jul 2018 10:12:21 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id i12-v6so50634687oik.2 for ; Wed, 11 Jul 2018 10:12:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=yI+t1Ua6WdLc4WrV/F2ymdjGJclO2HOL5LG+oXFXCec=; b=tuBAs9XXM/C3Nz3nSV/QjLTN8nFZPts7LMu2oEnqbLsa8JqohmMUVZDhUzHatGQz2u 4swRWYZhUy/y/Nzwh4lvvyDffvXpNBX8IuUS1+VeyFP4xEi8PDfj6PCcCdZRbnx8B0YM xEkMtTv/Fu6hTELd95b06r+YM8kStRBAUqXbdER1IaDxtgetbi3t2BPl7CwyO6ddtqK8 sWHH7g5ea6Y9nVB1Ee1uQZkD1qf4HDJjad3IlAcJ4Kf//AsP9K5KCRj0ff5SpDLQ3HQs tMv5UtDOiA3vNVNNdzIAXHyunR+ttRYtvU0PWOpqv6XoPeM/QugiD8MkMGedjgD+XAin /O+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=yI+t1Ua6WdLc4WrV/F2ymdjGJclO2HOL5LG+oXFXCec=; b=nIsEhv0p7pD8qpBu+mbB1KhnSITV8+mW1B2Hhd8zAP89tI3RO3RJZ1+uDnjMiVsH9L 2d3T0+/MmkA0K1i+3ZCGBIXfVhLFWfUnfD0tAC2GlO1rIbWvhcEDFfWXqg8Ta8GPj7wS fL60fexXHfrQvBvButfvYev8m1SyZvR6HtIS/HB2siU8dQycxyfqcXsytr0WOeT3CtTx Z9ie4myF+pnGBlrvw3V7nnQ6eZseHpMTRKPqXehNZemPohauJ0UZL7Qup0jEMJ1I+HYF n0zn6PVfeIvhfNTYeWAmtELkngTAtolNsR5ziWUaTambDdF8pojyEaRJ6ddriFZtxjG4 DqRA== X-Gm-Message-State: AOUpUlEHBzVlXwGY39xmsMhiRgSCWCmOxO8Q+pEbwJYuNgaX1i8+oYUc xWHNA4aVXI8M9vIJJcikiVvxvTRV9QKn2Y25fhRTPpvQ2EA= X-Google-Smtp-Source: AAOMgpe5nm0kqoCqz1vhC6A3xqWZnSNrt1JtAmHG/WdL88ry9q9+txotq/aIcAv4wejG4FU6tkln1DyYjyC10xygXZs= X-Received: by 2002:aca:d088:: with SMTP id j8-v6mr153061oiy.276.1531329140568; Wed, 11 Jul 2018 10:12:20 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:2646:0:0:0:0:0 with HTTP; Wed, 11 Jul 2018 10:11:59 -0700 (PDT) In-Reply-To: References: <02a23bd0-bada-8b67-7cac-7698df4af4fe@wizmail.org> From: Seth Blank Date: Wed, 11 Jul 2018 10:11:59 -0700 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="0000000000007556880570bc596f" Archived-At: Subject: Re: [dmarc-ietf] ARC protocol-15 posted X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 17:12:24 -0000 --0000000000007556880570bc596f Content-Type: text/plain; charset="UTF-8" On Wed, Jul 11, 2018 at 8:29 AM, Murray S. Kucherawy wrote: > On Wed, Jul 11, 2018 at 8:19 AM, Martijn van der Lee < > martijn=40dmarcanalyzer.com@dmarc.ietf.org > > wrote: > >> In 5.1.1. (Header Fields To Include In ARC-Seal Signatures) he text >> states to include the ARC Set currently being added. >> However, the signature cannot include the current ARC-Seal header, as >> it's full contents are not yet known at the time (for obvious reasons). >> Should the current ARC-Seal be excluded from the hash or should some part >> of it be included? >> I'm assuming the former, but regardless I can find no text to make this >> explicit. >> Is such text missing or am I simply overlooking it? >> > > If there's a question here, then there's probably room for improvement in > the text. > > The way I read this and implemented it, the AMS and AAR are fully > generated before the AS is, so you have the entire ARC Set except for the > "b=" part of the AS available, and that's what gets fed to the hash > function. It's the same way DKIM works, really. > Yes, this is the intention. 5.1.1 specifically refers to 6376 section 3.7 which explains this behavior. This was done as a reference so that if DKIM's mechanism changed, ARC would inherit it. For the working group: is this still unclear, and perhaps some non-normative text required in order to avoid confusion but not cause drift between ARC and DKIM? --0000000000007556880570bc596f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 11, 2018 at 8:29 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:
On Wed, Jul 11, 2018 at 8:19 AM, Mart= ijn van der Lee <martijn=3D40dmarcanalyzer.com= @dmarc.ietf.org> wrote:
In 5.1.1. (Header Fields To = Include In ARC-Seal Signatures) he text states to include the ARC Set curre= ntly being added.
However, the signature cannot include the curren= t ARC-Seal header, as it's full contents are not yet known at the time = (for obvious reasons).
Should the current ARC-Seal be excluded fr= om the hash or should some part of it be included?
I'm assumi= ng the former, but regardless I can find no text to make this explicit.
Is such text missing or am I simply overlooking it?

If there's a question here, th= en there's probably room for improvement in the text.

The way I read this and implemented it, the AMS and AAR are fully g= enerated before the AS is, so you have the entire ARC Set except for the &q= uot;b=3D" part of the AS available, and that's what gets fed to th= e hash function.=C2=A0 It's the same way DKIM works, really.

Yes, this is the intention.= =C2=A05.1.1 specifically refers to 6376 section 3.7 which explains this beh= avior. This was done as a reference so that if DKIM's mechanism changed= , ARC would inherit it.

For the working group: is = this still unclear, and perhaps some non-normative text required in order t= o avoid confusion but not cause drift between ARC and DKIM?
--0000000000007556880570bc596f-- From nobody Wed Jul 11 10:12:48 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA19130E69 for ; Wed, 11 Jul 2018 10:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EdZuhR7ny2zh for ; Wed, 11 Jul 2018 10:12:43 -0700 (PDT) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82D0B130E40 for ; Wed, 11 Jul 2018 10:12:43 -0700 (PDT) Received: by mail-ed1-x531.google.com with SMTP id d3-v6so19759322edi.1 for ; Wed, 11 Jul 2018 10:12:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=pET0PzQnCIKuehyYrbYxhif33XkeumPN8kQR4tL5FCU=; b=btPwvFixvrY6SfxkNxcYa5Io7/Z+eSTXKVRgC+5iDvDsfk/+ctd9YnhhAZj8ktJd8L dx8rYb3RHNTB4BTjbv3PsxEOaiaIMt34FbAFi2ThJ6+XkSsOsOaB6p8sydIwUnXlotRz VJD7lXfJlZCAqvvOVKfxjpxlTZAKRbI0e1IbY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=pET0PzQnCIKuehyYrbYxhif33XkeumPN8kQR4tL5FCU=; b=HmvULUgFnZwNIFBHIF1NyLrQC0eM0FJyF08Er5I27hlh6f8UbfMuYM5Hw8jHPSKoHN /qpi8GT3UFs37hq2q5jOKiqwkNMVZzQpg0wq/99yB5jLCVR2mhbaPrVzLzrFIsJZgKx2 a20JRXf8AxpaEVu0JBNxXn5ATC3NPn4a2/frvYyoPpDPjkWOX4nMmq4CK1E27FJEsxYE Lx5xJMO8Ocr8vP2TjFj7s8JN8E9jfCGcS/RiWcyFHjwsBHqRGKFJTHRp+/VQ8XUUEV3B xwudMp5qgxJsE8WZP8OiT1/hOQM/B12VPhyvaC9Ed9YGnY+P6kL3BZngcQSYlAzv3PXd nsig== X-Gm-Message-State: AOUpUlGaAQVtSNTHzXcGk3+4I8L5ktcZGu1b/xFyJzfNcLCTBzYr2xQl lg3XJ7cqG5jIvy7+G01WgGGNhIWc54TJeymC8D8b9Q== X-Google-Smtp-Source: AAOMgpegFS7b29rPbCDKylF0aITzrIzuzXt15Pt8QV7u78rMdcGN8PUxs8Uaaex4bBRUw9vGnaemI5k4lgoLizgRqbQ= X-Received: by 2002:aa7:d993:: with SMTP id u19-v6mr17738236eds.125.1531329162010; Wed, 11 Jul 2018 10:12:42 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 2002:aa7:da87:0:0:0:0:0 with HTTP; Wed, 11 Jul 2018 10:12:41 -0700 (PDT) In-Reply-To: References: <02a23bd0-bada-8b67-7cac-7698df4af4fe@wizmail.org> From: "Kurt Andersen (b)" Date: Wed, 11 Jul 2018 10:12:41 -0700 X-Google-Sender-Auth: lYho8A49znpX4SBWa5SDeJC1cVw Message-ID: To: "Murray S. Kucherawy" Cc: Martijn van der Lee , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000bc759c0570bc5a20" Archived-At: Subject: Re: [dmarc-ietf] ARC protocol-15 posted X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 17:12:46 -0000 --000000000000bc759c0570bc5a20 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 11, 2018 at 8:29 AM, Murray S. Kucherawy wrote: > On Wed, Jul 11, 2018 at 8:19 AM, Martijn van der Lee < > martijn=40dmarcanalyzer.com@dmarc.ietf.org > > wrote: > >> In 5.1.1. (Header Fields To Include In ARC-Seal Signatures) he text >> states to include the ARC Set currently being added. >> However, the signature cannot include the current ARC-Seal header, as >> it's full contents are not yet known at the time (for obvious reasons). >> Should the current ARC-Seal be excluded from the hash or should some part >> of it be included? >> I'm assuming the former, but regardless I can find no text to make this >> explicit. >> Is such text missing or am I simply overlooking it? >> > > If there's a question here, then there's probably room for improvement in > the text. > > The way I read this and implemented it, the AMS and AAR are fully > generated before the AS is, so you have the entire ARC Set except for the > "b=" part of the AS available, and that's what gets fed to the hash > function. It's the same way DKIM works, really. > That is correct. The whole ARC set with a blank "b=" value is hashed. --Kurt --000000000000bc759c0570bc5a20 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 11, 2018 at 8:29 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:
On Wed, Jul 11, 2018 at 8:19 AM, Martijn van der Lee <martijn=3D40dmarcanalyzer.com@dmarc.ietf.org&= gt; wrote:
In = 5.1.1. (Header Fields To Include In ARC-Seal Signatures) he text states to = include the ARC Set currently being added.
However, the signature = cannot include the current ARC-Seal header, as it's full contents are n= ot yet known at the time (for obvious reasons).
Should the curren= t ARC-Seal be excluded from the hash or should some part of it be included?=
I'm assuming the former, but regardless I can find no text t= o make this explicit.
Is such text missing or am I simply overloo= king it?

If there&= #39;s a question here, then there's probably room for improvement in th= e text.

The way I read this and implemented it, th= e AMS and AAR are fully generated before the AS is, so you have the entire = ARC Set except for the "b=3D" part of the AS available, and that&= #39;s what gets fed to the hash function.=C2=A0 It's the same way DKIM = works, really.
=

That is correct. = The whole ARC set with a blank "b=3D" value is hashed.
=
--Kurt=C2=A0

--000000000000bc759c0570bc5a20-- From nobody Wed Jul 11 10:29:18 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0686130DF2 for ; Wed, 11 Jul 2018 10:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIl1il7DsdIz for ; Wed, 11 Jul 2018 10:29:11 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E113130E40 for ; Wed, 11 Jul 2018 10:29:11 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id v8-v6so50720293oie.5 for ; Wed, 11 Jul 2018 10:29:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Ztrmf+bWknm51yIMB86Uf5V0N3Jyb9DaZwyLxsoKdIE=; b=xsctxAKISMbU8htQFNEqCPUN3igETTvhbD9rm0+jA2iaiLSCITeorLmAFv97OtCgkf XCSFuuspBXXkilH+6VP+pNAco+ZxtaA2Bgyou8MHFOnKENYd7MSRG1lVKptDUOfefGTQ iG1QbaEALI1tjEdquf1O4JTFdwKInwq8haVLwpc7ZElOXmoo4lsmYldx64MTe7XbdcXG GD8mwKNamAqC5xlNhDdosFxPj1plu1OCeQo7XHoHRmLBLpwmsxIMnqpF9fLmP5RyuYge /BdmHyt0OWBCo1B1Y7GSvg4PnzVQKxiTeufpI5wVvInSALdG0vN1dUSGxeIjg1uqdOi1 SRyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=Ztrmf+bWknm51yIMB86Uf5V0N3Jyb9DaZwyLxsoKdIE=; b=VPayYz+aPv0nRVVXw969H8fdSme8AnlyI+RRbkXh2fnf6h3Au5bjbiqCt5B2MbeDji OO5knABCXnFVbQAgptZn1qScKlJHfEk0su0OTYDncdE1+Dn+GVOKELBI9eKIAagJfApx e+vRsOfjsiGI8Uig/e9sauZ5Kyl+5Yfi+LJ1F3L9QNODU84w36wiR5kJ0hixYtRAN5qZ 4rDZnp+wl/sUH1+qglwWFCNtlO23rNSfsdkX64JAPdeR3jRkoKR5zD0JPb5aCyqPm6FR hFhLkw908yUEx+x/LYYFYzxIkcNbUfQZYVNJktiI+TmNoDP/SXnsRG8vsmsJ4vQsKwt/ ZHhg== X-Gm-Message-State: AOUpUlFHZnbbR3C+81X8Uz1ers9hFBu0RkYoOwVeHd7NKI+uiDLdARsL VV/uiUCRvBucsvDZqxDCHpitfLt9taI2MTLDp7fwGpIP3Sk= X-Google-Smtp-Source: AAOMgpfKkiZoN5il+MPNg2tBd+0FC4IrpmWwW8Pap3JaWL1wcgpKl37deDJbGjBLtGkoWNkiFIiAZ4+NcGbfp4RpMhM= X-Received: by 2002:aca:cd8f:: with SMTP id d137-v6mr219152oig.350.1531330150175; Wed, 11 Jul 2018 10:29:10 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:2646:0:0:0:0:0 with HTTP; Wed, 11 Jul 2018 10:28:49 -0700 (PDT) In-Reply-To: References: <96be85f9-dd0e-4259-47f4-2e7c425c404c@bluepopcorn.net> <968bd954-34a8-05ed-ceec-d4274107a773@bluepopcorn.net> From: Seth Blank Date: Wed, 11 Jul 2018 10:28:49 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a2b7cb0570bc9578" Archived-At: Subject: Re: [dmarc-ietf] ARC protocol-15 posted X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 17:29:17 -0000 --000000000000a2b7cb0570bc9578 Content-Type: text/plain; charset="UTF-8" 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 long as someone doesn't tamper with the chain (consisting of the > triplet ARC header fields). That allows intermediaries to change the > content and then attest to their changes within the scope of a still valid > chain. > > AMS (at least the most recent one) tells you about the general headers > (covered by the signature) and the body. AS is used to string the chain > together and avoid having modifications break the chain. > Yes, and to go one step further, there are basically three scenarios that make the differences and value clear: 1) The latest AMS validates and all the AS's validate ==> You have an intact and valid ARC chain and can use it to influence a local policy decision if needed 2) The latest AMS does not validate but all the AS's validate ==> You have an intact ARC chain, which you can use to localize the problem in the chain (either an entity that doesn't sign, or does so improperly, or between which hops a malicious actor inserted themselves, especially if you have the oldest_hop value from intermediaries) 3) Some of the AS's don't validate ==> The chain has been tampered with and you can't trust any information from it Especially in a world where not everyone is using ARC, scenario 2 above lets us as an industry identify actors who need to properly deploy ARC, and gives us further insight into attacks we might not otherwise see. But to circle back to Jim's original question about the value of the ARC Seal, this has also been discussed at length in this working group, and has probably been one of the largest technical points of contention: i.e. how much value does it really add, for whom, and is it truly needed? Warning, here be demons: https://mailarchive.ietf.org/arch/msg/dmarc/4Gu1EErK4iuo9pQnZ-uJ2tKpMDQ I believe where working group discussion ended up was that there were strong arguments on either side, and no consensus was in sight, but there was strong agreement that data from the experiment would clearly show if the ARC Seal added any value beyond just the AMS, so it was left in with a strong call out as an issue that needs resolution in section 11.3.1. --000000000000a2b7cb0570bc9578 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 11, 2018 at 4:41 AM, Kurt Andersen (b) <kboth@drkurt.com> wrote:
I think that there is a bit of a difference here and termi= nology is not being used precisely. The "seal" (AS) is not invali= dated when someone changes the content.=C2=A0 The "signature" (AM= S) is. The "seal" (aka AS) remains valid as long as someone doesn= 't tamper with the chain (consisting of the triplet ARC header fields).= That allows intermediaries to change the content and then attest to their = changes within the scope of a still valid chain.

<= /div>
AMS (at least the most recent one) tells you about the general he= aders (covered by the signature) and the body. AS is used to string the cha= in together and avoid having modifications break the chain.

Yes, and to go one step further, t= here are basically three scenarios that make the differences and value clea= r:

1) The latest AMS validates and all the AS'= s validate

=3D=3D> You have an intact and valid= ARC chain and can use it to influence a local policy decision if needed

2) The latest AMS does not validate but all the AS&#= 39;s validate

=3D=3D> You have an intact ARC ch= ain, which you can use to localize the problem in the chain (either an enti= ty that doesn't sign, or does so improperly, or between which hops a ma= licious actor inserted themselves, especially if you have the oldest_hop va= lue from intermediaries)

3) Some of the AS's d= on't validate

=3D=3D> The chain has been ta= mpered with and you can't trust any information from it

<= /div>
Especially in a world where not everyone is using ARC, scenario 2= above lets us as an industry identify actors who need to properly deploy A= RC, and gives us further insight into attacks we might not otherwise see.


But to circle back to Jim's orig= inal question about the value of the ARC Seal, this has also been discussed= at length in this working group, and has probably been one of the largest = technical points of contention: i.e. how much value does it really add, for= whom, and is it truly needed? Warning, here be demons:=C2=A0https= ://mailarchive.ietf.org/arch/msg/dmarc/4Gu1EErK4iuo9pQnZ-uJ2tKpMDQ

I believe where working group discussion ended up was = that there were strong arguments on either side, and no consensus was in si= ght, but there was strong agreement that data from the experiment would cle= arly show if the ARC Seal added any value beyond just the AMS, so it was le= ft in with a strong call out as an issue that needs resolution in section 1= 1.3.1.=C2=A0

--000000000000a2b7cb0570bc9578-- From nobody Wed Jul 11 11:34:28 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9530130EA0 for ; Wed, 11 Jul 2018 11:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WD4Vd0E5gaT9 for ; Wed, 11 Jul 2018 11:34:25 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F34BC130F58 for ; Wed, 11 Jul 2018 11:34:24 -0700 (PDT) Received: from steel.local (sfosf0017s350801.wiline.com [64.71.6.2] (may be forged)) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id w6BIYMeG030253 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 11 Jul 2018 11:34:23 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1531334063; bh=cagihf7lzUJ4t6j3J7TEdMqlulHB/w6NEH5vdaUzBQQ=; h=Subject:To:References:From:Date:In-Reply-To; b=uPGf7xNeSoQj8QraC0ZBGxqBYZJk7kfhWU6ITiw8t8VB3lnfk59b7/nZFOD3ltSOK 3DGFXGWHMKdLlRGIz/fchaDbgVgSBJ1rMraNHNMjXoiJqoZJYILCY+Qg8U8tuUncT8 q5/fja03pN9KBsMyix4KiMHEYV3krLojcmbTls+k= To: dmarc@ietf.org References: <96be85f9-dd0e-4259-47f4-2e7c425c404c@bluepopcorn.net> <968bd954-34a8-05ed-ceec-d4274107a773@bluepopcorn.net> From: Jim Fenton Message-ID: <57e9072d-40c5-3a68-28c5-e065810347e6@bluepopcorn.net> Date: Wed, 11 Jul 2018 11:34:17 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C5B3212B9D31B4A879E2171C" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC protocol-15 posted X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 18:34:27 -0000 This is a multi-part message in MIME format. --------------C5B3212B9D31B4A879E2171C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 7/11/18 10:28 AM, Seth Blank wrote: > > But to circle back to Jim's original question about the value of the > ARC Seal, this has also been discussed at length in this working > group, and has probably been one of the largest technical points of > contention: i.e. how much value does it really add, for whom, and is > it truly needed? Warning, here be demons: > https://mailarchive.ietf.org/arch/msg/dmarc/4Gu1EErK4iuo9pQnZ-uJ2tKpMDQ > Thanks for the pointer to the 'demons'; lots there for me to absorb. I'll try to do that before burdening the list further on this topic. If anyone wants to discuss any of this informally in Montreal, I'll be there all week. I guess the WG timeslot has been given to 'extra', and this is more than would fit in a 1-hour timeslot anyway. -Jim --------------C5B3212B9D31B4A879E2171C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 7/11/18 10:28 AM, Seth Blank wrote:

But to circle back to Jim's original question about the value of the ARC Seal, this has also been discussed at length in this working group, and has probably been one of the largest technical points of contention: i.e. how much value does it really add, for whom, and is it truly needed? Warning, here be demons: https://mailarchive.ietf.org/arch/msg/dmarc/4Gu1EErK4iuo9pQnZ-uJ2tKpMDQ

Thanks for the pointer to the 'demons'; lots there for me to absorb. I'll try to do that before burdening the list further on this topic.

If anyone wants to discuss any of this informally in Montreal, I'll be there all week. I guess the WG timeslot has been given to 'extra', and this is more than would fit in a 1-hour timeslot anyway.

-Jim

--------------C5B3212B9D31B4A879E2171C-- From nobody Wed Jul 11 15:09:09 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09BFD130ED9 for ; Wed, 11 Jul 2018 15:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNmHcWsQsCU8 for ; Wed, 11 Jul 2018 15:09:05 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DDB6130E35 for ; Wed, 11 Jul 2018 15:09:05 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id a134-v6so22508093lfe.6 for ; Wed, 11 Jul 2018 15:09:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=7CiTuu0iYXopDVGTsfDCTaYDo0arI8PpuxOJLqhIoTs=; b=VckfdznZ/1TrBvoDbtwveXfxl6/uhYuz+JybqfwMkzaKlIyn1aLFFSfz6xOzfBN2uF NKtMZnb7/vbPeAHHivT45MfXDHQc4Kcyrv3eHfuBvM/kMkyIWXw/a4vBstcbTHiDidwf Ypff+iUFs/BQSkZQddRM4DeH+zKQKxCwVBlGR3y0uX3KjOc61dJWqPslJtuCIBviNedL XyQnFKhFpNIul7zky88fYcZ+NPPwzaMNofNEtdGCwsTjd7kx9RMqu6ZpRnELi0XUN0vL FpSG4xP0mgwbuDOsdPTxAmKIx8XxfBBIiIch9XhORuN2NkYXZnULOpfSjftwlaZhsaqm p+Yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=7CiTuu0iYXopDVGTsfDCTaYDo0arI8PpuxOJLqhIoTs=; b=jX+3cErtD7ubKKwx1ah2QAwSD6XQxrjCiCczZsrsU9Z5fTbJHJIXFpzk9E789UFTzT 9lWeATSEKt5qaZGV0M2ag8c1PoM8ERzTFlojtdLVbvNGSQhYRpDTbLjcFB/jp3qPctrv ziX3REmR4geUJsocO6xaTeFeOsS420t4gdCFU7OFnz+O2FeslwR6MSgPJiTD2JGE/CDm BMdNZ3wOoDEk08lhdkazI1it+PoQSDPptkEZ8p0ZXIRMt4/V4VGEWdoqv4/sH1BKJHUn u+eDlcBEwew0olbQ8nxTXnhBValgANI8ECt6KVtGZUbwY7HGcE1ugj7oVU6ZJ5j92Q4y 6Zdg== X-Gm-Message-State: AOUpUlFyxISYRgWgb7pfPd0v3uKhAyg4XYasOhKQGtZSwcAWn8OKpb6F 6LtzOdi/TAaD3+WTt7PTrAIQd2JHL6wFEq1Y/nWV3Q== X-Google-Smtp-Source: AAOMgpfeD4oUz+cSvlA9OHilqj8FybezGnwK5W89KXs8dO/M3wrj9njuUII76p0JtTjdeSuJiP4Km5mc2d1dVFOwfiE= X-Received: by 2002:a19:c742:: with SMTP id x63-v6mr232966lff.9.1531346942986; Wed, 11 Jul 2018 15:09:02 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:2b10:0:0:0:0:0 with HTTP; Wed, 11 Jul 2018 15:09:01 -0700 (PDT) From: "Murray S. Kucherawy" Date: Wed, 11 Jul 2018 15:09:01 -0700 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="000000000000908f930570c07e47" Archived-At: Subject: [dmarc-ietf] Any outstanding issues on 7601bis? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 22:09:08 -0000 --000000000000908f930570c07e47 Content-Type: text/plain; charset="UTF-8" ...or can we WGLC it? -MSK --000000000000908f930570c07e47 Content-Type: text/html; charset="UTF-8"
...or can we WGLC it?

-MSK
--000000000000908f930570c07e47-- From nobody Wed Jul 11 15:11:33 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC898130E73 for ; Wed, 11 Jul 2018 15:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h_lppczs9wVO for ; Wed, 11 Jul 2018 15:11:28 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA9D2130E35 for ; Wed, 11 Jul 2018 15:11:28 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id b15-v6so22494029qtp.11 for ; Wed, 11 Jul 2018 15:11:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Cr4VQqJh9Q/bpiuwBCh17pS8McEAwlhYm7R8ajQKTbI=; b=UCwxTEsyaW10cp4LzWN2mbjdJirFLu3/f+aCYqyTB41f5YO3XDkXSFqNcyBnZ8/pPq w/izXwqMAuBH6B8xiwjbS14csQET03rCnpYeAZqeiOtgVebpfdxHbrJ+nM0Ja0EEwNg8 YPwa9izc2oeFO5c2EP8LUoRXX5awcK6leSHeN8FPttVl+do1xUoEr+g1RYN2TUpgSlH7 YNY6wJd2njDTd/Qg2M7d+dhIttXHbcTfNeeQTW+vwuLnleUBRLoSfd69UMD888f7NtA9 kwkOdmfKsmn/iL8Wqx90WtK76SbSfGtg6zX+fY39tVw8i+fJLkKIA/23KJWmFlZcuPgY Ohww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Cr4VQqJh9Q/bpiuwBCh17pS8McEAwlhYm7R8ajQKTbI=; b=eoK1WC8dQW1TVx3i6NCE1u9bO8ERqIVBKXAxz/Gjs2PmANByAtucEOEpcKjso6QQS1 DxOulb6iMr1TYAVBZOY6I7FzB8bLNOw247wliwYmatRBKWwExTXNQPqzyI+BX0o685p5 zapbzQtTIVSoK1cne7Mj0Jo6xKpb5tC57FtqIKwKr/PPqNFEa1Jm0wgmVR6oyawHEdWP /sPiCizDyKm0kLJ2e+mUdPAj7TJci4HAm4SPEezAhUqFE4BXFxk0S+mpfv/9w5VxMbX5 z0cV0E69VZOTFC4sNWby6OwFJIeh62+NTiXjW0JjU4l4PBppoc6fG2a4lwuhPLVcgL+w iBmg== X-Gm-Message-State: AOUpUlG6XVCPyPYmF3JlJeFcwNA/t6741yKC85cq9gXlG8heaSEW8GPH N2XuZIrAhuUxNwFr1TU6WYEvDtWqd6FPwjcHJGml1g== X-Google-Smtp-Source: AAOMgpd46AKlMuEm5KueqmYun9zjO5KsZ0Y+yyD26jjBdBIyKf9bCWxLV7j2xZS0KgAzJkIDubSmc3NwfIq90tqhZsc= X-Received: by 2002:a0c:d4a9:: with SMTP id u38-v6mr533390qvh.112.1531347087792; Wed, 11 Jul 2018 15:11:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Seth Blank Date: Wed, 11 Jul 2018 15:11:17 -0700 Message-ID: To: "Murray S. Kucherawy" Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="000000000000322b220570c087f4" Archived-At: Subject: Re: [dmarc-ietf] Any outstanding issues on 7601bis? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 22:11:31 -0000 --000000000000322b220570c087f4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Nope. Earlier comments of mine have been addressed. I think it=E2=80=99s re= ady for WGLC. On Wed, Jul 11, 2018 at 15:09 Murray S. Kucherawy wrote: > ...or can we WGLC it? > > -MSK > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --=20 Seth Blank | Director of Industry Initiatives E: seth@valimail.com | P: 415.273.8818 --000000000000322b220570c087f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Nope. Earlier comments of mine have been addressed. = I think it=E2=80=99s ready for WGLC.

On Wed, Jul 11, 2018 at 15:09 Murray S. Kucherawy= <superuser@gmail.com> wro= te:
...or can= we WGLC it?

-MSK
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--
<= div>

= Seth Blank | Director of Industry Initiatives

E: seth@valimail= .com | P: 415.273.8818

--000000000000322b220570c087f4-- From nobody Wed Jul 11 15:15:05 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7B1A130E35 for ; Wed, 11 Jul 2018 15:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7--sYMzcgESx for ; Wed, 11 Jul 2018 15:15:01 -0700 (PDT) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93D69130DE1 for ; Wed, 11 Jul 2018 15:15:01 -0700 (PDT) Received: by mail-ed1-x52d.google.com with SMTP id i20-v6so7304249eds.12 for ; Wed, 11 Jul 2018 15:15:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iger+M/P4IcEsG9tRg41XYiS7qPHE3ChqXPMCGVLsCk=; b=EGQNfMnRg2Qn7+t0MBQr2BqQHODg2MN2lLwGiShlV52DAYEeNhaiTdtlgUNhtuvWx4 Nqt6WDqWTrbWdTfZQxg7YMAF/t/BetTLRTPkCa6ozUlLlb6xlZh9fCuKCfE+gPmLmek5 H+t/r1XTpuy8pBsPVKxWH6vONuw+6nU8GhuN8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iger+M/P4IcEsG9tRg41XYiS7qPHE3ChqXPMCGVLsCk=; b=DzX8blcgIMrGC0cCiHU1t6yqNVF+RCsHkWR9vvqMdB7zXvhii21vYl6//O10O7+coG ahh1kf0oExvh8tSWDwToq3HITxLzeLwt573ChXwCFglkOS2LYmXDDoQ1RSFYSHdAzRqk YI3ap/BI9H/ejByyZbCPMLG8Wa0o7qHU5Fq/IkU6fXGqzpDuxRGXC33lFPDW7TQWCYF8 ulgr/MDQHlvCTAp51RolXYZTtAmcMNqNn02bO/RM8/ka65viwbSm94VO0JJH5vuaTbwB GnU+8i3h9U5X2kA0Wq3hegefxJwGpLA2OPYdWnSvtCnukFeWJSA7110dNWt095Du+HIW 8O5w== X-Gm-Message-State: AOUpUlEO58FSxM10wN7Dvi6Us+DgOkyABLbNRLILpIrFcDuR1N9/CmpT Aqsw3/6bWk5vq3Y0L2YTjLXThcGXdk+H1z8lUx8DpmPhVdI= X-Google-Smtp-Source: AAOMgpfj2nNfh4DkjiFW37Yp39G3/cN4X5oJ/HY3/B+HTg6tbvNNjJsDlt8LFdgCfO6yD8TObfxu+MdOv/0+XCeCsc8= X-Received: by 2002:aa7:d993:: with SMTP id u19-v6mr332700eds.125.1531347300081; Wed, 11 Jul 2018 15:15:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kurt Andersen Date: Wed, 11 Jul 2018 18:14:48 -0400 Message-ID: To: Seth Blank Cc: "Murray S. Kucherawy" , dmarc@ietf.org Content-Type: multipart/alternative; boundary="000000000000d9726b0570c093e1" Archived-At: Subject: Re: [dmarc-ietf] Any outstanding issues on 7601bis? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 22:15:04 -0000 --000000000000d9726b0570c093e1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 On Wed, Jul 11, 2018, 18:11 Seth Blank wrote: > Nope. Earlier comments of mine have been addressed. I think it=E2=80=99s = ready for > WGLC. > > On Wed, Jul 11, 2018 at 15:09 Murray S. Kucherawy > wrote: > >> ...or can we WGLC it? >> >> -MSK >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > -- > > Seth Blank | Director of Industry Initiatives > > E: seth@valimail..com | P: 415.273.8818 > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000d9726b0570c093e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1

O= n Wed, Jul 11, 2018, 18:11 Seth Blank <seth=3D40valimail.com@dmarc.ietf.org> wrote:
Nope. Earlier comme= nts of mine have been addressed. I think it=E2=80=99s ready for WGLC.
=

On Wed, Jul 11, = 2018 at 15:09 Murray S. Kucherawy <superuser@gmail.com> wrote:
...or can we W= GLC it?

-MSK
_______________________________________________
dmarc mailing list
dmar= c@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--
_______________________________________________
dmarc mailing list
dmar= c@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000d9726b0570c093e1-- From nobody Wed Jul 11 15:24:05 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB62C12872C for ; Wed, 11 Jul 2018 15:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=zU6yY7HI; dkim=pass (2048-bit key) header.d=kitterman.com header.b=jE34pIMu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHrqJNVqwjZ1 for ; Wed, 11 Jul 2018 15:24:01 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B51BA130DE1 for ; Wed, 11 Jul 2018 15:24:01 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1531347838; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=y96J+EQr8gwGvDQZyWTvwFOi1N1MkY6td4+eOJZs5w4=; b=zU6yY7HI5VgBadWrcLC9lEoX+15/KQHQNz+sag4XlzPtgx/+jaDqoXpz Exp6/7TvNezSOp4qnwMl4ELTbQZGDQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1531347838; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=y96J+EQr8gwGvDQZyWTvwFOi1N1MkY6td4+eOJZs5w4=; b=jE34pIMuQmXH7rdlVL0PLW/IVfOCmBM1rhapmEIBEj++5HwWZzWoTyd1 guAsM+YjL4Sgq1AclOo3r6pEE3tY+UPyB6M55lOlhArzpISJqe2kD0gq6S HWIPjG/Bg+udk/aDhzp9s1OTOK/1d1t8B3iK0iOF4HnTiZbwmFfsQ3q3eX lE1rvRgCmvF5d3AnWnUR52OoY+IFruM0yGukU409LpZol4MmifHgmgXVpe 1kQRzrsNKnVKkxVRELQ/srpzM2A4fpIU7d0lsKZzNDZT+oTjeL8M6kgC/x v2MY1BymNpg0Mv17Ef9a5hFXmlqdMgMiOmWLQTpmaKFKMyz1SsE6NQ== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 355A4C4026B for ; Wed, 11 Jul 2018 17:23:58 -0500 (CDT) From: Scott Kitterman To: dmarc@ietf.org Date: Wed, 11 Jul 2018 18:23:57 -0400 Message-ID: <2940516.WEBi8fTYBz@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-147-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Any outstanding issues on 7601bis? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 22:24:04 -0000 On Wednesday, July 11, 2018 03:09:01 PM Murray S. Kucherawy wrote: > ....or can we WGLC it? > > -MSK Not that it needs to be fixed before WGLC, but should Sender ID be listed as historic now? Is the list of EAI affected components of the field complete? As an example, sometimes email addresses are used for SMTP Auth user IDs (or sometimes just the local part). I don't know a lot about EAI, but it seems to me that most any field might have to contain UTF-8 now? I guess that's more of a WGLC type comment than anything, so I think it's good to go. Scott K From nobody Wed Jul 11 17:15:22 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D217130E86 for ; Wed, 11 Jul 2018 17:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gr38aFcIyWUP for ; Wed, 11 Jul 2018 17:15:19 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93D3F12426A for ; Wed, 11 Jul 2018 17:15:19 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id q19-v6so26196483ioh.11 for ; Wed, 11 Jul 2018 17:15:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=u5wVObJ1BzafiV+7oCmGbR4gAiRUFAWDR9GMlsnTFpc=; b=OijXz8QPImCJOk1/spH3i0evDijyYfROgnB3I4R3v0f7nrAb4MZHeGsuYOPIOKhazz Y7hbCecNhCK6xHlKC4/8Kk3bH8/NV1v4PcyhMf9LRnaJ9iDbk+EAd3cr+Q1HzNnRWpZ7 UHkQo8eNcTtCyIinGJ+5fJYJmHtjXcnJWcd/DaQLMJ9QqciqkE5qog/6RattuLWqkoNB jWtbHFRf06yaMdAaRvk6sL8uv50bEjMLDtAeHwE3TvXvL8gAU/q5KvQ5NKz7bUX9zL9t hVt30cqAIONBpmATT4C5rPC4k4Vl+n5esD2NTZW1Yv7ulZrG5V6G/RO1eAEDKu4dKu4A kwyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=u5wVObJ1BzafiV+7oCmGbR4gAiRUFAWDR9GMlsnTFpc=; b=I7bYaCud98lGm6N97NEzG4h1Jd9IJquzSCDwHCWT/9PWWCjNKWKUyLnkl5IEPMjFjP VgHCLwENzdViUGir2lDqQ9hsFD+84Lr/nM9AgucVblSBepmCsxOiUFaDaoPucwgB0Qwn RexNsW+o4KL8qLdUj4ahiSnzaJuCgoqR4L3sTffTs7CrFkmogmG08FSKA43glKHuwx/3 y54LDJYQ8N9YsuM6Rp3kxXyiVwYUYGCoGNAq2hPS+Tw2jQzHIoaagKUcBfGgGx+eJtI4 NubmGiALhbHr/P4A2rZcgID0058AcyNYZfAX7Bl0iUeRpxyKy0dylJCtCnvq+fqrlKRS XQXg== X-Gm-Message-State: AOUpUlG0y6s1hkNA6aGibp5u75ce5WpwuGClR8y8tghmwHUgxTno0Ja6 gBRw31u0BUBmQusqg/FJMSyssLcFkxvozwRXwANW X-Google-Smtp-Source: AAOMgpfwHanUGI3babUY5bDdUdwgzFbuRan+3WfjOg4annl14ZWyocrpeutmzLau6Lzg3m+Xgftii5vmI1ekk8BJYko= X-Received: by 2002:a6b:1504:: with SMTP id 4-v6mr870593iov.405.1531354518532; Wed, 11 Jul 2018 17:15:18 -0700 (PDT) MIME-Version: 1.0 References: <96be85f9-dd0e-4259-47f4-2e7c425c404c@bluepopcorn.net> <968bd954-34a8-05ed-ceec-d4274107a773@bluepopcorn.net> In-Reply-To: From: Brandon Long Date: Wed, 11 Jul 2018 17:15:06 -0700 Message-ID: To: Jim Fenton Cc: "Murray S. Kucherawy" , dmarc@ietf.org, "Kurt Andersen (b)" Content-Type: multipart/alternative; boundary="0000000000001ae5840570c24222" Archived-At: Subject: Re: [dmarc-ietf] ARC protocol-15 posted X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 00:15:21 -0000 --0000000000001ae5840570c24222 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 10, 2018 at 1:24 PM Jim Fenton wrote: > On 7/10/18 12:43 PM, Murray S. Kucherawy wrote: > > RFC7601 doesn't require or encourage deletion of A-R fields in general. > (The strongest word is "could".) If it's valid and possibly useful > downstream, you can certainly keep it. It only says you have to delete > stuff that's clearly a forgery. > > > I didn't go back and check the wording used in 7601 obviously. I was > inferring from the language in 4.1.2, "are likely to be deleted". > Right, basically an ADMD right now has to delete any existing A-R field that claims to be the ADMD in order to prevent forgery. If you added it to the signature and added an instance variable, you don't need to do that anymore, but you may still run afoul of other software that is deleting them. DKIM-Signatures are also sometimes removed from messages (mailing lists often do this), and there are also MTAs which incorrectly make assumptions about how DKIM-Signature failure means (the RFC says a failed DKIM-Signature should be treated as if it's not there, but that's not what we're seeing in practice). Earlier instances of the AMS are expected to fail if the message content is changed and for that to be fine. We did spend a bunch of time, maybe before it even came to the IETF, exploring whether we could do this without having a separate set of header fields, and we decided no. Brandon --0000000000001ae5840570c24222 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=20 =20 =20
On 7/10/18 12:43 PM, Murray S. Kucherawy wrote:
=20
RFC7601 doesn't require or encourage deletion of A-R fields in general.=C2=A0 (The strongest word is "could&quo= t;.)=C2=A0 If it's valid and possibly useful downstream, you can certainly keep it.=C2=A0 It only says you have to delete stuff that's cle= arly a forgery.

I didn't go back and check the wording used in 7601 obviously. I wa= s inferring from the language in 4.1.2, "are likely to be deleted&qu= ot;.

Right, basically an ADMD rig= ht now has to delete any existing A-R field that claims to be the ADMD in o= rder to prevent forgery.=C2=A0 If you added it to the signature and added a= n instance variable, you don't need to do that anymore, but you may sti= ll run afoul of other software that is deleting them.

<= div>DKIM-Signatures are also sometimes removed from messages (mailing lists= often do this), and there are also MTAs which incorrectly make assumptions= about how DKIM-Signature failure means (the RFC says a failed DKIM-Signatu= re should be treated as if it's not there, but that's not what we&#= 39;re seeing in practice).=C2=A0 Earlier instances of the AMS are expected = to fail if the message content is changed and for that to be fine.

We did spend a bunch of time, maybe before it even came to= the IETF, exploring whether we could do this without having a separate set= of header fields, and we decided no.

Brandon
--0000000000001ae5840570c24222-- From nobody Wed Jul 11 17:20:45 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5090130F0B for ; Wed, 11 Jul 2018 17:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=zqrq8uao; dkim=pass (1536-bit key) header.d=taugh.com header.b=aS0jvAPy Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtPVFuTEg4Xj for ; Wed, 11 Jul 2018 17:20:41 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 977A6130EAE for ; Wed, 11 Jul 2018 17:20:41 -0700 (PDT) Received: (qmail 38130 invoked from network); 12 Jul 2018 00:20:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=94f0.5b469ed8.k1807; bh=j+RlTg8/KF2lTdapdK6VwMXvPYcUwTN8/m6Q2fGpAKM=; b=zqrq8uaoBBDXagctFfleHBXPSnpxFxwDN4VkR1w/C7BUVPQxc5GTt+73S48JcllnedwgICKofbbaIHFtVIZFOY+SwAoP/JwYzn/SXnyFHgTeCk61fIEbydN7sD42gwF+4CaTeMBaYi/Mjl92Ye+Ausx1/6fM4RwExtyJhHaWnEjm/Oh6vjWT0mgeX7JV0ABR4VTeeL3cIeFj0PCHUDvzj3Aw+xjtqaZh79D52h08JvTWFY/a48GACP+GWdonudQe DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=94f0.5b469ed8.k1807; bh=j+RlTg8/KF2lTdapdK6VwMXvPYcUwTN8/m6Q2fGpAKM=; b=aS0jvAPy8KU36KM9rD5Piu1jU/tsqbz4BNosPHzHWyZBzYCyinW+EaYx7CNv/XDIJXAtXsUE+qI9Qvk/uFJAYRLQ1r8kzcQYb0W1Hm4Mgz9rtvEtLn0nIGvzapaPg4r+kfAOV7333+gjMpCuEq9dmt+5F0AXPUeLyjzqZJYOoJPrb91cKltG/XF3cyoFLpLwt9/vof/YvIAGjkWs2QwLvnzCIm+0nTrg3Q/LPzIYxUP6+drrrsc3XrtIUqvBuAXI Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 12 Jul 2018 00:20:40 -0000 Received: by ary.qy (Postfix, from userid 501) id DD05520020EA83; Wed, 11 Jul 2018 20:20:39 -0400 (EDT) Date: 11 Jul 2018 20:20:39 -0400 Message-Id: <20180712002039.DD05520020EA83@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: sklist@kitterman.com In-Reply-To: <2940516.WEBi8fTYBz@kitterma-e6430> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Any outstanding issues on 7601bis? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 00:20:44 -0000 In article <2940516.WEBi8fTYBz@kitterma-e6430> you write: >Is the list of EAI affected components of the field complete? As an example, >sometimes email addresses are used for SMTP Auth user IDs (or sometimes just >the local part). I don't know a lot about EAI, but it seems to me that most >any field might have to contain UTF-8 now? Any field that is a domain name or an e-mail address can be UTF-8 in an EAI message. From nobody Wed Jul 11 17:38:33 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F218130F94 for ; Wed, 11 Jul 2018 17:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfSxpRw2YfNo for ; Wed, 11 Jul 2018 17:38:29 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84A5C130DDC for ; Wed, 11 Jul 2018 17:38:29 -0700 (PDT) Received: from steel.local ([IPv6:2601:647:5500:1330:dd50:9f6d:3988:b691]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id w6C0cM9P015539 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 11 Jul 2018 17:38:23 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1531355903; bh=THbTB+Ai+2e5xJz/xSdzIT6pjkTGL8T2NthwxM8pHOM=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=ZaGif1zHaQUzq2tgOYBAdG5EPft30NX5nVE1wfUSnnAxXyDsa/m6Vhzt8TSXM/IKG ZK6olU4LsmTk9HNzgP3enCU40E0CfAXbqW+5C3BaDfPkeKtV+ykWBQeLco7P2huAHE NokzVaFemwH05nMVUulZbIrcp4Y849FLpIHT/1iA= To: Brandon Long Cc: "Murray S. Kucherawy" , dmarc@ietf.org, "Kurt Andersen (b)" References: <96be85f9-dd0e-4259-47f4-2e7c425c404c@bluepopcorn.net> <968bd954-34a8-05ed-ceec-d4274107a773@bluepopcorn.net> From: Jim Fenton Message-ID: Date: Wed, 11 Jul 2018 17:38:16 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------EC4F24D3CD7571D25657229E" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC protocol-15 posted X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 00:38:32 -0000 This is a multi-part message in MIME format. --------------EC4F24D3CD7571D25657229E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 7/11/18 5:15 PM, Brandon Long wrote: > DKIM-Signatures are also sometimes removed from messages (mailing > lists often do this), and there are also MTAs which incorrectly make > assumptions about how DKIM-Signature failure means (the RFC says a > failed DKIM-Signature should be treated as if it's not there, but > that's not what we're seeing in practice).  Earlier instances of the > AMS are expected to fail if the message content is changed and for > that to be fine. > > We did spend a bunch of time, maybe before it even came to the IETF, > exploring whether we could do this without having a separate set of > header fields, and we decided no. So essentially we're creating a bunch of header bloat (creating duplicate header fields with different names where that could be avoided) because there are some MTAs that did not follow the specifications before. That makes me unhappy, but what matters here is not the behavior of all MTAs, it's the behavior of MTAs implementing ARC (that include instance number tag/value). If there's an MTA in the middle that deletes DKIM-Signature, it's not implementing ARC and the chain is broken. Small reminiscence (feel free to ignore this): Back when we were merging DomainKeys and IIM to create DKIM, one of the design decisions was whether to publish the public key in DNS (ala DomainKeys) or to include it in the signature header field and put a fingerprint in DNS (ala IIM). The decision was made when a large mail service provider calculated how much more storage they would have to buy in the latter case (because of the larger header field). While that was ~14 years ago and storage is cheaper now, we're talking about a lot more space than just a public key. -Jim --------------EC4F24D3CD7571D25657229E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 7/11/18 5:15 PM, Brandon Long wrote:
DKIM-Signatures are also sometimes removed from messages (mailing lists often do this), and there are also MTAs which incorrectly make assumptions about how DKIM-Signature failure means (the RFC says a failed DKIM-Signature should be treated as if it's not there, but that's not what we're seeing in practice).  Earlier instances of the AMS are expected to fail if the message content is changed and for that to be fine.

We did spend a bunch of time, maybe before it even came to the IETF, exploring whether we could do this without having a separate set of header fields, and we decided no.

So essentially we're creating a bunch of header bloat (creating duplicate header fields with different names where that could be avoided) because there are some MTAs that did not follow the specifications before. That makes me unhappy, but what matters here is not the behavior of all MTAs, it's the behavior of MTAs implementing ARC (that include instance number tag/value). If there's an MTA in the middle that deletes DKIM-Signature, it's not implementing ARC and the chain is broken.

Small reminiscence (feel free to ignore this): Back when we were merging DomainKeys and IIM to create DKIM, one of the design decisions was whether to publish the public key in DNS (ala DomainKeys) or to include it in the signature header field and put a fingerprint in DNS (ala IIM). The decision was made when a large mail service provider calculated how much more storage they would have to buy in the latter case (because of the larger header field). While that was ~14 years ago and storage is cheaper now, we're talking about a lot more space than just a public key.

-Jim

--------------EC4F24D3CD7571D25657229E-- From nobody Wed Jul 11 18:23:53 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D47130DC7 for ; Wed, 11 Jul 2018 18:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VY52rg2nRsGs for ; Wed, 11 Jul 2018 18:23:50 -0700 (PDT) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01C4C12F1A2 for ; Wed, 11 Jul 2018 18:23:49 -0700 (PDT) Received: by mail-ed1-x531.google.com with SMTP id x5-v6so16898659edr.0 for ; Wed, 11 Jul 2018 18:23:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=TFXIpxANA55EUsK5+XiK4dtle2mCu3cHqZLPfWJ0gQM=; b=TsBZWRe5hbsj5gXPDYPUmaSgZIE8u3THrrd3L1JBYfzwWnvi8AvMVbo+iIZ+vY8Osf kQs2ggx+JyfdMdkyBE7a9a88V4QjtTtNFz9oRcj5C4TMytZocyQjFqgCF/Aw5LynFDPH SoYe3tx2RNjf8crZU0WXfpBHdEeEPWEdFQIZY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=TFXIpxANA55EUsK5+XiK4dtle2mCu3cHqZLPfWJ0gQM=; b=WOl98/GjsoInMwzydUy62clIEEz0PF5i26h/SNDj/SDzPdMgPwLxEmmiB2U/2eA/iK q8btRzegfrqhfg6Z2PW+sVRdCE/ISdiHIOvjt/XIfeeGG6bZUpxrPldsjjckJnAFa/Xp 8rol689/yeNs5ldggJSshClmChY1wPlUveu6CK7HlIuvS0A6k9JSh3FYa9oRzBaYE5BN NgmOIPwQ12FyQ3IjzVFKukiJF4fj4+kFO3Di+pzMiTbHsYyE0PkyJO4xe5RoDa2aKDbq YLZ+FS+SOo+qHjnm7ltZcs3151LPTsWg1qSDDD563qNempfGYWTImIHJuOf8UlXbgiG1 1Q/A== X-Gm-Message-State: AOUpUlHLze2Gj4Y9qgvekgFhUp60Y0UdWWW9Nvjmc1xmD7KTOURwS2d/ +GJYrZNW1XiRSyWmn1Zz93dT2PGBfI+t3reI0Oi9BQ== X-Google-Smtp-Source: AAOMgpeQB9CkQWnV1an90KCH00ls/OX4ZJygn2wsTZEyXJ74tKJaf4V00DeBtHck0g8HAjRlvlJWiMLERCkZ74V5h1g= X-Received: by 2002:a50:c251:: with SMTP id t17-v6mr206192edf.108.1531358628427; Wed, 11 Jul 2018 18:23:48 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 2002:aa7:da87:0:0:0:0:0 with HTTP; Wed, 11 Jul 2018 18:23:47 -0700 (PDT) In-Reply-To: References: <96be85f9-dd0e-4259-47f4-2e7c425c404c@bluepopcorn.net> <968bd954-34a8-05ed-ceec-d4274107a773@bluepopcorn.net> From: "Kurt Andersen (b)" Date: Wed, 11 Jul 2018 18:23:47 -0700 X-Google-Sender-Auth: 5NTBsQFhMzxOtlaiKTWTwKW7JN8 Message-ID: To: Jim Fenton Cc: Brandon Long , "Murray S. Kucherawy" , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000124ac70570c3378a" Archived-At: Subject: Re: [dmarc-ietf] ARC protocol-15 posted X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 01:23:52 -0000 --000000000000124ac70570c3378a Content-Type: text/plain; charset="UTF-8" On Wed, Jul 11, 2018 at 5:38 PM, Jim Fenton wrote: > > So essentially we're creating a bunch of header bloat (creating duplicate > header fields with different names where that could be avoided) because > there are some MTAs that did not follow the specifications before. That > makes me unhappy, but what matters here is not the behavior of all MTAs, > it's the behavior of MTAs implementing ARC (that include instance number > tag/value). If there's an MTA in the middle that deletes DKIM-Signature, > it's not implementing ARC and the chain is broken. > The DMARC WG is explicitly *not* scoped to make normative changes to any other specifications so changing DKIM (for example) is not an available option. Deleting or otherwise breaking one or more of the DKIM-Signatures on a message has nothing to do with ARC per se. It's even possible that an ARC-implementing ADMD could do such a thing. --Kurt --000000000000124ac70570c3378a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 11, 2018 at 5:38 PM, Jim Fenton <fenton@bluepopcorn.net&g= t; wrote:
=20 =20 =20

So essentially we're creating a bunch of header bloat (creating duplicate header fields with different names where that could be avoided) because there are some MTAs that did not follow the specifications before. That makes me unhappy, but what matters here is not the behavior of all MTAs, it's the behavior of MTAs implementing ARC (that include instance number tag/value). If there's an MTA in the middle that deletes DKIM-Signature, it's = not implementing ARC and the chain is broken.

The DMARC WG is explicitly *not* scoped to make normative changes = to any other specifications so changing DKIM (for example) is not an availa= ble option. Deleting or otherwise breaking one or more of the DKIM-Signatur= es on a message has nothing to do with ARC per se. It's even possible t= hat an ARC-implementing ADMD could do such a thing.

--Kurt=C2=A0

--000000000000124ac70570c3378a-- From nobody Wed Jul 11 18:39:28 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 060AC130DC8 for ; Wed, 11 Jul 2018 18:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=vJZqPF47; dkim=pass (1536-bit key) header.d=taugh.com header.b=lI+Mq1pB Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpdr8E90VkOX for ; Wed, 11 Jul 2018 18:39:22 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAB2712F1A2 for ; Wed, 11 Jul 2018 18:39:21 -0700 (PDT) Received: (qmail 67955 invoked from network); 12 Jul 2018 01:39:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1096d.5b46b147.k1807; bh=FAGy/KXhLOI6U/xmIv+9ZlS2n+lDP1g+e5NaBLiU4V8=; b=vJZqPF47VqN7SMN13GKtoyoyu8lUYMAdVska0xvjq2ucO2ScaSG/TDFHVqaFn0tmWWJ4Z/9muJVPtwf1+QcnFRYy8dfNAmLjzwRmfsZLbPrggFEB5BCVjEq6i4T+tH7auD97YCLSPcZS1ogvZkWjHsSluHSOSymHHa+fVrD8aasnli4yySyNGKOw/E3avvL34ZqAGejoTVvMDCV7pabNtsLCGljX4EYsfag7HkKMLf4OAs2OfG1ndaPe4dahneyp DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1096d.5b46b147.k1807; bh=FAGy/KXhLOI6U/xmIv+9ZlS2n+lDP1g+e5NaBLiU4V8=; b=lI+Mq1pB6FFsgzeJ+qkxQ+NmJWmwhE8hQBZx9WentyoaWdpNhs41UijbTCDhZbk2xxUHSR6ZVl2cPSlK8Y5zVuKgxqM5OQboIpfpPIm1qtVujiAio81X7TyE1NJ1D3ATOaoYxVRDgDLKrEWYms+o1Xrsh9YvudkLyBPSK74S/B3ZdZRwCya84z5Ojbo0VejK0ROVs7jWS84266RBLjLvwdBKWMXIfSu8VTQLxVdU2XbASbLcgpXx3WHK/KhaDC/v Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 12 Jul 2018 01:39:19 -0000 Received: by ary.qy (Postfix, from userid 501) id 1E61120020F35F; Wed, 11 Jul 2018 21:39:18 -0400 (EDT) Date: 11 Jul 2018 21:39:18 -0400 Message-Id: <20180712013919.1E61120020F35F@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: fenton@bluepopcorn.net In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] ARC protocol-15 posted X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 01:39:26 -0000 In article you write: >-=-=-=-=-=- > >On 7/11/18 5:15 PM, Brandon Long wrote: >So essentially we're creating a bunch of header bloat (creating >duplicate header fields with different names where that could be >avoided) because there are some MTAs that did not follow the >specifications before. Not really. Removing A-R headers and DKIM signatures that you know you've broken is perfectly legit. >While that was ~14 years ago and storage is >cheaper now, we're talking about a lot more space than just a public key. The header bloat war was over years ago, and bloat won. See the headers below from a Hotmail message I just sent to myself. And remember that most messages have two copies of the contents, one as text and one as overformatted HTML. R's, John Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-oln040092254069.outbound.protection.outlook.com [40.92.254.69]) by mail1.iecc.com ([64.57.183.56]) with ESMTPS (TLS1.2/X.509/SHA384) via TCP port 4832/25 id 593422434; 12 Jul 2018 01:33:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yheKLMok/AWsFgQSOudb3SeVpVLTechgX2xwJg55q1I=; b=fSMMmynOZ/yvG4APRjHNPV6dEp5BL4cqFrWDuhwGP1TrOFjBAKfK90feS2C0m8fYLSCpxLT5kVicGIRKU4/m8mnkhAddsiYJyH1YndV++hcuWdYczcC+J4BTOjyGoI6nHG0huyk4JNCdDbUDkOrBJVtnzBuUV7bul1/HiRpByRmwjJEblpDmwL39unVb5BsraL4LI4tFpVg7SoSN8JknQkQhEehEy4y/KKrjf0BWfTevXijH/SUIuhfTtvivBNYk3nttmGb/UzZnppsg0K60B1Spzkt5a+MDVfb0WcxOW96pbW+JZBDUQL2DJzYEeMO2XwU0KzvI2VeTo+FFbsaJfg== Received: from PU1APC01FT054.eop-APC01.prod.protection.outlook.com (10.152.252.53) by PU1APC01HT025.eop-APC01.prod.protection.outlook.com (10.152.253.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.952.17; Thu, 12 Jul 2018 01:33:40 +0000 Received: from MA1PR01MB0504.INDPRD01.PROD.OUTLOOK.COM (10.152.252.58) by PU1APC01FT054.mail.protection.outlook.com (10.152.253.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.952.17 via Frontend Transport; Thu, 12 Jul 2018 01:33:40 +0000 Received: from MA1PR01MB0504.INDPRD01.PROD.OUTLOOK.COM ([fe80::80d8:30b7:8b9:76b8]) by MA1PR01MB0504.INDPRD01.PROD.OUTLOOK.COM ([fe80::80d8:30b7:8b9:76b8%6]) with mapi id 15.20.0952.017; Thu, 12 Jul 2018 01:33:40 +0000 From: John Levine To: "johnl@taugh.com" Subject: foonly Thread-Topic: foonly Thread-Index: AQHUGYBbeUQDz4tOwk+dGC+Hc9JmZA== Date: Thu, 12 Jul 2018 01:33:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:A7C19D09C7AEA4F3F77D7470D7304AD8D473C0A6D230F3D30521AB146ABFE106;UpperCasedChecksum:396480D49DF29DCCCFBA5A280F6FA9AC7D936435C538895B009E6EE3C82D4242;SizeAsReceived:6935;Count:44 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [EXz7oC/i7RDIxsz0et96krw+RIvK/ZpBSSdECXooGiWEUcOlu9MA/OlkbCP8PsXYKWXUaXqoDgk=] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;PU1APC01HT025;7:MrJzcL3Ttgoo5VtNuOX58QnjyQ9+Dos0iMozs6RfU6mvKY6vaW/B9Ta309AzLchfmM/OI+ejlE8BZ63HPBTs1d7sj4m7AXNELVE0UWzMtt5pOfCHXuTDuaQXyu+0caU6ZayNj66ow1OOqvmegxS5mykVWw9cO0GXW90Wpk6olG3kSxqjOJ5MUPeznySFTRBi7zx8SVTbvJCwvmEWFvbawwc29O1FjyBBePky3s56CRq2eQqu9Iw314XajfL253HU x-incomingheadercount: 44 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125500)(1701031045);SRVR:PU1APC01HT025; x-ms-traffictypediagnostic: PU1APC01HT025: x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(82015058);SRVR:PU1APC01HT025;BCL:0;PCL:0;RULEID:;SRVR:PU1APC01HT025; x-forefront-prvs: 0731AA2DE6 x-forefront-antispam-report: SFV:NSPM;SFS:(7070007)(199004)(189003)(8676002)(2351001)(104016004)(102836004)(1730700003)(7696005)(81156014)(8936002)(105586002)(68736007)(45080400002)(588024002)(74316002)(97736004)(14454004)(2900100001)(25786009)(33656002)(4270600006)(606006)(6916009)(5250100002)(7116003)(3480700004)(5660300001)(106356001)(2501003)(7066003)(105004)(558084003)(426003)(6306002)(54896002)(53376002)(99286004)(55016002)(476003)(20460500001)(256004)(236005)(82202002)(17480700002)(53366004)(87572001)(46003)(6436002)(86362001)(19627405001)(486006)(5640700003)(221733001)(6346003)(135393001)(217283001)(220243001)(42262002)(10090945008);DIR:OUT;SFP:1901;SCL:1;SRVR:PU1APC01HT025;H:MA1PR01MB0504.INDPRD01.PROD.OUTLOOK.COM;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:; received-spf: None (protection.outlook.com: outlook.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=xn--ls8ha@outlook.com; x-microsoft-antispam-message-info: 1hB2K4YT2O0kPIKFQFuK5MkKMpbq//Nz/nLHv3mR53oy2kxliK+wcoRfC4T7Kotj5h28m5YlpaQo0VMqKn8eIBw0m7fXOJemQf57W/hJPBNKbS1QLGCUw7O+p8YzveR2lTuTG/2/HMkXax0aiMcWmW17N/Xs73U40tMus0egk0NXZa2WdNRNKIEDPkwJH/BEaausYzwOuKlQQFzNMy+IPBp8RhpA43XvIJLmI3uCrO4= Content-Type: multipart/alternative; boundary="_000_MA1PR01MB0504324A40284B728F144030E4590MA1PR01MB0504INDP_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: f12efbb0-867f-4c93-8261-502eceebfafa X-MS-Exchange-CrossTenant-Network-Message-Id: 78a9bde9-00e8-4b24-8c25-08d5e7977f35 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: f12efbb0-867f-4c93-8261-502eceebfafa X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2018 01:33:40.2226 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT025 From nobody Wed Jul 11 20:23:12 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0A2130DD6 for ; Wed, 11 Jul 2018 20:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=k7VY064y; dkim=pass (2048-bit key) header.d=kitterman.com header.b=AabTlyuM Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxEK0f3uZiLt for ; Wed, 11 Jul 2018 20:23:08 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACC20130DCA for ; Wed, 11 Jul 2018 20:23:08 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1531365786; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=BI63b4//7um9Ie1QZ+S2n1MLy0nxf1gM6HGNl7UrKO8=; b=k7VY064yZ367SyToAY05dvUGyDfdTGaSpkBqpcU1yyLpaSCI1rBzv2Bu ETAjeRrsZ6zkfxxiJoynP+jIFNcHCQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1531365786; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=BI63b4//7um9Ie1QZ+S2n1MLy0nxf1gM6HGNl7UrKO8=; b=AabTlyuMe2npSyMcthEysaouNrgWaJQ8+7gLuImNyTjwtI1EtUfKYOcr SFu22vpNKNS5NBsmmbrXsLsolp9KRaXXFiFIIooNvDodOH4LOPnIMhLpqL rkQGtcum1aoVGHrCNXbKNWZCnVxe74wbsBCyDdFtSUhLX6zmk08JZQDDX/ wlYPsiX8cJ28iAEqlDQpUD9KcW3+1pZC3MTTQoYoqM5gNyKvEyA1eKbN+P AIKTCWY9O6XYKkhTiJiE1wZYkOACeHLCbfr7FFka1cIjbOoVvh/S5Bm3v7 h+p0QUq9SahfmruoCfvFKVph702fNnU/yxrF30ORslxZORFasmQsQQ== Received: from [192.168.1.146] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 4FEEAC4026B; Wed, 11 Jul 2018 22:23:06 -0500 (CDT) Date: Thu, 12 Jul 2018 03:22:41 +0000 In-Reply-To: <20180712002039.DD05520020EA83@ary.qy> References: <20180712002039.DD05520020EA83@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: <9F097CFB-F6DB-4B3E-99C4-EE660616CFCD@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] Any outstanding issues on 7601bis? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 03:23:11 -0000 On July 12, 2018 12:20:39 AM UTC, John Levine wrote: >In article <2940516=2EWEBi8fTYBz@kitterma-e6430> you write: >>Is the list of EAI affected components of the field complete? As an >example,=20 >>sometimes email addresses are used for SMTP Auth user IDs (or >sometimes just=20 >>the local part)=2E I don't know a lot about EAI, but it seems to me >that most=20 >>any field might have to contain UTF-8 now? =20 > >Any field that is a domain name or an e-mail address can be UTF-8 in >an EAI message=2E Thanks=2E It's probably better to say that explicitly rather than list ou= t a few of the possibilities=2E =20 Scott K From nobody Wed Jul 11 20:33:33 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9BB5130EA8 for ; Wed, 11 Jul 2018 20:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUlB5jLouVki for ; Wed, 11 Jul 2018 20:33:28 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEB1A130E26 for ; Wed, 11 Jul 2018 20:33:28 -0700 (PDT) Received: from steel.local ([IPv6:2601:647:5500:1330:a8ed:8bba:f947:aecf]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id w6C3XMVC025235 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 11 Jul 2018 20:33:24 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1531366404; bh=JZYmq2e4aq49Btyu/4sNimXu/oZ5i7paxowVGGW60r4=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=gFMFmtamdhRVdUrzoTB8Knnm7bvk72vsQr2dA2RtR7Wuk94GVHQURsvuEPJKiSxyi zL21ZHnsoVnQH+5Y51oBwA63Czr3Dn6lQ8k6FkS4oNtwuBKP7XJ4BjI+dLqzR4SZMw iCxF1Bm3BGN7aw2UVttJMthIzYN+Yb3O4Yxpx2Vo= To: "Kurt Andersen (b)" Cc: Brandon Long , "Murray S. Kucherawy" , "dmarc@ietf.org" References: <96be85f9-dd0e-4259-47f4-2e7c425c404c@bluepopcorn.net> <968bd954-34a8-05ed-ceec-d4274107a773@bluepopcorn.net> From: Jim Fenton Message-ID: <2f29fe29-06c8-2477-39c4-5424abd31f45@bluepopcorn.net> Date: Wed, 11 Jul 2018 20:33:16 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9E4A5B705B0A729CD6D6982A" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC protocol-15 posted X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 03:33:31 -0000 This is a multi-part message in MIME format. --------------9E4A5B705B0A729CD6D6982A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 7/11/18 6:23 PM, Kurt Andersen (b) wrote: > On Wed, Jul 11, 2018 at 5:38 PM, Jim Fenton > wrote: > > > So essentially we're creating a bunch of header bloat (creating > duplicate header fields with different names where that could be > avoided) because there are some MTAs that did not follow the > specifications before. That makes me unhappy, but what matters > here is not the behavior of all MTAs, it's the behavior of MTAs > implementing ARC (that include instance number tag/value). If > there's an MTA in the middle that deletes DKIM-Signature, it's not > implementing ARC and the chain is broken. > > > The DMARC WG is explicitly *not* scoped to make normative changes to > any other specifications so changing DKIM (for example) is not an > available option. Deleting or otherwise breaking one or more of the > DKIM-Signatures on a message has nothing to do with ARC per se. It's > even possible that an ARC-implementing ADMD could do such a thing. I'm afraid I wasn't able to find that explicit statement in the charter. On the other hand, it says that one of the options the WG has is to propose "A form of DKIM signature that is better able to survive transit through intermediaries." So I don't see my suggestion as being out of scope. -Jim --------------9E4A5B705B0A729CD6D6982A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit On 7/11/18 6:23 PM, Kurt Andersen (b) wrote:
On Wed, Jul 11, 2018 at 5:38 PM, Jim Fenton <fenton@bluepopcorn.net> wrote:

 So essentially we're creating a bunch of header bloat (creating duplicate header fields with different names where that could be avoided) because there are some MTAs that did not follow the specifications before. That makes me unhappy, but what matters here is not the behavior of all MTAs, it's the behavior of MTAs implementing ARC (that include instance number tag/value). If there's an MTA in the middle that deletes DKIM-Signature, it's not implementing ARC and the chain is broken.

The DMARC WG is explicitly *not* scoped to make normative changes to any other specifications so changing DKIM (for example) is not an available option. Deleting or otherwise breaking one or more of the DKIM-Signatures on a message has nothing to do with ARC per se. It's even possible that an ARC-implementing ADMD could do such a thing.

I'm afraid I wasn't able to find that explicit statement in the charter. On the other hand, it says that one of the options the WG has is to propose "A form of DKIM signature that is better able to survive transit through intermediaries." So I don't see my suggestion as being out of scope.

-Jim

--------------9E4A5B705B0A729CD6D6982A-- From nobody Wed Jul 11 23:45:19 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F7A131066 for ; Wed, 11 Jul 2018 23:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qa21DLJ0GHlX for ; Wed, 11 Jul 2018 23:45:15 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19188130E13 for ; Wed, 11 Jul 2018 23:45:15 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id g6-v6so12597018lfb.11 for ; Wed, 11 Jul 2018 23:45:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=I3wJfMGxqOr1KWYZSfL6A3/CaylfZfgNiK6a181xxZ8=; b=eNQfv8ygNgjhWT54VA4kglt8j4VXrJ6+Q83niPfxrCbpcog3yO27ksIPghbXMtMpP+ KTxQLqBkITwOubHD6kPCMObUqBc7uNKSsR6k/9WiXjv9anxVBmQ87YfIZr1RekpeEXeE L6Fz/WuRyXY6KiIXp8kwkcTKi6tVc2WNZLKshu/9GJGYU709hJ+etbyBaVyZkxeMgMD/ dkoTTRG5i13ipp6lV2QnfnUATQlkiOOP4xUEe7UJfpjwdkP9d3aYjsHlxAh1c1zomoAQ TXKgNSB7wpubTz6JpF0fiRuSfQnkbbOp9+axCMo9IXjjmCZqGD9WBoq7x/6i71GQs23b YT6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=I3wJfMGxqOr1KWYZSfL6A3/CaylfZfgNiK6a181xxZ8=; b=psfIZojCr5wRgsuqC6Em5Xi5UTPDBImJOIeBeFEYWtiZRaL+pPLQhH1IAbNhxTGirH KRq+k8U/TB0g2+RzBah9mC5TjPj8/SXU3QiCtABqfrPM1pzDWNAgD+cMNwtZ823a1Pag /d/VmzPC1MxFWB+ThDGOi6ANENEJ5mFDBJU+pvi8c/R6xVsTNteVT3Zyazh/ZATYRLsA updd67mziz1m6ivf5Ph3sapc6ASQLFkUGCaopBhOx9OBGEM10H1NpV0Lc3FGbVGtHvYM nBK7ZFolZq6GqE62eMthVwXm5HN3zzQ4rJ2APXe7uKB45jbhLkew12EGuIHIUW+4SLdY OIrw== X-Gm-Message-State: AOUpUlGzvSO75XwnWq2KdyT61fDl9jSYuX7cpJsxFSiC3h2fMBD6zf9x k2Au2sq2pujuh1SlKHfPKSknssPGT97/hyvyocHKZQ== X-Google-Smtp-Source: AAOMgpfG2gqZXV0LSHf59KArjiw25o4ncshUji1o9myhCmRjmGKKQ8nVSSqiWzRuSGg25w33Z++PPLQrRJ0q7h6oW+Y= X-Received: by 2002:a19:eb1b:: with SMTP id j27-v6mr792154lfh.0.1531377913090; Wed, 11 Jul 2018 23:45:13 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:3a13:0:0:0:0:0 with HTTP; Wed, 11 Jul 2018 23:45:12 -0700 (PDT) In-Reply-To: <2f29fe29-06c8-2477-39c4-5424abd31f45@bluepopcorn.net> References: <96be85f9-dd0e-4259-47f4-2e7c425c404c@bluepopcorn.net> <968bd954-34a8-05ed-ceec-d4274107a773@bluepopcorn.net> <2f29fe29-06c8-2477-39c4-5424abd31f45@bluepopcorn.net> From: "Murray S. Kucherawy" Date: Wed, 11 Jul 2018 23:45:12 -0700 Message-ID: To: Jim Fenton Cc: "Kurt Andersen (b)" , Brandon Long , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000086d7850570c7b40b" Archived-At: Subject: Re: [dmarc-ietf] ARC protocol-15 posted X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 06:45:18 -0000 --00000000000086d7850570c7b40b Content-Type: text/plain; charset="UTF-8" On Wed, Jul 11, 2018 at 8:33 PM, Jim Fenton wrote: > On 7/11/18 6:23 PM, Kurt Andersen (b) wrote: > > On Wed, Jul 11, 2018 at 5:38 PM, Jim Fenton > wrote: > >> >> So essentially we're creating a bunch of header bloat (creating duplicate >> header fields with different names where that could be avoided) because >> there are some MTAs that did not follow the specifications before. That >> makes me unhappy, but what matters here is not the behavior of all MTAs, >> it's the behavior of MTAs implementing ARC (that include instance number >> tag/value). If there's an MTA in the middle that deletes DKIM-Signature, >> it's not implementing ARC and the chain is broken. >> > > The DMARC WG is explicitly *not* scoped to make normative changes to any > other specifications so changing DKIM (for example) is not an available > option. > > Why are we doing 7601bis then? ;-) > Deleting or otherwise breaking one or more of the DKIM-Signatures on a > message has nothing to do with ARC per se. It's even possible that an > ARC-implementing ADMD could do such a thing. > > > I'm afraid I wasn't able to find that explicit statement in the charter. > On the other hand, it says that one of the options the WG has is to propose > "A form of DKIM signature that is better able to survive transit through > intermediaries." So I don't see my suggestion as being out of scope. > I agree that it's in scope for the charter, but we're pretty far down the road of trying what we have before us to be going back to square one. Given that we've settled on Experimental status, I propose this gets tabled until that's published. The experiment will establish what benefit ARC can provide, which I think is the most important output of this work. The change being suggested here appears to be one of efficiency, not something that will assist with evaluating that benefit. -MSK --00000000000086d7850570c7b40b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 11, 2018 at 8:33 PM, Jim Fenton <fenton@= bluepopcorn.net> wrote:
=20 =20 =20
On 7/11/18 6:23 PM, Kurt Andersen (b) wrote:
=20
On Wed, Jul 11, 2018 at 5:38 PM, Jim Fenton <fenton@bluepopcorn.net> wrote:

 So essentially we're creating a bunch of header bloat (creating duplicate header fields with different names where that could be avoided) because there are some MTAs that did not follow the specifications before. That makes me unhappy, but what matters here is not the behavior of all MTAs, it's the behavior of MTAs implementing ARC (that include instance number tag/value). If there's an MTA in the middle that delete= s DKIM-Signature, it's not implementing ARC and the chain is broken.

The DMARC WG is explicitly *not* scoped to make normative changes to any other specifications so changing DKIM (for example) is not an available option.
Why are we doing 7601b= is then?=C2=A0 ;-)
Dele= ting or otherwise breaking one or more of the DKIM-Signatures on a message has nothing to do with ARC per se. It's even possible that an ARC-implementing ADMD could do such a thing.

 I'm afraid I wasn't able to find that explicit statement in the charter. On the other hand, it says that one of the options the WG has is to propose "A form of DKIM signature that is better able to survive transit through intermediaries." So I don't see my suggestion as being out of scope.

I agree that = it's in scope for the charter, but we're pretty far down the road o= f trying what we have before us to be going back to square one.
<= br>
Given that we've settled on Experimental status, I propos= e this gets tabled until that's published.=C2=A0 The experiment will es= tablish what benefit ARC can provide, which I think is the most important o= utput of this work.=C2=A0 The change being suggested here appears to be one= of efficiency, not something that will assist with evaluating that benefit= .

-MSK
--00000000000086d7850570c7b40b-- From nobody Thu Jul 12 00:59:29 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B09130E0E for ; Thu, 12 Jul 2018 00:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dmarcanalyzer.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WqgrzQfPWzY for ; Thu, 12 Jul 2018 00:59:25 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3F46130EBF for ; Thu, 12 Jul 2018 00:59:25 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id w16-v6so5672436ita.0 for ; Thu, 12 Jul 2018 00:59:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dmarcanalyzer.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=LmZ0pLH/ZhpQ6a6cDd9Y13lF+3Xa49m6579lgiT4yx4=; b=KPMMZ1QuTSXy2oxL7CM19q72t7FsvuImYLNdRhFW1W+DAlb64XrFwUT708OY7x4ndO YPTOCOnjZ9eFJrlVzvXV0gTwCEK1pCtq8s9qmZOpQl6PpsE31HUxaqTgwiA/UYtlb8I8 DIUSIWoM7yx373iTnXRaddHY162ZYhZBZU/a4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=LmZ0pLH/ZhpQ6a6cDd9Y13lF+3Xa49m6579lgiT4yx4=; b=cmu/0jy+5U7Gqnyg3bsXucl/29SbvfsK0xiewiNcePCuviHD9bsL31ijfGL+LnRcfj 6fYi3Ao66p37fFVBQRpLYgYZNiIO6Zpspmi/0YAFhkj5RUeWsj8nvmMpanOdy7ps98tc SewhaGmzdYjdfNFaBFJ6hAL9T3Uh2PSfiTAsrKeT4DiVE6JZykqmjoq5oMycnDUrpQ+1 12I7VMfT6+iwlTyFRJi6W9QmVQrqyaYgWMXjEkbYd7m7XfbhZO7Aqob1g71domNHY+Z5 mQBPxZW3EkHx29Y/Jun3GvEVoBZZRV+RFQsqAPX7BrP0ds9atKkbk7yWc8BBjZu7rrEo ydyA== X-Gm-Message-State: AOUpUlG/4pj35wVQ+wmEwtJYmgclnzELi44c2MPS+vQerFXPolPuottE F5rvNRdPcuC5E1f0hl+FBANIVzHV2GA7D/0Q87qA3Zky X-Google-Smtp-Source: AAOMgpcpgrkS4FTDWeJP4lWN7RGgivEN0BGAtwadeSl1QqL153GQsc5cq5DOLTXfzabe3hvb/L7xnwKmMDMJF3KVE60= X-Received: by 2002:a24:2895:: with SMTP id h143-v6mr446443ith.61.1531382364659; Thu, 12 Jul 2018 00:59:24 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:3057:0:0:0:0:0 with HTTP; Thu, 12 Jul 2018 00:58:44 -0700 (PDT) From: Martijn van der Lee Date: Thu, 12 Jul 2018 09:58:44 +0200 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="000000000000dc78210570c8bd82" Archived-At: Subject: [dmarc-ietf] Message sender as part of ARC chain? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 07:59:28 -0000 --000000000000dc78210570c8bd82 Content-Type: text/plain; charset="UTF-8" This is more in regards to the Recommended Usage draft than the ARC spec itself (and possibly this has been answered elsewhere before). Is a message sender allowed (or perhaps even advised) to be part of the ARC chain as the first set of the chain? -- Martijn van der Lee --000000000000dc78210570c8bd82 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is more in regards to the Recommended Usage draf= t than the ARC spec itself (and possibly this has been answered elsewhere b= efore).

Is a message sender allowed (or perhaps ev= en advised) to be part of the ARC chain as the first set of the chain?
<= /div>

--
Martijn van der Lee
<= div>
--000000000000dc78210570c8bd82-- From nobody Thu Jul 12 03:55:52 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1F11130F81 for ; Thu, 12 Jul 2018 03:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZMFalJijMet for ; Thu, 12 Jul 2018 03:55:47 -0700 (PDT) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2575130DDA for ; Thu, 12 Jul 2018 03:55:46 -0700 (PDT) Received: by mail-ed1-x52c.google.com with SMTP id d3-v6so21569106edi.1 for ; Thu, 12 Jul 2018 03:55:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=BFWADeHn+mNpdzZQlC7LIdjGvinL+Wz7PaWf3DfzemE=; b=dxEKIMveauskUsw/epcYSKFueMeceHY18Jows5E2JLkK7Sfnd2rgK8c+9GqskOZ3jP LSo0DuAV92zYqUoxNbtDNmGYiKlTdMmjB/w58wBbucUdFN5/ryI1Pad+2LKp18IJLIHQ YGe5e7w3kkj8hccCq8Gz40SY/JHQqi5kPg9iI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=BFWADeHn+mNpdzZQlC7LIdjGvinL+Wz7PaWf3DfzemE=; b=k+uZ+EFypwci9RE+fG/2/Mg3lQSLwv44t9ayxTbOdvjhok4c/cKg2M6+hAGKbXJfUE ZG+dyIgpoykWnMCyYqhK+yR3yZ43EJODmrrsHHnUc8HtOdXT7+CdXmjm5UpOD+kzP9ei srjHiliJjaY4zQPh7gFLZhAJQbNNgtckWUUk9rSnDAbbbIMfx+anT5mGof5ExWZZTSOb GmsVaT+Fur4fOjWcKvUXdFmNRebrpKpNoTnx1I+5aJMxwNRmAqcy3S7LP4PzTfmm31TH 2g3zCBHcYQSypANVQY7ZWMOpFq7Tj2PWYtg0eh6qRwlGdITSnyw8dFnGalpVQp2WxERz uCEA== X-Gm-Message-State: AOUpUlGVQLX4SIV4cBZ8qZZNInG7klEBFaXH3n5d34cmhgqSbEfI6QSo Cbv7joVStVqDZofy+B0HUyVIfADbE0g3WEkn1Nzz0g== X-Google-Smtp-Source: AAOMgpdci9x4pj+oCsWykgh5aHUdWS+QH6VTjRrNleVuJIL67Eh5ej6f0mdikXTYkILzW1r6K2A7ibaCk3CNoJuhU4M= X-Received: by 2002:a50:b962:: with SMTP id m89-v6mr2109332ede.20.1531392945196; Thu, 12 Jul 2018 03:55:45 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 2002:aa7:da87:0:0:0:0:0 with HTTP; Thu, 12 Jul 2018 03:55:44 -0700 (PDT) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Thu, 12 Jul 2018 03:55:44 -0700 X-Google-Sender-Auth: h-GSYTLuLhFqZo4HjgYP4_4Udog Message-ID: To: Martijn van der Lee Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000082a59c0570cb346e" Archived-At: Subject: Re: [dmarc-ietf] Message sender as part of ARC chain? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 10:55:50 -0000 --00000000000082a59c0570cb346e Content-Type: text/plain; charset="UTF-8" On Thu, Jul 12, 2018 at 12:58 AM, Martijn van der Lee < martijn=40dmarcanalyzer.com@dmarc.ietf.org> wrote: > This is more in regards to the Recommended Usage draft than the ARC spec > itself (and possibly this has been answered elsewhere before). > > Is a message sender allowed (or perhaps even advised) to be part of the > ARC chain as the first set of the chain? > Allowed = yes; advised = no The protocol was explicitly designed to require no changes on the part of the initiating ADMD. It is only for intermediary ADMDs, and especially those which do or may change the message in some fashion (that impacts authentication mechanisms). Sort of by definition (SPF-wise), that would include all intermediaries, but we mainly have in mind those which break the validity of the DKIM signature(s). --Kurt --00000000000082a59c0570cb346e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Jul 12, 2018 at 12:58 AM, Martijn van der Lee <martijn=3D40dmarcanalyzer.com@dmarc.ietf.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
This is more in regards= to the Recommended Usage draft than the ARC spec itself (and possibly this= has been answered elsewhere before).

Is a message= sender allowed (or perhaps even advised) to be part of the ARC chain as th= e first set of the chain?

Allowed =3D yes; advised =3D no=

The p= rotocol was explicitly designed to require no changes on the part of the in= itiating ADMD. It is only for intermediary ADMDs, and especially those whic= h do or may change the message in some fashion (that impacts authentication= mechanisms). Sort of by definition (SPF-wise), that would include all inte= rmediaries, but we mainly have in mind those which break the validity of th= e DKIM signature(s).

--Kurt
--00000000000082a59c0570cb346e-- From nobody Thu Jul 12 04:38:29 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E10A71310EA for ; Thu, 12 Jul 2018 04:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dmarcanalyzer.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJPe2X3tlPpG for ; Thu, 12 Jul 2018 04:38:22 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C275B1310E4 for ; Thu, 12 Jul 2018 04:38:22 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id q9-v6so27922262ioj.8 for ; Thu, 12 Jul 2018 04:38:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dmarcanalyzer.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3zeDP8Qkz/xnIy+YTxzRRZqlm85GpHU/ZFqftfeTHaM=; b=RsRFzNemhCIeJ9490KSFAUksgHcZwPc8S2XxNuK27XGkO4u0GnvhD0ZGo+vmrMAzjZ n5BilzwrXN9M1Bd16XlHfT0CvuJRLFAT019LGfF4j/AM9rb9HpZrX3dL+GeHLZCLkkUQ kn+OkQUD5uLU1LHVV+uYNSEOZKfCozIKoERzI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3zeDP8Qkz/xnIy+YTxzRRZqlm85GpHU/ZFqftfeTHaM=; b=fWH+tg1iJYACo8l3ajuBG9WrNsHsX4bGQEpprNPhgrgttZ+6344Z0Oj0Rggoy55vS5 bLeuCObmYKj3QzvFGfBQJO++j7GBHUvKt9n+n1uVNA9ikDpEVFqh+9tuYFTeuj90a9+O r5RG731kNvrRMZr4uPzgT+pBaNIWx8StnHLGHKNfPw0yGbyGnONDilEuEDSCvTWfhgwB idsIBh6ovdB49oQSy5m/I3rEoe/woxhlAu483F1hdFOVeiq8vHDQD/+D1fAJsOSUWMX9 nxaVifv7y79TFp7nFb4yk+0q35jBUe55W9BBiyK/sC6mFgmhNyxIs4ZNsweUi1+ScTrw 6Ilw== X-Gm-Message-State: APt69E0WLYVpkCrqW1NA2fAG0YowfoxFDx+Ac+yHf0PKlt5nliLqqVip 5qKVolJYAwriZiP/wqKiYHThALUuUJfyVj+U2U2X3w== X-Google-Smtp-Source: AAOMgpdpelDM9vOWmcUO91ZFzMpmkVnycULmNiMVx/ZWpq4kJI4A0WCG0LNti4mfd83GD+gPuaPc8JYWJoWtmdTbTug= X-Received: by 2002:a6b:ed0:: with SMTP id 199-v6mr27826322ioo.69.1531395501879; Thu, 12 Jul 2018 04:38:21 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:3057:0:0:0:0:0 with HTTP; Thu, 12 Jul 2018 04:37:41 -0700 (PDT) In-Reply-To: References: From: Martijn van der Lee Date: Thu, 12 Jul 2018 13:37:41 +0200 Message-ID: To: "Kurt Andersen (b)" Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e68d7a0570cbcc5b" Archived-At: Subject: Re: [dmarc-ietf] Message sender as part of ARC chain? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 11:38:27 -0000 --000000000000e68d7a0570cbcc5b Content-Type: text/plain; charset="UTF-8" Perhaps "advised" was a wrong choice of words. I understand that ARC makes no additional demands on the sender. But would it be beneficial or harmful (or neutral) for the sender to do so anyway? I can imagine validators taking note of ARC capability of an ADMD for reputation tracking. If an email is send by a sender known to start the ARC chain itself, the start of a chain by a malicious sender spoofing as an intermediary could help a validator draw more appropriate conclusions about it's trustworthiness. It would still be possible for a malicious party to spoof an entire chain, but it would be just a little bit harder to do so. I was just wondering if there could be any real-world validity to these assumptions. On Thu, Jul 12, 2018 at 12:55 PM, Kurt Andersen (b) wrote: > On Thu, Jul 12, 2018 at 12:58 AM, Martijn van der Lee < > martijn=40dmarcanalyzer.com@dmarc.ietf.org> wrote: > >> This is more in regards to the Recommended Usage draft than the ARC spec >> itself (and possibly this has been answered elsewhere before). >> >> Is a message sender allowed (or perhaps even advised) to be part of the >> ARC chain as the first set of the chain? >> > > Allowed = yes; advised = no > > The protocol was explicitly designed to require no changes on the part of > the initiating ADMD. It is only for intermediary ADMDs, and especially > those which do or may change the message in some fashion (that impacts > authentication mechanisms). Sort of by definition (SPF-wise), that would > include all intermediaries, but we mainly have in mind those which break > the validity of the DKIM signature(s). > > --Kurt > -- Best regards, Martijn van der Lee Software developer DMARC Analyzer - Trusted. Email. Delivered. Stationsplein 12 | 1211 EX | Hilversum | The Netherlands www.dmarcanalyzer.com | +31 (0) 85 13 00 788 We are accredited on security and privacy by the DDMA Privacy Authority. --000000000000e68d7a0570cbcc5b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Perhaps "advised" was a wrong choice of words. I= understand that ARC makes no additional demands on the sender. But would i= t be beneficial or harmful (or neutral) for the sender to do so anyway?
I can imagine validators taking note of ARC capability of an ADMD= for reputation tracking. If an email is send by a sender known to start th= e ARC chain itself, the start of a chain by a malicious sender spoofing as = an intermediary could help a validator draw more appropriate conclusions ab= out it's trustworthiness. It would still be possible for a malicious pa= rty to spoof an entire chain, but it would be just a little bit harder to d= o so. I was just wondering if there could be any real-world validity to the= se assumptions.

On Thu, Jul 12, 2018 at 12:55 PM, Kurt Andersen (b) <kboth= @drkurt.com> wrote:
On Thu, Jul 12, 2018 at 12:58 AM, Martijn van der Lee <martijn=3D40dmarcanalyzer.com@dmarc.ietf.org> wrote:
This is = more in regards to the Recommended Usage draft than the ARC spec itself (an= d possibly this has been answered elsewhere before).

Is a message sender allowed (or perhaps even advised) to be part of the = ARC chain as the first set of the chain?

Allowed = =3D yes; advised =3D no

The protocol was explicitly designed to require no change= s on the part of the initiating ADMD. It is only for intermediary ADMDs, an= d especially those which do or may change the message in some fashion (that= impacts authentication mechanisms). Sort of by definition (SPF-wise), that= would include all intermediaries, but we mainly have in mind those which b= reak the validity of the DKIM signature(s).

--Kurt



--
Best regards,

Martijn van der = Lee
Software developer



DMARC Analyzer - Trusted. Email. Delivered.

Stationsplein 12 | = 1211 EX | Hilversum |=C2=A0The Netherlands
www.dmarcan= alyzer.com=C2=A0|=C2=A0+31 (0) 85 13 00 788

=C2=A0=C2=A0=C2=A0
We are accredited on security an= d privacy by the DDMA Privacy Authority.
--000000000000e68d7a0570cbcc5b-- From nobody Thu Jul 12 06:03:38 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 191FB130E3C for ; Thu, 12 Jul 2018 06:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwbhWOsZ-np9 for ; Thu, 12 Jul 2018 06:03:34 -0700 (PDT) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08EBF130E3A for ; Thu, 12 Jul 2018 06:03:34 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id v22-v6so21827538edq.4 for ; Thu, 12 Jul 2018 06:03:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vealfEGqlsJJzsBZmnx2RdrMcOzW8xQ7yKmaP77WvDs=; b=MkqBoSG5t+5I+pIpRRHAvOYsOvu2uk2meECL5e+X/ZuRlR9KXxoo8y5rFVop36ERZJ pTYzTJp0KI7Bx+oRfISoifnoz0pqufIBd4cOI0Fg6uOXhhF5D9vA2++eQZoTvjvVVV2S gxp0oJG5oojgZTHXNd5Gw3tEJn/06r5W0BuAw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vealfEGqlsJJzsBZmnx2RdrMcOzW8xQ7yKmaP77WvDs=; b=ZG8hkV1/7BfB2wm9rRGrT6lw9nAGjnTWAkjL5cxfF9QsmIsc8ASsP5wyfEKHpxB16i D4Atq/lcCo0V8SMOGySd6NBCryiBfbNt37iE4N1OgE55rR8bortBg10wI1l0ix+ICcAt MZhss1qpjob9n4CEuhqftaaJaAlZfqR4nJa4MZo+gCPiNRTR4PmGLs4tkkawU2RC8A4N W0vbX5K0FvUW3yj0uel4a5UlnLn8cfBlQHVmR43kKkSxH7lJkr3c8537OunW05wBgIra W8ZCzSretsqoo2U0+OnpCEIEivWc9LSzAEYKK+Yn2zc1dIfFrBW6kPFZ6/E/hJDTRruZ +YtA== X-Gm-Message-State: AOUpUlFIFtT4kIApZ8AO/6OsPsbOzlnnyBph/I5xoxCsA3k+t/tuY0lm 5BlbXtcxMBVFUodE3pdMPmKBHzxjQaG/wx2WLjiEsw== X-Google-Smtp-Source: AAOMgpe8AyIqEbavTr72lQZGSluY5Sxrrd49AVJo3Gn6/biVwAOWY/rq+iY2LLOkFpy9QZHjFIApKZtm8kswKFmrGGM= X-Received: by 2002:aa7:d2cd:: with SMTP id k13-v6mr2409840edr.311.1531400612483; Thu, 12 Jul 2018 06:03:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Kurt Andersen (b)" Date: Thu, 12 Jul 2018 09:03:21 -0400 Message-ID: To: Martijn van der Lee Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="0000000000008425180570ccfdce" Archived-At: Subject: Re: [dmarc-ietf] Message sender as part of ARC chain? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 13:03:36 -0000 --0000000000008425180570ccfdce Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jul 12, 2018, 07:38 Martijn van der Lee wrote: > ... would it be beneficial or harmful (or neutral) for the sender to do s= o > anyway? > > I can imagine validators taking note of ARC capability of an ADMD for > reputation tracking. If an email is send by a sender known to start the A= RC > chain itself, the start of a chain by a malicious sender spoofing as an > intermediary could help a validator draw more appropriate conclusions abo= ut > it's trustworthiness. It would still be possible for a malicious party to > spoof an entire chain, but it would be just a little bit harder to do so.= I > was just wondering if there could be any real-world validity to these > assumptions. > Interesting thoughts. Starting an ARC series at the initial ADMD could give such a signal but I can think of easier ways to do so - perhaps a "I support ARC" bumper sticker published via DNS =F0=9F=98=80 --Kurt > --0000000000008425180570ccfdce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Thu, Jul 12, 2018, 07:38 Martijn van der Lee <martijn@dmarcanalyzer.com> wrote:
... would it be beneficial or = harmful (or neutral) for the sender to do so anyway?

I can ima= gine validators taking note of ARC capability of an ADMD for reputation tra= cking. If an email is send by a sender known to start the ARC chain itself,= the start of a chain by a malicious sender spoofing as an intermediary cou= ld help a validator draw more appropriate conclusions about it's trustw= orthiness. It would still be possible for a malicious party to spoof an ent= ire chain, but it would be just a little bit harder to do so. I was just wo= ndering if there could be any real-world validity to these assumptions.

Interesting thoughts. Starting an ARC series at the initial ADMD could = give such a signal but I can think of easier ways to do so - perhaps a &quo= t;I support ARC" bumper sticker published via DNS =F0=9F=98=80

--Kurt
--0000000000008425180570ccfdce-- From nobody Thu Jul 12 09:16:01 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE6A130DE5 for ; Thu, 12 Jul 2018 09:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4MX6eWJOX6BD for ; Thu, 12 Jul 2018 09:15:57 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FAF8126CC7 for ; Thu, 12 Jul 2018 09:15:57 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id q11-v6so31254022oic.12 for ; Thu, 12 Jul 2018 09:15:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=T3jvgGAyLnjOVAiLphvbr8dLjCrmdpmkDP1IkkcQAqQ=; b=PVLW4lBpLsH5VHNFP0DXLy9OrBPuafSofFF3VCKTl9FUtGng/5FPFYK1wTw32S7JoC kRSlCgf+oehr4xfYd2+6oD0cFdS7lc8MR5DRefMHCrUhXRCEaKvmrUUsIRDtjd/gMg0I cNunP90frhiGXP2ugR0Im3PQ22t+25Jw1fsINAex6SByNJSkwbu7+KHSZSeWe9ZQMPOb WCMMbx6IE6T5FulzGF0BPrP9chk2RbD/RM+kNwm64fjVQ1BS+dWbiYuvphub1TgXkrK0 qVP8VFmCl5a0R0KrHU6ypZf7guSP13FeqmDrATE5EqfHZIYZUzrhzO7EROorMLkZX3fY nheQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=T3jvgGAyLnjOVAiLphvbr8dLjCrmdpmkDP1IkkcQAqQ=; b=iPKkfOzUzh1g06lbUuaoeRzLIjIUNkBmuoqdXfT7dWDTq0/fi6pKQ1mTeVTEfb24Pc 1Uxj7oiABHXiYnn04n3czmy0IOBMd0sOsKmU1AIiiv4YTcbeIaq1dCTwhYmKFzyWBfip M/VcG5R2hMtYG+88QZsZypClAaxdbyIwMFmJkH+3yCMC+uYrRpX5LdzoHxRao+IG+Qfj PFAiSK+HBdUC3XhQ8G8X0DR6DUku5kA8DkfbYCJxhF41V8+vxO6vBmmzVVjarU5t2s7u qZc0a8ncgTvJiPZvNah57s71rShhY9tYuhLHYfMhO+syJBaP1dpQrzTkhRWF9vULEvSY +wAA== X-Gm-Message-State: AOUpUlHGOPe0eDFmR6oh/sdSBAIcx6vRrTznWOy8515PXpBqQ7dFxaZC /ecAimQ9ZN8sgR7uemI5I/YZTXNjGuy57HJHrcMdNeNk X-Google-Smtp-Source: AAOMgpdC3nCrUPWOb2f/urnmLFNXgdL5pStTuB+WT1mpfTS5BCcDL+1izCEw59b/8tz2U/O8H339+zb+9ilarXkXG3E= X-Received: by 2002:aca:bd8b:: with SMTP id n133-v6mr3132210oif.108.1531412156038; Thu, 12 Jul 2018 09:15:56 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:2646:0:0:0:0:0 with HTTP; Thu, 12 Jul 2018 09:15:35 -0700 (PDT) In-Reply-To: References: From: Seth Blank Date: Thu, 12 Jul 2018 09:15:35 -0700 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="00000000000090da180570cfad68" Archived-At: Subject: Re: [dmarc-ietf] Message sender as part of ARC chain? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 16:16:00 -0000 --00000000000090da180570cfad68 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jul 12, 2018 at 6:03 AM, Kurt Andersen (b) wrote= : > On Thu, Jul 12, 2018, 07:38 Martijn van der Lee > wrote: > >> ... would it be beneficial or harmful (or neutral) for the sender to do >> so anyway? >> > Sections 5.1.4 and 5.1.5 explicitly call out that it's safe to Seal. As Kurt mentioned, the marginal benefit for a sender to Seal on origination is thin, but it is by design not harmful. > >> I can imagine validators taking note of ARC capability of an ADMD for >> reputation tracking. If an email is send by a sender known to start the = ARC >> chain itself, the start of a chain by a malicious sender spoofing as an >> intermediary could help a validator draw more appropriate conclusions ab= out >> it's trustworthiness. It would still be possible for a malicious party t= o >> spoof an entire chain, but it would be just a little bit harder to do so= . I >> was just wondering if there could be any real-world validity to these >> assumptions. >> > > Interesting thoughts. Starting an ARC series at the initial ADMD could > give such a signal but I can think of easier ways to do so - perhaps a "I > support ARC" bumper sticker published via DNS =F0=9F=98=80 > Some receivers are already considering using this as a heuristic, especially as adoption ramps up and consistent Sealers become well known. "If we always see an ARC Seal from domain example.org, and we get a message that doesn't have one, scrutinize that message more thoroughly." To Kurt's comment about ARC in DNS, that's trickier, because ARC is the responsibility of a breaking intermediary, but a flag in DNS shifts some responsibility to the sender about mailflow that sender can't know about. --00000000000090da180570cfad68 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Jul 12, 2018 at 6:03 AM, Kurt Andersen (b) <kboth@drkurt.com> wrote:
On Thu, Jul 12, 2018, 07:38 = Martijn van der Lee <martijn@dmarcanalyzer.com> wrote:
... would it be beneficial or harmful (o= r neutral) for the sender to do so anyway?

Sections 5.1.4 and 5.1.5 explicitly call out= that it's safe to Seal. As Kurt mentioned, the marginal benefit for a = sender to Seal on origination is thin, but it is by design not harmful.
=C2=A0

I can imagine validators taking note o= f ARC capability of an ADMD for reputation tracking. If an email is send by= a sender known to start the ARC chain itself, the start of a chain by a ma= licious sender spoofing as an intermediary could help a validator draw more= appropriate conclusions about it's trustworthiness. It would still be = possible for a malicious party to spoof an entire chain, but it would be ju= st a little bit harder to do so. I was just wondering if there could be any= real-world validity to these assumptions.

Interesting though= ts. Starting an ARC series at the initial ADMD could give such a signal but= I can think of easier ways to do so - perhaps a "I support ARC" = bumper sticker published via DNS =F0=9F=98=80
=
Some receivers are already considering using this as a heuri= stic, especially as adoption ramps up and consistent Sealers become well kn= own. "If we always see an ARC Seal from domain example.org, and we get a message that doesn't have one, sc= rutinize that message more thoroughly."

To Ku= rt's comment about ARC in DNS, that's trickier, because ARC is the = responsibility of a breaking intermediary, but a flag in DNS shifts some re= sponsibility to the sender about mailflow that sender can't know about.=
--00000000000090da180570cfad68-- From nobody Thu Jul 12 10:15:16 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9DDF130DD2 for ; Thu, 12 Jul 2018 10:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWuIrYDso2V5 for ; Thu, 12 Jul 2018 10:15:13 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFFA2130F4A for ; Thu, 12 Jul 2018 10:15:12 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id s21-v6so20996037pfm.6 for ; Thu, 12 Jul 2018 10:15:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=4TOeb4o2kofZawUrBMnm2d1e2i07AP/nkTU6eFu+my0=; b=o0TcND6na3DklB11sD+W7Z/Kac2ZbbA+uJVYmrk3etvJg9mXozEmTcCKzF8bK9Z78F E4w6fl7iFvaoZU9wWoQR+oOrvsqeweb7x8Af88yTDaJ15gosx0MxxovDZbhQF5vTrYSi oA0Rm3I+ArjhmTXIR+3hFzuk7kMBeG38nItboHA2H4Y4M3rAI0oaLpGnvrJRWkAJHbef UrovVMXVdIUcoTPTelTf3efUejCeX793RF2iRabj6AxII8G64Ni1F/aMlBrpQBZRRHzG SH9er/R8ktcDhwnw6354pfNo735yMmR/sA6hyG5+oNwWsFDTzoUD32zHTdDLjvsRDhNo 7aPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=4TOeb4o2kofZawUrBMnm2d1e2i07AP/nkTU6eFu+my0=; b=PQulGHQ245GDlxzCpHC5r5WrawLc1TDnBekNB6+yQRBHyFLovSgO+geC1GxfmB+pHT N9N0BiWKoQBiBQ+O7c6D7IDFOzhVx4KOYqTyFCkfowDY1agoerHZUBmawSHdeV9qUfnH 4Ptngk0xxWAwOVZTHdaIsxcFyGIVx/nVrFtCuGi4koyh7zWfOIFgIbatMaoIrLc6iyyc LGqkLrv8qXUcx7EBVbml6AshLsSBTz2ihJqFtmquHB44bG4PRTkdjEd9DWgzYbbZtrpD I3+FoEu0On5Y3pEucZVy31jO6/+cYhpFYPPRhy48ZdI+FMBD3Mef23FoO+n0d41FCBXa CgDw== X-Gm-Message-State: AOUpUlGgOf/DrrJmlHCxt9a3JxK8pDOjEuT7Ru0jeSsDpO56bDD/wrQ1 dpdEWxEbkM9AWhBUgtS1oRXJcQfR X-Google-Smtp-Source: AAOMgpftb+M7KhaCFrlfEOEZd5QDler15megF+PGNRYc3exnv28bUR4gIpezehGdEjrOJamiRbNGaw== X-Received: by 2002:a62:198e:: with SMTP id 136-v6mr3301518pfz.103.1531415712147; Thu, 12 Jul 2018 10:15:12 -0700 (PDT) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net. [76.218.8.128]) by smtp.gmail.com with ESMTPSA id 8-v6sm42536677pfk.132.2018.07.12.10.15.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jul 2018 10:15:10 -0700 (PDT) To: Martijn van der Lee References: Cc: dmarc@ietf.org From: Dave Crocker Message-ID: <36d4e170-bd4a-460b-84d5-1090177bc2f8@gmail.com> Date: Thu, 12 Jul 2018 10:15:08 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Message sender as part of ARC chain? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 17:15:15 -0000 On 7/12/2018 12:58 AM, Martijn van der Lee wrote: > Is a message sender allowed (or perhaps even advised) to be part of the > ARC chain as the first set of the chain? Just for clarity, do you mean the author or the originator? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Jul 12 11:03:34 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7613B131150 for ; Thu, 12 Jul 2018 11:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmbOHdwnCTn4 for ; Thu, 12 Jul 2018 11:03:29 -0700 (PDT) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11297130E2E for ; Thu, 12 Jul 2018 11:03:29 -0700 (PDT) Received: by mail-ed1-x52a.google.com with SMTP id x5-v6so18891823edr.0 for ; Thu, 12 Jul 2018 11:03:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=BXnz1ni3ssL+7E0kpoAaZs0r5ybfdzt0RklElAuh/Ag=; b=OXoaYPsZ6gLW6ab9rZtLGJf/Q5/vco8/gCu6tDBl4ByrT1mSQHP4ZCPCAbUhzR9LiJ t5qkPf69I88f2ccN61QV86k8fOVVE2HMf0dnGtmR3QXzifDPBwBwILOIVgqI9DfhCo1E 6nnoaag1Km+6AAMQh0R4KxVd3pZRXsELGAZFQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=BXnz1ni3ssL+7E0kpoAaZs0r5ybfdzt0RklElAuh/Ag=; b=X9z3iXSaxFs6KfV7MyGRDzUPOuUix0fyBJs6HW3nS+xmiEu8vMbTQvNJjJStAOHURF RsDc/oMKVu8L9lbPUsE0dS7a59mBC2STU4gqmEk0rv/Kb6kHylj8CmvVBupP2AolxVTS kL8SkqtO50P39LgmPowmhvUelsJU8dgHSz1CswTliSAhyZhtf5F6IzEGaSFfqwDD2Du0 TVCOrf99nyfn76wtiMUgLtcTeMyrL5AmN+Ug1K1Sxv6ckbR63RScg3cO4hM0AHjB4E0h 1qHIGrtrjdcum/55e6TT7Chbyo+P6LEDXw76sHUOeBOsJSr88AZMYQMMKECA/JRwzhRG B1LA== X-Gm-Message-State: AOUpUlGYy6O6lo5pknO0gsh0W31AqqitZrobGtaH83QNj45y3JPrai9l hKyzml+O7BCVdSX+l/gX6bTf5O7FfrxqMZDbr0OuIg== X-Google-Smtp-Source: AAOMgpdq2jzI/8JWv0FTRfweRLxPqaG3oFmw58aJHGICx1V5BcnAtYd0ALXiWoMwSHnKy1zNRS6YJbcCx5qFGngubjg= X-Received: by 2002:a50:c251:: with SMTP id t17-v6mr3613952edf.108.1531418607512; Thu, 12 Jul 2018 11:03:27 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 2002:aa7:da87:0:0:0:0:0 with HTTP; Thu, 12 Jul 2018 11:03:26 -0700 (PDT) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Thu, 12 Jul 2018 11:03:26 -0700 X-Google-Sender-Auth: MnHLaim4ItsQ1gjRHMHjV68Z9No Message-ID: To: Seth Blank Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001a82610570d12ec6" Archived-At: Subject: Re: [dmarc-ietf] Message sender as part of ARC chain? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 18:03:32 -0000 --0000000000001a82610570d12ec6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jul 12, 2018 at 9:15 AM, Seth Blank wrote: > On Thu, Jul 12, 2018 at 6:03 AM, Kurt Andersen (b) > wrote: >> >> Interesting thoughts. Starting an ARC series at the initial ADMD could >> give such a signal but I can think of easier ways to do so - perhaps a "= I >> support ARC" bumper sticker published via DNS =F0=9F=98=80 >> > To Kurt's comment about ARC in DNS, that's trickier, because ARC is the > responsibility of a breaking intermediary, but a flag in DNS shifts some > responsibility to the sender about mailflow that sender can't know about. > I was (somewhat playfully) thinking that one could "advertise" the authentication mechanisms which one employs both on the sending (authentication by) and receiving (enforcement by) sides. For instance, a DMARC record implies that one supports *SPF ^ DKIM" analysis of outbound traffic but does not let a receiver know that they could also expect BATV or other signals. Maybe "scout merit badges" would be a better analogy than bumper stickers :-) It could be a way for ADMDs to indicate what *bona fides* a receiver should look for. On the receiver side, it could advertise FBLs, enforcement, reporting, etc. but this strays a bit further from "ARC as a protocol" and "using ARC". --Kurt --0000000000001a82610570d12ec6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Jul 12, 2018 at 9:15 AM, Seth Blank <seth@sethblank.com> wrote:
On Thu, Jul 12, 201= 8 at 6:03 AM, Kurt Andersen (b) <kboth@drkurt.com> wrote:
Interesting thoughts. Starting an ARC series at the initial = ADMD could give such a signal but I can think of easier ways to do so - per= haps a "I support ARC" bumper sticker published via DNS =F0=9F=98= =80
To Kurt's comment about ARC in = DNS, that's trickier, because ARC is the responsibility of a breaking i= ntermediary, but a flag in DNS shifts some responsibility to the sender abo= ut mailflow that sender can't know about.

I was (somewhat playfully) thinking that o= ne could "advertise" the authentication mechanisms which one empl= oys both on the sending (authentication by) and receiving (enforcement by) = sides. For instance, a DMARC record implies that one supports *SPF ^ DKIM&q= uot; analysis of outbound traffic but does not let a receiver know that the= y could also expect BATV or other signals. Maybe "scout merit badges&q= uot; would be a better analogy than bumper stickers :-) It could be a way f= or ADMDs to indicate what bona fides a receiver should look for.

On the receiver side, it could advertise FBLs, enforc= ement, reporting, etc. but this strays a bit further from "ARC as a pr= otocol" and "using ARC".

--Kurt

--0000000000001a82610570d12ec6-- From nobody Thu Jul 12 11:08:10 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26718130E58 for ; Thu, 12 Jul 2018 11:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=lB+Z+TN/; dkim=pass (1536-bit key) header.d=taugh.com header.b=LszCiOG6 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdvRdRsclTE9 for ; Thu, 12 Jul 2018 11:08:06 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8397F130E2E for ; Thu, 12 Jul 2018 11:08:06 -0700 (PDT) Received: (qmail 96035 invoked from network); 12 Jul 2018 18:08:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1771f.5b479905.k1807; bh=qjyuuqdqAXlhoVqropIw6qI/xWAadSEMSqhTBE4N8w0=; b=lB+Z+TN/Cz/65W45C0AwNS5wYq1NTpburGT+BJbeK16tjelqq6yIaMUe+uIx6i42ThYRix9xpET2qdji0Rcoy0b3yiKYRIZjIrvy1RcHKQ6/sm/miTH8TiEeFyQ+/+gXQ2n5Tuz6Jl+NmMUP83+vv2GeyCT/IelQD7X33gQpdr9uyiKVt0zUii9h6n5SqjO5CivDEUGjf54pqjThnoSEBWJLu/I/509IFWEH1Qr8rUVogN2LUiEfaL5z5w7uUEqT DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1771f.5b479905.k1807; bh=qjyuuqdqAXlhoVqropIw6qI/xWAadSEMSqhTBE4N8w0=; b=LszCiOG69aTewBYDdLJTstEK1mEJDMtddm6UFTDbjoi1PPmyzzll6StPNTr4fgg5Y8/eoO4SgCBgKFa/R60yTg0Y5Ih1aOmZG8tdt7ScnBk/YTrhNx8NdH9klBqHl8eC1xJ1EN21Q9/iaX4DvBMZZSK4qgTHOGE6+v46bPj9M1U7wT+jOOgNlBbbOrFG1SY+m1h/j1XDC1SZC+5rC57yShjrxqB1nylFeQRsEGXNejkXlG3MrluQ774RYufi6ceh Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 12 Jul 2018 18:08:05 -0000 Received: by ary.qy (Postfix, from userid 501) id ED4D62002391BD; Thu, 12 Jul 2018 14:08:04 -0400 (EDT) Date: 12 Jul 2018 14:08:04 -0400 Message-Id: <20180712180804.ED4D62002391BD@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: superuser@gmail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] ARC protocol-15 posted X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 18:08:09 -0000 In article you write: >Given that we've settled on Experimental status, I propose this gets tabled >until that's published. The experiment will establish what benefit ARC can >provide, which I think is the most important output of this work. The >change being suggested here appears to be one of efficiency, not something >that will assist with evaluating that benefit. Having written and deployed a bunch of ARC code, I do not believe that any sort of twiddle to try to combine one of the ARC headers with a DKIM signature would be productive, and I have no interest in going down that road. As I said in a previous message, the bloat wars are over and bloat won. Nobody cares any more about avoiding a few hundred bytes of message header. R's, John From nobody Thu Jul 12 12:52:44 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5D0130EF1 for ; Thu, 12 Jul 2018 12:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tfy4gS-XznO5 for ; Thu, 12 Jul 2018 12:52:40 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1FDA130E7B for ; Thu, 12 Jul 2018 12:52:39 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id c5-v6so25187760qth.5 for ; Thu, 12 Jul 2018 12:52:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:date:subject:message-id :references:in-reply-to:to; bh=HHQ4Q0sl+GqHgh8A6O1HFpJ2jilNDTrgMuNHmS7MiL4=; b=uIrKlOIcfqe6tQXCUpUTeoQW2qtTgXuyPKfGb0IxVvyxhmBY6LybrpCK9OYiaFzpXp Q7Lj5gBOYse5o1oB1Bptwiqa4DpEAXXpIE6a9+ckaFkJ7aaPuYWNssvey/S2mlLA9TW6 +w5RWKJTwf/hgFR1H3eyBbSRxzQ95JcJXZkCbsiIk5LAs874eYw9rGU6o+8lByz4lr9N PuYjUNfMpOOt1iymfikiFRrLpM+AN87fv/jbol3IkuXzVU6Qvf+gbFfx+onYgaQWOxF6 HC8LOu99AL4RHImwSj8a1eyci3iU70fldF7FLpXyKvuFjEqpkg9ZoLJwqdQKycbR2La0 n8QA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:references:in-reply-to:to; bh=HHQ4Q0sl+GqHgh8A6O1HFpJ2jilNDTrgMuNHmS7MiL4=; b=IDAcs5ct1Yp955alm8LsXqZqRVqfMI6Dm6La9hmnm8cFpCmMgY9yiSgiTvwxHl9sn4 0qkxp1BN2hYgdu8rzhaPKRQRqxmepwl3gpSTBi8arQ9bIiXR05NzNKa6ZivpilHSAVAt dx/Q/SZDH4QInAly4tBj8fxiWAmW3NQcV0XV3kJ+jeiFV2rEphUS5SZx9jVaXVXibEZ6 o06Y1N72tfwBsKqGCzJ6V/YbuODjNGqYx41elpznHBU537pglclILffrcH39SJVijFUK NaCOGiLSYCpYMNkrNAoSJuHC9fqoCET2xFMVRnPoa2x550aEY8VSMz8axYMPXzbJD/B9 EYDQ== X-Gm-Message-State: AOUpUlGYr4GH6Zy1c9CeL0e+craQbsR1CRsvP+QhvnUcqvwPC9rSK08q mFiNWcX+ZNvGbHoMnQWHG49vtHUh X-Google-Smtp-Source: AAOMgpcNs9EKfVQg7jWY1tXDZ5p1auBpu75jaSgpUJ23l5LhCoS9h8kHrntoR7iR4jG2TMXytPCR2A== X-Received: by 2002:ac8:1c63:: with SMTP id j32-v6mr3053024qtk.242.1531425158915; Thu, 12 Jul 2018 12:52:38 -0700 (PDT) Received: from [192.168.6.248] ([72.138.96.2]) by smtp.gmail.com with ESMTPSA id n59-v6sm15651591qte.97.2018.07.12.12.52.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jul 2018 12:52:37 -0700 (PDT) From: tjw ietf Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Thu, 12 Jul 2018 15:52:37 -0400 Message-Id: References: <20180712002039.DD05520020EA83@ary.qy> <9F097CFB-F6DB-4B3E-99C4-EE660616CFCD@kitterman.com> In-Reply-To: <9F097CFB-F6DB-4B3E-99C4-EE660616CFCD@kitterman.com> To: dmarc@ietf.org X-Mailer: iPhone Mail (15F79) Archived-At: Subject: Re: [dmarc-ietf] Any outstanding issues on 7601bis? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 19:52:43 -0000 7601bis looks good for WGLC Tim =46rom my high tech gadget > On Jul 11, 2018, at 23:22, Scott Kitterman wrote: >=20 >=20 >=20 >> On July 12, 2018 12:20:39 AM UTC, John Levine wrote: >> In article <2940516.WEBi8fTYBz@kitterma-e6430> you write: >>> Is the list of EAI affected components of the field complete? As an >> example,=20 >>> sometimes email addresses are used for SMTP Auth user IDs (or >> sometimes just=20 >>> the local part). I don't know a lot about EAI, but it seems to me >> that most=20 >>> any field might have to contain UTF-8 now? =20 >>=20 >> Any field that is a domain name or an e-mail address can be UTF-8 in >> an EAI message. >=20 > Thanks. It's probably better to say that explicitly rather than list out a= few of the possibilities. =20 >=20 > Scott K >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Thu Jul 12 15:27:17 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED30C1311ED for ; Thu, 12 Jul 2018 15:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nq_vuddnMqDm for ; Thu, 12 Jul 2018 15:27:11 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 391141311E8 for ; Thu, 12 Jul 2018 15:27:11 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id 16-v6so9019406itl.5 for ; Thu, 12 Jul 2018 15:27:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=amX5NYBnwMqD9WNYpPBID+efF6LNN5uBF1CAMksTJ3g=; b=rZo5EvI0Hah+C3fYbDO0dhyewzF3gWx8T8ur6BEKlSci685mOEVJQeWcphLYm2NtBO 4lKeaNp6kSnPa9jkUqHX0jUInbgc8z/i2kU6omjrOFj/ZKY1bkgKS7yjgCLq26uwr34V W3uVQHJ2p4ryVQL+jWJiVDEjrOPc4sGruJdcdCK+W6/3a3ggNQkUdze3EJXFxO8gA1v0 L3QvgdvQvr5tDy0lJOw1OwQQc1fIiZSZJwEwu9ZqdH+XaxrtuO6uaTKX/LNM0t9jiZBm 9dl3BBOWER/aeSA6W7S0QSUV2cPURbp+8OmBkagPUqirRpU+Ik2pa14/8mDuQqbE16+L lM/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=amX5NYBnwMqD9WNYpPBID+efF6LNN5uBF1CAMksTJ3g=; b=FnCqT1iyo8sEoJfCgySmaqbiM1/XUND71irikK8CA9j78x5k0qsocWNotsIcLNlf16 IivQUL7tw2Lrh7eb/c0FZNLS8zuCO4YmINt7mMcoRw3t+YGkr6mLFuCIIC8CPmjpD0zb L5XD3lYmeDm6dI3QII6pwYhjYTKwFXyIvBkfil+4bpQ+JWu0YUb2PTvNawjJNhKPh6C1 VOytO8zIMAEP6nEymZ680OQ+v9nd6K/Gq7D3Bmllm4Gv98yLZNiWjopkbura7EFuFXLb UipSwPOVVspZF9H5gyl81aV4y0UQrBj7YL7/J6VJgkJrrlpxJb91EaLi7l8rucOD1y7f f08Q== X-Gm-Message-State: AOUpUlFoVOhgVsAuqp/ErRTspJ1/hVBrEHopQbrPHmPjEv24TLwzauXs rTkSb0opQIBu/bm2FbEtM4qaqpE4sJ48f9Jr7XQsQ+AgAQ== X-Google-Smtp-Source: AAOMgpd4fzx/UlyY/uLObMYvzWVZMzh41aD+UxIkV2eDLk24F3MPsBxokFcZvXEtmXonvLQvtRi3JOAyjxpY5dCnZ94= X-Received: by 2002:a02:238f:: with SMTP id u137-v6mr3313040jau.0.1531434430011; Thu, 12 Jul 2018 15:27:10 -0700 (PDT) MIME-Version: 1.0 References: <96be85f9-dd0e-4259-47f4-2e7c425c404c@bluepopcorn.net> <968bd954-34a8-05ed-ceec-d4274107a773@bluepopcorn.net> In-Reply-To: From: Brandon Long Date: Thu, 12 Jul 2018 15:26:57 -0700 Message-ID: To: Jim Fenton Cc: "Murray S. Kucherawy" , dmarc@ietf.org, "Kurt Andersen (b)" Content-Type: multipart/alternative; boundary="0000000000003341bf0570d4ddd3" Archived-At: Subject: Re: [dmarc-ietf] ARC protocol-15 posted X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 22:27:15 -0000 --0000000000003341bf0570d4ddd3 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 11, 2018 at 5:38 PM Jim Fenton wrote: > On 7/11/18 5:15 PM, Brandon Long wrote: > > DKIM-Signatures are also sometimes removed from messages (mailing lists > often do this), and there are also MTAs which incorrectly make assumptions > about how DKIM-Signature failure means (the RFC says a failed > DKIM-Signature should be treated as if it's not there, but that's not what > we're seeing in practice). Earlier instances of the AMS are expected to > fail if the message content is changed and for that to be fine. > > We did spend a bunch of time, maybe before it even came to the IETF, > exploring whether we could do this without having a separate set of header > fields, and we decided no. > > > So essentially we're creating a bunch of header bloat (creating duplicate > header fields with different names where that could be avoided) because > there are some MTAs that did not follow the specifications before. That > makes me unhappy, but what matters here is not the behavior of all MTAs, > it's the behavior of MTAs implementing ARC (that include instance number > tag/value). If there's an MTA in the middle that deletes DKIM-Signature, > it's not implementing ARC and the chain is broken. > Note that ARC is designed so that non-participating relays which don't break the latest AMS don't break the chain. Not that I expect there are many relays which will delete a DKIM-Signature and not otherwise break the AMS, though. Also, the chain is added by the relays. The DKIM-Signature means an authority is verifying that a message was sent by them, and not having the concept of instances, there is no way to know to show the difference between relaying the message and sending the message. Ie, google.com is certainly not going to DKIM-Sign a message from a third party, that would imply authentication of the message as being google.com. We have code in google groups to only sign outgoing messages if the original message was authenticated, and even then, it means we sign things we probably shouldn't. We've even debated having a separate set of outbound smtp servers to be used for that type of mail so they won't "gain" SPF authentication on the relay. AMS is different, it only indicates that the message transited the relay, and only authenticates the ARC payload (the AAR header). We actively use the ARC chain now to prevent assigning sender authentication to relays. Also also, bloat wise, it's the same. DKIM-Signature is added by the sender, AMS is added by the relays. Even if ARC used DKIM-SIgnature, we'd still be adding them on the relays, and they'd be similar in size. Also, if we added the instance concept to DKIM, we are basically creating DKIM v=2, which opens up the whole can of worms of whether or not there is any benefit of versioning in some attempt at backward compatibility. We'd probably need to make it v=2 based on what is being authenticated. During the discussion about whether or not AS was useful, I did point out that if bloat was the issue, we could rejigger the AMS/AS to have a single signature by having AMS just have a hash and AS then signing the AMS. No one thought the change was worthwhile. As for the A-R header, I'd more say that A-R was designed for a very simple purpose, to pass auth results from the inbound gateway to the end user client or server. That use case is more easily subsumed by the AAR than the reverse, because of the limitations and implementations of the A-R header as designed. Trying to extend A-R runs into the same issues where the chain will break on non-participating relays, and that hole I expect to be a larger consideration. Brandon --0000000000003341bf0570d4ddd3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed= , Jul 11, 2018 at 5:38 PM Jim Fenton <fenton@bluepopcorn.net> wrote:
=20 =20 =20
On 7/11/18 5:15 PM, Brandon Long wrote:
=20
DKIM-Signatures are also sometimes removed from messages (mailing lists often do this), and there are also MTAs which incorrectly make assumptions about how DKIM-Signature failure means (the RFC says a failed DKIM-Signature should be treated as if it's not there, but that's not what we're= seeing in practice).=C2=A0 Earlier instances of the AMS are expected to fa= il if the message content is changed and for that to be fine.

We did spend a bunch of time, maybe before it even came to the IETF, exploring whether we could do this without having a separate set of header fields, and we decided no.

So essentially we're creating a bunch of header bloat (creating duplicate header fields with different names where that could be avoided) because there are some MTAs that did not follow the specifications before. That makes me unhappy, but what matters here is not the behavior of all MTAs, it's the behavior of MTAs implementing ARC (that include instance number tag/value). If there's an MTA in the middle that deletes DKIM-Signature, it's = not implementing ARC and the chain is broken.
Note that ARC is designed so that non-participating relays whi= ch don't break the latest AMS don't break the chain.

=
Not that I expect there are many relays which will delete a DKIM= -Signature and not otherwise break the AMS, though.

Also, the chain is added by the relays.=C2=A0 The DKIM-Signature means an= authority is verifying that a message was sent by them, and not having the= concept of instances, there is no way to know to show the difference betwe= en relaying the message and sending the message.

I= e, google.com is certainly not going to D= KIM-Sign a message from a third party, that would imply authentication of t= he message as being google.com.=C2=A0 We = have code in google groups to only sign outgoing messages if the original m= essage was authenticated, and even then, it means we sign things we probabl= y shouldn't.=C2=A0 We've even debated having a separate set of outb= ound smtp servers to be used for that type of mail so they won't "= gain" SPF authentication on the relay.=C2=A0

= AMS is different, it only indicates that the message transited the relay, a= nd only authenticates the ARC payload (the AAR header).=C2=A0=C2=A0= =C2=A0We actively use the ARC chain now to prevent assigning sender = authentication to relays.

Also also, bloat = wise, it's the same.=C2=A0 DKIM-Signature is added by the sender, AMS i= s added by the relays.=C2=A0 Even if ARC used DKIM-SIgnature, we'd stil= l be adding them on the relays, and they'd be similar in size.

Also, if we added the instance concept to DKIM, we are bas= ically creating DKIM v=3D2, which opens up the whole can of worms of whethe= r or not there is any benefit of versioning in some attempt at backward com= patibility.=C2=A0 We'd probably need to make it v=3D2 based on what is = being authenticated.

During the discussion about w= hether or not AS was useful, I did point out that if bloat was the issue, w= e could rejigger the AMS/AS to have a single signature by having AMS just h= ave a hash and AS then signing the AMS.=C2=A0 No one thought the change was= worthwhile.

As for the A-R header, I'd more s= ay that A-R was designed for a very simple purpose, to pass auth results fr= om the inbound gateway to the end user client or server.=C2=A0 That use cas= e is more easily subsumed by the AAR than the reverse, because of the limit= ations and implementations of the A-R header as designed.=C2=A0 Trying to e= xtend A-R runs into the same issues where the chain will break on non-parti= cipating relays, and that hole I expect to be a larger consideration.
=

Brandon
--0000000000003341bf0570d4ddd3-- From nobody Sun Jul 15 11:04:57 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3BE130ECD; Sun, 15 Jul 2018 11:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aYl2jxKQM7Y; Sun, 15 Jul 2018 11:04:53 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AA41130EC8; Sun, 15 Jul 2018 11:04:53 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id p4-v6so17782979itf.2; Sun, 15 Jul 2018 11:04:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=Izz8R0M6xm1LjPYJh5APM9jSZ891s2+AD2tVBv0jqOw=; b=ck1rrW5LxnucOt/BG5DuC4XweJ3gRixDSFFIhGvmIbbZVSu8qyjaS30ZWlv/F3RAtw zFvtmEQCy8DZXfM/EpQlKBBzcQj0OAt3HKRYPc+/dvZT4zTjctxbns7gZN9xGgUp60Yh WmwPkgVDAm6PTF2Itoz6TZXuYiyCH3SP8OJGSGOha1DM5NFj5/Rz+zl6VljVllJZwb2b UfzKtRXb2CnvXxMHiKH69PmgAqq71371QAOmr0CJjjU9vZXLwAI20rQ9AuAHIlW/rIjC sDGRe3xCoWxuWx377EjBiYQxdkZAUFhFayWyuaYKo7zLymO/ApS1wAaU2RKpG5AWQniW jBiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc; bh=Izz8R0M6xm1LjPYJh5APM9jSZ891s2+AD2tVBv0jqOw=; b=Qj85gPs3rWUkX+JBgTY4cQ3DTq+O+HMhD1Y6DLm3NNV/FLFKoqjn+4jZnBxVlskKZN z+wvNJ7IkpXuoDQFbW+kpYQcf4fSdJZDprUworA27/Mc/NxzJRP2A5ll4mLA9sy2M27z Bs43ArtwrGJzhZcyIUibW6g+N+GXb1EjRdrUAqbWrTr505Kmp8mElrCA/sHD+9lkcvb9 HNZhmNHj49eKO5PlRsUXbT+4soxIo/+TZu0JmS9+PllTPpYty6UCXG/cCpxmxbMJjJPJ jnSEHsMeBJx3mO2u1vhFMZnXYwi/hnQc4wHmZBhNsYkI/OD1EvIZaLjA1r26I6sd5qIQ LrKA== X-Gm-Message-State: AOUpUlEketyHYsKnCgmo8FZG0oqk5HJinr1K6rilZ0QkJAQt/XlwDEc6 UbIeLyUKLrng+UndmSLm1rgwHGHEPBR39olS/PtZMy7L X-Google-Smtp-Source: AAOMgpe4nwSmPN7HxleyxGcBijWm0D2agsiFgshdLUp83HNMofqCota6D+fTPi3ykJQuMGJKVByDQBA6Bwc8GfiVW/8= X-Received: by 2002:a24:7910:: with SMTP id z16-v6mr11190025itc.15.1531677892360; Sun, 15 Jul 2018 11:04:52 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 2002:ac0:8e88:0:0:0:0:0 with HTTP; Sun, 15 Jul 2018 11:04:51 -0700 (PDT) From: Barry Leiba Date: Sun, 15 Jul 2018 14:04:51 -0400 X-Google-Sender-Auth: S3gub_2ChM9nSCND3vJ9yAZLFo0 Message-ID: To: dmarc@ietf.org Cc: draft-ietf-dmarc-rfc7601bis@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [dmarc-ietf] WGLC on draft-ietf-dmarc-rfc7601bis-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2018 18:04:55 -0000 So begins Working Group Last Call (WGLC) on draft-ietf-dmarc-rfc7601bis-02. Please review the latest version: https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/ ... and send comments to the DMARC working group mailing list by 3 August. If you review it and think it's ready to go and you have no comments, please post that as well. -- Barry, DMARC chair From nobody Sun Jul 15 11:27:45 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34A05130DD0 for ; Sun, 15 Jul 2018 11:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r99-h5o1Xaq7 for ; Sun, 15 Jul 2018 11:27:42 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEA5C128CF3 for ; Sun, 15 Jul 2018 11:27:42 -0700 (PDT) Received: from dhcp-84ae.meeting.ietf.org ([IPv6:2001:67c:370:128:24f4:646f:72e1:4110]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id w6FIRcM4028407 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sun, 15 Jul 2018 11:27:41 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1531679262; bh=+qkNRIZdxwhg6JrI6ZEYQ4vIKP+G9qHXH+MqV3PAS0o=; h=Subject:To:References:From:Date:In-Reply-To; b=sjsu49WgIOFDAQ5TS23jrtR6zchb3FeVJigp+8D6KkgnvMZEhn43Q6eiBhKikN9LX CLlWHW8QPcebzQ2QbQDEFtpkyElX4VmJbIcWuMQvCnZSyhOKc73IQA5a6Zu6qXwmpV JyzPo6Xacy+jbwxxCbh7Y/k3sIEKnpXb+IE410VQ= To: dmarc@ietf.org References: <20180712013919.1E61120020F35F@ary.qy> From: Jim Fenton Message-ID: Date: Sun, 15 Jul 2018 14:27:37 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180712013919.1E61120020F35F@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC protocol-15 posted X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2018 18:27:44 -0000 On 7/11/18 9:39 PM, John Levine wrote: > > The header bloat war was over years ago, and bloat won. See the > headers below from a Hotmail message I just sent to myself. And > remember that most messages have two copies of the contents, one as > text and one as overformatted HTML. I'm not particularly fond of the "everyone else is bloating their message headers, so we'll do more of that" argument. But I'll leave it at that. However, the additional message header fields do require generation and verification. Generating and verifying AAR and AMS signatures requires additional computation (OK, Moore's Law so I shouldn't worry about that) and potentially additional public key retrieval from DNS. Verification of ARC Seals (and determining the oldest-pass value, if that is done) will probably require different public keys for each, which will probably create more DNS requests and may insert more latency as those responses are received. I suggest that as part of WG Last Call that the DNS Directorate be consulted, largely to socialize this with them so they aren't surprised by the request load requirements. -Jim From nobody Mon Jul 16 06:17:25 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C80B130DD7 for ; Mon, 16 Jul 2018 06:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BI1VQI8JoW_o for ; Mon, 16 Jul 2018 06:17:21 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89F79127AC2 for ; Mon, 16 Jul 2018 06:17:20 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id q127-v6so29322173ljq.11 for ; Mon, 16 Jul 2018 06:17:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Zm+yqEwCn0TMEFHn/Kl1XKWcL5h5lF/DoLbMYz4biRY=; b=N6hzjG+iUUrUl29b3Abz4mkVEcpxtVm5zmU7yYjswruUlKJ23zCFOLZDPal0CfcF3r gjOwXx5psu/BgFyBaUiAAAjb29t1QXqQKGGEb5aeVI1SOQ5qRHRMETPlq9mDY+giM7b6 +NKR5reEcxw/n74gNQ80Fei+rEPgedPCZj5SnNNkqri/Iih4JjOMzbuTffE+qsrnNggk UIk1Yp5a5+A61YpnFhcSJZerRlfNPy6bG1EsuJmwyASixO8nH4KWy1V7vWM8tw23DMVK 5WjJxyaFBwTvdkaqehQwcOTJsfr0x9MeZAmj5pqjSEGrVYeUeTBSQ1KgxNyLz6vVVe7n Ol8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Zm+yqEwCn0TMEFHn/Kl1XKWcL5h5lF/DoLbMYz4biRY=; b=WLmUtXQKvZgBUBO8V7NCgO1pAInsuxd19csTu2xbN99ykHxn4JlxyUtQrKzy0fxkCI Jhcw/No5eRI4Ac0Nyp5llvs8Xr4wZxXWWgO9AGpVELVw28fC5BBr8IrIElxuWJ3Kjtcf uLjeEkrwtBxV59+o8yM0cW+vB5EnEpGgSBwv/kjhgHLwxJIhFvO65STcFlvUk0xhLsGk tDYjdkdPaj6ph/Mg5nGUv8jThsfzfIhCUpu1PQRPt3oqv7rX/pK5iPqdrhNVYwVosdt3 UbXRrkJXwcXuCJ2Dkl6qIoeATy87VvKSN3JTorPA7x4B32Nrye0VaRzf31senDT6fRMY CYgg== X-Gm-Message-State: AOUpUlHv7P+C/RY2sz4h6foem7yPuhutPDPiEUsF4uwI7Neil5kTl3kQ lPVXtv3l49dbB6JvUFsQPku216OOiL4J5Mb0w//vZQ== X-Google-Smtp-Source: AAOMgpfeXetWrLgfDxO4DL9CiX+/zSbmWa4y9MteDinGTal4ZJgCTCxDoAfdaXAcNM9hGfiBNuxXf+yqvqlHbJColyA= X-Received: by 2002:a2e:4357:: with SMTP id q84-v6mr9868361lja.13.1531747038741; Mon, 16 Jul 2018 06:17:18 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:3a13:0:0:0:0:0 with HTTP; Mon, 16 Jul 2018 06:17:17 -0700 (PDT) In-Reply-To: References: <20180712013919.1E61120020F35F@ary.qy> From: "Murray S. Kucherawy" Date: Mon, 16 Jul 2018 13:17:17 +0000 Message-ID: To: Jim Fenton Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="0000000000002148a905711da6ca" Archived-At: Subject: Re: [dmarc-ietf] ARC protocol-15 posted X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 13:17:23 -0000 --0000000000002148a905711da6ca Content-Type: text/plain; charset="UTF-8" On Sun, Jul 15, 2018 at 6:27 PM, Jim Fenton wrote: > > I suggest that as part of WG Last Call that the DNS Directorate be > consulted, largely to socialize this with them so they aren't surprised by > the request load requirements. > Should the draft say more than what Section 9.2 already says? -MSK --0000000000002148a905711da6ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Jul 15, 2018 at 6:27 PM, Jim Fenton <fenton@= bluepopcorn.net> wrote:

I suggest that as part of WG Last Call that the DNS Directorate be consulte= d, largely to socialize this with them so they aren't surprised by the = request load requirements.

Should the draft say more th= an what Section 9.2 already says?

-MSK
--0000000000002148a905711da6ca-- From nobody Mon Jul 16 07:07:02 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24CC5130E28 for ; Mon, 16 Jul 2018 07:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGaB4J9LXEHy for ; Mon, 16 Jul 2018 07:06:59 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF772130DFF for ; Mon, 16 Jul 2018 07:06:58 -0700 (PDT) Received: from dhcp-84ae.meeting.ietf.org ([IPv6:2001:67c:370:128:74eb:5154:89c6:4741]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id w6GE6rmu016361 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 16 Jul 2018 07:06:55 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1531750016; bh=9b7uN6eQVzDTlYOg9wvfzw0Lkin1Rj+m1gRO1IA120I=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=EBg0lPSbI53ElFGAkezNdS8i2dX86TVF9BbgJ2EkIzOdvh41XaXZ3WR8qz5SNOeN7 k0gvPgDETFesx7A04qSCgDdbAJAsMDNWHWLgsHRJD+OB8WVpxZ70r1RxsOjORLSMjM wpVQ5rMWvKXY5Q6hiZ8rX5pVF4Iq3lFWKVHAj+Kw= To: "Murray S. Kucherawy" Cc: dmarc@ietf.org References: <20180712013919.1E61120020F35F@ary.qy> From: Jim Fenton Message-ID: Date: Mon, 16 Jul 2018 10:06:52 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8C39F4E615B127BA992A1E86" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC protocol-15 posted X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 14:07:00 -0000 This is a multi-part message in MIME format. --------------8C39F4E615B127BA992A1E86 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 7/16/18 9:17 AM, Murray S. Kucherawy wrote: > On Sun, Jul 15, 2018 at 6:27 PM, Jim Fenton > wrote: > > > I suggest that as part of WG Last Call that the DNS Directorate be > consulted, largely to socialize this with them so they aren't > surprised by the request load requirements. > > > Should the draft say more than what Section 9.2 already says? 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 consulting the DNS directorate, it would be good to mention the operational impact of 9.2. I also wonder if it would be helpful to mitigate the operational impact by saying that AS SHOULD use the same selector as the associated AMS. -Jim --------------8C39F4E615B127BA992A1E86 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit On 7/16/18 9:17 AM, Murray S. Kucherawy wrote:
On Sun, Jul 15, 2018 at 6:27 PM, Jim Fenton <fenton@bluepopcorn.net> wrote:

I suggest that as part of WG Last Call that the DNS Directorate be consulted, largely to socialize this with them so they aren't surprised by the request load requirements.

Should the draft say more than what Section 9.2 already says?

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 consulting the DNS directorate, it would be good to mention the operational impact of 9.2.

I also wonder if it would be helpful to mitigate the operational impact by saying that AS SHOULD use the same selector as the associated AMS.

-Jim

--------------8C39F4E615B127BA992A1E86-- From nobody Mon Jul 16 09:56:42 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54FDF130E3A for ; Mon, 16 Jul 2018 09:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLYjALYKwUmf for ; Mon, 16 Jul 2018 09:56:38 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDD18130E1E for ; Mon, 16 Jul 2018 09:56:37 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id k81-v6so76062063oib.4 for ; Mon, 16 Jul 2018 09:56:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OX0nOxmPvPgYE+Ycg3FSmp1WAkKeu74AXFZLkkoV2kE=; b=G5k08ZCjT5netqruppP7SHeHEpVE8KlBaDzVu9KTn0AJfJn/umFYjVyvj7xReiJ+9B hjkA8ijPuBUURDlR+7eNtkgP1g3HV9F5HcwuakXptgQuyEU8UaRGROeaHVnlg9I7975V K72bJzqVJAX23ST1JN8adXPwJuQTwLZsxYWsAE3vWmLB4mFDbmjyZyz/4XPw/x2MVpT1 fOnTNdX+r0GpnRqU94L7YwUt57aIOnU5DUoX/9/Ac8NaPAYc/rP13YHwL2gpMbjIKzt5 rErqxlBfjGdKTYbxQQsIZOpNqM0Jjw+kBp7UVPBTQLyJ1aKOUxx4gmrDUtksgDEzrWhZ 4u6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OX0nOxmPvPgYE+Ycg3FSmp1WAkKeu74AXFZLkkoV2kE=; b=HqPDDcXR9aPMDV6yTtCFecDsYxHIZmMyCkogBbnu79HiKu+yV1hUqanTh0ywPHRd4c QbWrDTR4fifbAXr/nyfSEZWUsRNoMztWOhQqVSuQgFWdkdXkRabktK61RlPXm9/co0/z QwHLmKfaiFNn3Mmt94tAmDOITZC9yFvRHnJVVsfNpQMrSn8aSsA6HOgPNMP3b7jNQ0v8 8kPH3uD8HcHULNo6U4qt5E/C+pgA95m80K2+Slca5FnvjLqLE6q6ZSe6I1VCFz7yrNR2 Qk7QO/uhzB7RLmGDn3a9MjxXJEcKtrHyoF62gB5oMsnixXRIhG4e3uxE/l3/sPjZDv/c BPHw== X-Gm-Message-State: AOUpUlGgSozEqXHN6TmK0vkg7uiBBUHr/8hPmtLou0M68sxx+woj2+vL nZ08z23IzeeFNFnv6oNQqW83z+nl2YrVTwlDCEJ3lsjq X-Google-Smtp-Source: AAOMgpfye9wbk6UeRaqQn5dHFJAUVFBBF9iLknDWKspYYDP7ed5TkX11PFHuy7EKJoMwyfIU2Mr7iNEiw41iKLttoM0= X-Received: by 2002:aca:3d05:: with SMTP id k5-v6mr141030oia.86.1531760196865; Mon, 16 Jul 2018 09:56:36 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:2646:0:0:0:0:0 with HTTP; Mon, 16 Jul 2018 09:56:16 -0700 (PDT) In-Reply-To: References: From: Seth Blank Date: Mon, 16 Jul 2018 09:56:16 -0700 Message-ID: To: dmarc@ietf.org Cc: draft-ietf-dmarc-rfc7601bis@ietf.org Content-Type: multipart/alternative; boundary="0000000000006a6d51057120b65e" Archived-At: Subject: Re: [dmarc-ietf] WGLC on draft-ietf-dmarc-rfc7601bis-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 16:56:41 -0000 --0000000000006a6d51057120b65e Content-Type: text/plain; charset="UTF-8" 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) between the current text in 2.3 and what's in 2.3 of 7601. The text is supposed to be loosened so things like smtp.client-ip and arc.oldest-pass info for ARC A-R stamps are allowable in the registry. 2) Typo: Section 2.2 references "sob-domain" Final thought: the inclusion of authres-payload as inheritable ABNF and the addition of EAI language in this update will be both quite valuable. I'm looking forward to seeing this published. Seth On Sun, Jul 15, 2018 at 11:04 AM, Barry Leiba wrote: > So begins Working Group Last Call (WGLC) on draft-ietf-dmarc-rfc7601bis-02 > . > > Please review the latest version: > https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/ > .... and send comments to the DMARC working group mailing list by 3 August. > > If you review it and think it's ready to go and you have no comments, > please post that as well. > -- > Barry, DMARC chair > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --0000000000006a6d51057120b65e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've reviewed. All the technical matters look good, an= d 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) between the current text in 2.3 and what&#= 39;s in 2.3 of 7601. The text is supposed to be loosened so things like smt= p.client-ip and arc.oldest-pass info for ARC A-R stamps are allowable in th= e registry.

2) Typo: Section 2.2 references "= sob-domain"

Final thought: the inclusion of a= uthres-payload as inheritable ABNF and the addition of EAI language in this= update will be both quite valuable. I'm looking forward to seeing this= published.

Seth
<= br>
On Sun, Jul 15, 2018 at 11:04 AM, Barry Leiba= <barryleiba@computer.org> wrote:
So begins Working Group Last Call (WGLC) on draft-ietf-dmarc-= rfc7601bis-02.

Please review the latest version:
https://datatracker.ietf.org/doc/d= raft-ietf-dmarc-rfc7601bis/
.... and send comments to the DMARC working group mailing list by 3 August.=

If you review it and think it's ready to go and you have no comments, please post that as well.
--
Barry, DMARC chair

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

--0000000000006a6d51057120b65e-- From nobody Mon Jul 16 10:00:19 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3A7130E1E for ; Mon, 16 Jul 2018 10:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8qxQIXKJrbi for ; Mon, 16 Jul 2018 10:00:16 -0700 (PDT) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0685B130EA7 for ; Mon, 16 Jul 2018 10:00:16 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id i20-v6so17475646eds.12 for ; Mon, 16 Jul 2018 10:00:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=EG74K9UFgiJqA0nx/FOifLYBcbQ3AATr3xu+x6lULrw=; b=fU6gD5uJYz/A1zTpzPAcAOp6r3yRITL2GA63n7Hfe44CvgMJX5i9x4M2o0NwIvFpGG UZ0XooU0VQ1ouS8hOwzm20hF6nLiUIrjGGBhZ7lXrsk0vA2jverSSddnLgXUxpqFdShn 2bM9+OrVe+orNKGf+YgAxASuYdE7rNdp6xlsk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=EG74K9UFgiJqA0nx/FOifLYBcbQ3AATr3xu+x6lULrw=; b=YMVtWZ5wM+vhlEHA8cwIGcMLpSp/Yuzl+h3zKY8ZjVvrAG7oHhjRTYidwfU1WJsQhg w5OhyJjuKvWiadYRjSfRmAkU18P2oQag/FaKhCQ4FoPY4c5dK9k5LqoAiFefrVAJtcEX z+ZqK+3KKqT4avzpxQBhSTkPWF0QE8mj2ShwthFkAvtCqs2Nh5466kMYuqbQIjGakxY6 KUMQpfflQb1EpCl+eHDlepfnOBsfeDoxG5bbO9Wv2e92YZJdsI9PK/o3qzxrgUmi82EC m4qe9zC1JJk9FSSfrKYnG2y+9cKw7lYZUJ0Rdnq1HV4e6dH8qNsz59KH3OdTagvMrUdZ ImOg== X-Gm-Message-State: AOUpUlFgE4ZDJp2/xaR4Kss5FPus4w21S+6qcZv6v/QWNfN7XJQrrIrU ZwcCF+qP3faxWvcS1nULmn7Hy+llsbs3R/6k2WnRcg== X-Google-Smtp-Source: AAOMgpfYrkxKX0ADLKIqR62Cu2S7HjBPAhUtW4NY5MUUDM8fyUpBoH6BT2r8ohn0U0tZLa8kdSCfAWIKxfPygV7TFK4= X-Received: by 2002:a50:a7e2:: with SMTP id i89-v6mr17462096edc.176.1531760414502; Mon, 16 Jul 2018 10:00:14 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 2002:aa7:da87:0:0:0:0:0 with HTTP; Mon, 16 Jul 2018 10:00:13 -0700 (PDT) In-Reply-To: References: <20180712013919.1E61120020F35F@ary.qy> From: "Kurt Andersen (b)" Date: Mon, 16 Jul 2018 10:00:13 -0700 X-Google-Sender-Auth: 4WVCJZqjfAfHzgFgk3ds0V5HW9c Message-ID: To: Jim Fenton Cc: "Murray S. Kucherawy" , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006340e2057120c300" Archived-At: Subject: Re: [dmarc-ietf] ARC protocol-15 posted X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 17:00:19 -0000 --0000000000006340e2057120c300 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 16, 2018 at 7:06 AM, Jim Fenton wrote: > On 7/16/18 9:17 AM, Murray S. Kucherawy wrote: > > On Sun, Jul 15, 2018 at 6:27 PM, Jim Fenton > wrote: > >> >> I suggest that as part of WG Last Call that the DNS Directorate be >> consulted, largely to socialize this with them so they aren't surprised by >> the request load requirements. >> > > Should the draft say more than what Section 9.2 already says? > > > 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 consulting the DNS directorate, it would be good to > mention the operational impact of 9.2. > > I also wonder if it would be helpful to mitigate the operational impact by > saying that AS SHOULD use the same selector as the associated AMS. > I would be opposed to adding the suggestion of this sort of restriction on the basis of hypothetical load impacts. --Kurt --0000000000006340e2057120c300 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Jul 16, 2018 at 7:06 AM, Jim Fenton <fenton@bluepopcorn.net&g= t; wrote:
=20 =20 =20
On 7/16/18 9:17 AM, Murray S. Kucherawy wrote:
=20
On Sun, Jul 15, 2018 at 6:27 PM, Jim Fenton <f= enton@bluepopcorn.net> wrote:

I suggest that as part of WG Last Call that the DNS Directorate be consulted, largely to socialize this with them so they aren't surprised by the request load requirements.

Should the draft say more than what Section 9.2 already says?

 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 consulting the DNS directorate, it would be good to mention the operational impact of 9.2.

I also wonder if it would be helpful to mitigate the operational impact by saying that AS SHOULD use the same selector as the associated AMS.

I would be oppose= d to adding the suggestion of this sort of restriction on the basis of hypo= thetical load impacts.

--Kurt=C2=A0
--0000000000006340e2057120c300-- From nobody Mon Jul 16 11:38:20 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 640F2130FD9 for ; Mon, 16 Jul 2018 11:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUj4rdLfXfFv for ; Mon, 16 Jul 2018 11:38:12 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 507F9130E74 for ; Mon, 16 Jul 2018 11:38:12 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id l10-v6so30007138oii.0 for ; Mon, 16 Jul 2018 11:38:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=kLiiof+j/KRJbHW8y2+nHQYyGo4fGRdTPB8194sCdLk=; b=wzPuvB6AyfGLUmwFBS9NcMVbG0gac/p3fRexhH2J9lrBkO+beImAZmQtTM3+xxcZa1 IkYU9rL+y0UNszoSAlxfjew0hSa//eo3svzzPCkRLTn8S6AinRlWhYgDfIS78UT9PTXa +OmXmiAu+o2FyXHDYs0wKfZ8XKSloUMFjW0Fz2thJbIT0Gu+hNKmFH13upC5EZ4GY6zs W21b/cfkh9Dgn1KVv4lXk+kWcJ/lLhxyM6n5+6fZJ252cJFnnqX0IOYUHzRQZU0QiFNK wtNJ/8heuyCukpWE5gVulzHmseo/KU1FaGPpD5QEQSEKdOsyzm7S85Rpjcud4LX+onfV GeUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=kLiiof+j/KRJbHW8y2+nHQYyGo4fGRdTPB8194sCdLk=; b=QUt/p1OX7FyX4a05JKBW0f801UU+C+m6FajlyMCNCoMzhzFK1vfY/ypw1wNlahPkaj X+Bx/0vr2Emlr2P3le6dvWjgP1puJ4EIwWR4VLqfrwMHX2g29kDTqJxuWHE6x7UJV3i2 kky7BgIVRXHsT1JGXiKzY/jN+K+dZIMKb+sYZUP1E/abTDbDInfm0t5Wp2TwtPVHrDK8 TnCXWXDyUR5gVFA1eD3mDdxYuLEnqNnLTm3pCP0Q54oHuxeCQQt4UDy5wQF1x626bI9A WgL8qYk90EIvbxmzu4GXyM3avjfgmUiNFw+Si26uGW1r0n+AxWjh8fI/YZc8Oyu2bh4J GoPg== X-Gm-Message-State: AOUpUlH/tL8ui9h7KLhSfuY2rCe/LSelGWGWRrTMKXbZkjYWowWFr7Rf bX6FwMSNKyTOVZ86P9pRj8Jp8bRsEnckdwY6KDtLxm2DTSw= X-Google-Smtp-Source: AAOMgpcKpziO8PuTgAqKnwHxpCZPU9VL1cZDtmn5CtycJSUvsHjwawWSJxbCGY9xciiJHpgZ8xAbQrpinBVEVwEQBHI= X-Received: by 2002:aca:b954:: with SMTP id j81-v6mr528839oif.356.1531766291218; Mon, 16 Jul 2018 11:38:11 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:2646:0:0:0:0:0 with HTTP; Mon, 16 Jul 2018 11:37:50 -0700 (PDT) In-Reply-To: References: <20180712013919.1E61120020F35F@ary.qy> From: Seth Blank Date: Mon, 16 Jul 2018 11:37:50 -0700 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="000000000000aadbfa05712221a9" Archived-At: Subject: Re: [dmarc-ietf] ARC protocol-15 posted X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 18:38:17 -0000 --000000000000aadbfa05712221a9 Content-Type: text/plain; charset="UTF-8" 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 consulting the DNS directorate, it would be good to > mention the operational impact of 9.2. > > I also wonder if it would be helpful to mitigate the operational impact by > saying that AS SHOULD use the same selector as the associated AMS. > This has also been discussed several times on list, here's one such: https://mailarchive.ietf.org/arch/msg/dmarc/XfS4UnLPrMbIhTvjYjmsYrcj_HA Where this reach consensus (and it wasn't in the referenced thread, but I couldn't find it after a brief search), was that no one had any technical reason for a MUST or even a SHOULD in the spec, and that ultimately this is matter of usage. So the usage guide should say that AMS and AS d=/s= should match UNLESS you have a good reason to do otherwise, as receivers will most likely treat it as suspicious if they don't. We could see a clear example where the ARC Seal is signed by the organizational entity, and the ARC Message Signature is signed by the service. For instance, AS d=example.org, and AMS d=examplelists.org. This translates to my ADMD takes overall responsibility for handling this message, and this service within made a breaking change. This seemed to be something that would become clear through the Experiment, if everyone used the same key for both, then we could simplify the specl. But if using separate keys ended up being valuable, and didn't create a meaningful increase in DNS overhead, there was no reason to prohibit it before seeing where the chips fell. --000000000000aadbfa05712221a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Jul 16, 2018 at 7:06 AM, Jim Fenton <fenton@bluepopcorn.net&g= t; wrote:
=20 =20 =20
9.2 describes the problem, but it's expresse= d 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 consulting the DNS directorate, it would be good to mention the operational impact of 9.2.

I also wonder if it would be helpful to mitigate the operational impact by saying that AS SHOULD use the same selector as the associated AMS.

This has also bee= n discussed several times on list, here's one such:=C2=A0https= ://mailarchive.ietf.org/arch/msg/dmarc/XfS4UnLPrMbIhTvjYjmsYrcj_HA

Where this reach consensus (and it wasn't in the r= eferenced thread, but I couldn't find it after a brief search), was tha= t no one had any technical reason for a MUST or even a SHOULD in the spec, = and that ultimately this is matter of usage. So the usage guide should say = that AMS and AS d=3D/s=3D should match UNLESS you have a good reason to do = otherwise, as receivers will most likely treat it as suspicious if they don= 't.

We could see a clear example where the ARC= Seal is signed by the organizational entity, and the ARC Message Signature= is signed by the service. For instance, AS d=3Dexample.org, and AMS d=3Dexampl= elists.org. This translates to my ADMD takes overall responsibility for= handling this message, and this service within made a breaking change.

This seemed to be something that would become clear t= hrough the Experiment, if everyone used the same key for both, then we coul= d simplify the specl. But if using separate keys ended up being valuable, a= nd didn't create a meaningful increase in DNS overhead, there was no re= ason to prohibit it before seeing where the chips fell.
=C2=A0
--000000000000aadbfa05712221a9-- From nobody Mon Jul 16 12:19:09 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 777591311B5 for ; Mon, 16 Jul 2018 12:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=olZ57E6Q; dkim=pass (1536-bit key) header.d=taugh.com header.b=mMBwS+h7 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2_liAuKs51Y for ; Mon, 16 Jul 2018 12:18:56 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A82C7130DE6 for ; Mon, 16 Jul 2018 12:18:56 -0700 (PDT) Received: (qmail 72110 invoked from network); 16 Jul 2018 19:18:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=119aa.5b4cef9f.k1807; bh=FLOm7BfMv/PQMlHZ3Vlcw/jjVlX1QNnVpd9VrEmsaPE=; b=olZ57E6QOu4e+Q2tzUIpzKaQYeTGKBnRtG86ndEth99CRcMWBEEezxiuuJlCVAzKCEUp8xTpaeOxdr7Nu77BwK/tLeOjsutaKw4LIziNrxZ3c7TU6/wYQ4/gkpOX9q9z0Czu8l6OMR6Gq8XvHq5TOIzZDKZAvI+qyIXuJWjaAe+8STgvZlbzQzgAKZOx6bB+nKQ0g6X6ds41sGP7di2s41NN0AhoD21M8EAobLJ+ZncpEhS4/4vd7c5UGi3k4Yc7 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=119aa.5b4cef9f.k1807; bh=FLOm7BfMv/PQMlHZ3Vlcw/jjVlX1QNnVpd9VrEmsaPE=; b=mMBwS+h7EaOQLqTLVoxXoPXo0NqQWUyBtD+dMygaxbYYygPF6eT4jBuZJJSdho4LowiOLn43bjPvZa61wnvGxFJBQG2dfNdYuJQirESZMWEgFeFaAovhqTqVMIENqfZ9nmjYjTG8uv4ydiEGQX35u6Zvv8iqL1kghS0GTVR1i90AXAus9rJ4pp5j36LlibUUZ3tbT0SljjDrrneM5eY2XwzK32Qke8f2fHzD6WJdve1qpplBivyjMfAD8brUD0Fw Received: from dhcp-85af.meeting.ietf.org ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 16 Jul 2018 19:18:55 -0000 Received: by dhcp-85af.meeting.ietf.org (Postfix, from userid 501) id 1E17E200257719; Mon, 16 Jul 2018 15:18:54 -0400 (EDT) Date: 16 Jul 2018 15:18:54 -0400 Message-Id: <20180716191855.1E17E200257719@dhcp-85af.meeting.ietf.org> From: "John Levine" To: dmarc@ietf.org Cc: kboth@drkurt.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] ARC protocol-15 posted X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 19:19:05 -0000 In article you write: >> 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 consulting the DNS directorate, it would be good to >> mention the operational impact of 9.2. >> >> I also wonder if it would be helpful to mitigate the operational impact by >> saying that AS SHOULD use the same selector as the associated AMS. > >I would be opposed to adding the suggestion of this sort of restriction on >the basis of hypothetical load impacts. I agree with Kurt here. I would be astonished if the extra load of ARC lookups were even noticable other than in contrived scenarios. In typical mail systems, every incoming message provokes a blizzard of DNS lookups in DNSBLs for IP addresses and envelope domains, SPF, DKIM keys, checking whether envelope and header address domains exist, and DNSBL lookups up of every domain name in message bodies. ARC is a very slim straw on the back of this particular camel. I do weird DKIM signatures where every signature has a different selector, often with several signatures per message, and the DNS load is still trivial. R's, John From nobody Mon Jul 16 13:02:11 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C594130E6D for ; Mon, 16 Jul 2018 13:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lKqz9Xz6VPg for ; Mon, 16 Jul 2018 13:02:07 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63448130E4B for ; Mon, 16 Jul 2018 13:02:06 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id p17-v6so23287725itc.2 for ; Mon, 16 Jul 2018 13:02:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=D8P2jQ/tVPsOc2KCg/f3BGRkK9yKkZi3fI5SzkebPXs=; b=Yk1owdqVxZsY+ppzI3tZ6HrElxfl32tn08uoJbeYVmzI8BlD3SL0Bybn6YYjW82vKX R09bUU7x4Uz9Vkcyl3vks6B/bNZY+zMlr6tWcIYOVoX4CIZ/vSSGjyE/3UpJhvAz7hmv pdlL4rCEKhJsCJqu0B/poARPaoXOly98cTRi3aHpzQoPKXm2lKLAvngsstS6+fQjmEdN O5ldSKOOCnthjZNMmG9Eiu+uoxX2QRGWgGccoZ+9z59615neiOVRyfUPgxvm/KZUH72m YAbIyAmJI3JRnGpeKQjCEeYxVm2ANwCCpryLTMU1510CkcYeRv01+u7fjb8twLtuJqHz TPzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=D8P2jQ/tVPsOc2KCg/f3BGRkK9yKkZi3fI5SzkebPXs=; b=djvmWYwTKQz7HerjSlcniW1ARFx0c1Jw5TEocdDEPVMcNxBTqgQMytVqEYDs2U55JF TCy+e2U3QT2nxhYBTFY1wFQtBbCRWv05j7dL9/Y/rVUQsTGcSkEZcVhbjwO7uVh9B8Ui bGjIWKihWYoe3+nuPLcPilT2UCA8gS0uWFE75UKlRKi9MbvytOYKdg9QlbdtCuVA0m+0 GXlh76MKKRdep5HiGr7uPElFzIbt7vfYNiuBlXuk3UVPBTYwVqj4dVleUh//wyOeOwar IgwXSqX+a5dx2PoMjy/fxUQObfLXhBxO2U723TVjnAij/I1sKznh0KX97eCu+TKqXD6B 9o6A== X-Gm-Message-State: AOUpUlEF4qE/Fg/2Do+l8hkXdmtyU3CrTyQq4QVtuVRo94XWFnsbq9KV cTyUjmJkpO6l1qRv76UK6g7o5XbBC5d6rA9BvJ9/TQ== X-Google-Smtp-Source: AAOMgpcHSiSAeDjMAO3H9gIR0CBJZNnl5G+YOl+VZ43Te3R2JDWThng6oS0oZr7D9bNIuG1QtDC1531yfzNG2oaXyI8= X-Received: by 2002:a02:9b9c:: with SMTP id p28-v6mr14756088jak.28.1531771325159; Mon, 16 Jul 2018 13:02:05 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 2002:ac0:8e88:0:0:0:0:0 with HTTP; Mon, 16 Jul 2018 13:02:04 -0700 (PDT) From: Barry Leiba Date: Mon, 16 Jul 2018 16:02:04 -0400 X-Google-Sender-Auth: GsbGfw0Z0XUHPCC0OdVM37Scr7s Message-ID: To: dmarc@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [dmarc-ietf] WGLC will be on ARC-16 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 20:02:09 -0000 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 From nobody Mon Jul 16 13:10:23 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7BC131203 for ; Mon, 16 Jul 2018 13:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k7dX6S9N55HT for ; Mon, 16 Jul 2018 13:10:08 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0927B1311D9 for ; Mon, 16 Jul 2018 13:10:08 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id q12-v6so34007014qtp.6 for ; Mon, 16 Jul 2018 13:10:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=VBcs7OlCL+8M/JaWFY86wUud01KOBM8SEVF/HXBC0d8=; b=HbVI5k1yuP5aiitd5ie0/kUu6t/NZcvzmuLLOTug7NqdHWZFDdx5NhQLJ54SgDygA8 PIw5pAWRnRNkPa6LbQUPLFE1llBsF3zOOgOPP9zAGtGkT23kOmBatJL0fItqG4Hv7wrW yfP93rOD98ox2NbmGCZVBHUV+CNHWTitaPJqYW77fmHjdme04vDodDINyCZd3DKQZZZ4 6TZePynT/aRjh49TBxp5JALCM2B+3zJHxiRl8p1KhvLpapN5ZSWRTnTjUiPdZDMp6Q73 WzjHc0EwdG2zv1BVBGwWwsnmC9D+KY8voeoZN9Ft8rdjoyvPuTehHODs0F+IZ267DWWu vdXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=VBcs7OlCL+8M/JaWFY86wUud01KOBM8SEVF/HXBC0d8=; b=gQiw6pow6/oHjquYdL1PW6A+aood2CSDsq9RLNbjTaXXCb83jo08jngCYKhmwgNvlE BRDqzJWJwJErYrzXbHpp1KG3iCLqnuWQ1V6IM4Gck8S6jvNbg+QpJWgdCn0og7IC2j+Q 8ub2cJQgqtiWNY2H7iHXezrgeNCMi4As1BrwDgL4Y0NIuvO/pxgD59RhZsust+hLawyt fVc+fA+S3C2FbLEU6uF+Tk9vlwbr21YliMriGfohpdyOrUmTuOT5q4QJsM5wif90v/9h tpgIHsyKI+WoPTL2m8cN6YPzXjOgqwoohfuGeOJQOyQLhQEWBCrrd2+L4cGspnPjFdRn L/sg== X-Gm-Message-State: AOUpUlFv+Rawo+zp2rW8NU8hz7Jio0F1D/OURIO9Ubenr72a1SGwsexN 8yTNkXCz7earG3nbzGLGJJ8Gd5kO7Dp0cLja7eM9ESr9 X-Google-Smtp-Source: AAOMgpf7EFE7vBroIxGv09k72tiq/2MT93C+LGc8PfzgZ43jEi7ZMeplfVc6v9XmCOzw+lAXrVZIyMRGPFaftexuLSM= X-Received: by 2002:ac8:2d8c:: with SMTP id p12-v6mr16366652qta.262.1531771806854; Mon, 16 Jul 2018 13:10:06 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:22e1:0:0:0:0:0 with HTTP; Mon, 16 Jul 2018 13:09:46 -0700 (PDT) In-Reply-To: References: From: Seth Blank Date: Mon, 16 Jul 2018 13:09:46 -0700 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="0000000000006cc19a0571236af3" Archived-At: Subject: Re: [dmarc-ietf] WGLC will be on ARC-16 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 20:10:21 -0000 --0000000000006cc19a0571236af3 Content-Type: text/plain; charset="UTF-8" Excellent, Kurt and I will make sure the notes from the current discussions are accounted for and publish -16. Thank you, Barry. 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. > > 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 > -- Seth Blank | Director of Industry Initiatives E: seth@valimail.com | P: 415.273.8818 --0000000000006cc19a0571236af3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Excellent, Kurt and I will make sure the notes from the cu= rrent discussions are accounted for and publish -16.

Tha= nk you, Barry.

On Mon, Jul 16, 2018 at 1:02 PM, Barry Leiba <= ;barryleiba@co= mputer.org> 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.=C2=A0 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.=C2=A0 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



--

Seth Blank | Director of Industry Initiative= s

E: seth@valimail.com | P: 415.273.8818<= /p>

--0000000000006cc19a0571236af3-- From nobody Mon Jul 16 13:13:10 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 826E7130DC2 for ; Mon, 16 Jul 2018 13:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0NVsmI1vP7F for ; Mon, 16 Jul 2018 13:13:04 -0700 (PDT) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FF64130E42 for ; Mon, 16 Jul 2018 13:13:04 -0700 (PDT) Received: by mail-ed1-x530.google.com with SMTP id o8-v6so3381980edt.13 for ; Mon, 16 Jul 2018 13:13:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Jc00Q/mU+DSbjh0mHinuAy/iXZzFU/CBFC89J2BDNWE=; b=SR+485NeNqvuHu0znvUjt1pcyjHJRRzJarbZ5MMH0BTPoh+5QaBiZ8MOrAyvuNUx+5 Pjx9XIwyBUNVJ9gy1l/9EouhNxGh0B8GMzAX3X532f3/ghF7akUmbfx+zLQ+ePksFGSX 6L90/rbSmz5HG8h+znxTw15K6KY6nRFykAQhg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Jc00Q/mU+DSbjh0mHinuAy/iXZzFU/CBFC89J2BDNWE=; b=cKMAnpKD8VAK+Elh8ZR+3di8hWgK0Mek7CGLQeo1l5uee5F0577ddicJXRIhrxqmHF Mzh7vr6nEEX3fZR5poTWxNgTE/WTpqIqAn5o5URf5LwliPE+OQ/8L0KI75Fm1KU3L27n Y4EwB0ulGgn7NP50fdsfwbYMvMwo79LLDeChw7Mva4EjSaHgi5JlEZaxEnRG9mi6K1Ek a1YUemhet9mIyiaMqfQkgmU6uFZitOi2ktGyhV8mpTRZIbDl7NJ1+/PhQP9fWPr7YwVO mpl1BFHGVtUUJZOXImVDBAExjOXzNU2pgEU58EGZ6M0gtSJkVtY6sI5mFEt/BRnUIrrW NirA== X-Gm-Message-State: AOUpUlESlU0ToocLv3aUzs/Empobt27Qt3UK1BA8B9eLUVzIQDmbnrO8 yUleYmMJw7+znNHMdTFZe30RIv3DOQ3BQnxaL2Pyp9kr X-Google-Smtp-Source: AAOMgpex2nMA9IPwwJjcVMo5ugWX3AzHo6gxrJVl/faAOpUjSzOajg9Flcu5LaG8A6XdocGZhGUlJ8qmctWowQjfxzk= X-Received: by 2002:a50:c251:: with SMTP id t17-v6mr18540350edf.108.1531771982630; Mon, 16 Jul 2018 13:13:02 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 2002:aa7:da87:0:0:0:0:0 with HTTP; Mon, 16 Jul 2018 13:13:01 -0700 (PDT) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Mon, 16 Jul 2018 13:13:01 -0700 X-Google-Sender-Auth: HDdG3hApaYl9Z-hn4Q4PBYJnhKk Message-ID: To: Seth Blank Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e6e8e60571237494" Archived-At: Subject: Re: [dmarc-ietf] WGLC will be on ARC-16 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 20:13:09 -0000 --000000000000e6e8e60571237494 Content-Type: text/plain; charset="UTF-8" Ack - look for it before EOW. --Kurt On Mon, Jul 16, 2018 at 1:09 PM, Seth Blank < seth=40valimail.com@dmarc.ietf.org> wrote: > Excellent, Kurt and I will make sure the notes from the current > discussions are accounted for and publish -16. > > Thank you, Barry. > > 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. >> >> 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 >> > > > > -- > > Seth Blank | Director of Industry Initiatives > > E: seth@valimail.com | P: 415.273.8818 > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --000000000000e6e8e60571237494 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ack - look for it before EOW.

--Kurt

On Mon, = Jul 16, 2018 at 1:09 PM, Seth Blank <seth=3D40valimail.= com@dmarc.ietf.org> wrote:
=
Excellent, Kurt and I will make sure the notes from the cu= rrent discussions are accounted for and publish -16.

Tha= nk you, Barry.

On Mon, Jul 16, 2018 at 1:02 PM, Barry Leib= a <barryleiba@computer.org> wrote:
We have a good set of comments on -15, and thanks, everyon= e, for that.
Kurt and Seth, please make the changes that make sense based on the
discussion, and publish -16 when you've done that.=C2=A0 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.=C2=A0 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



--

Seth Blank | Director of Indus= try Initiatives

E: seth@valimail.com | P:<= /span> 415.273.8818

<= /div>

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


--000000000000e6e8e60571237494-- From nobody Mon Jul 16 14:48:47 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 535EC130DF2; Mon, 16 Jul 2018 14:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CiiOppifshfs; Mon, 16 Jul 2018 14:48:41 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26303131225; Mon, 16 Jul 2018 14:48:25 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id l15-v6so11116165lji.6; Mon, 16 Jul 2018 14:48:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ljCCVdC5DeWRLXC8DJ5qZh4QFkwf58432B4hNO6ShlQ=; b=Kg5CHvU3NLDOyalRvu0qC2x6KETJ4+uv3hAS+QhAXsPgXRDwgICKYOvZaKf2fvgAMB yCDHGDbSd3ZVv8GoVGEqJyIvfE66PPUAv6UxlKUuux6x1wLe0FQv/a2mFxbjeTM9Yukl Ow1bQ+ZT9XJf6CVfH/hUHySneDdPqXnYJNowsfEhRtvY5fKTSQZbbgsG8N4UusiZu/74 hADdhIj0QwTDPM38y/bcyeqO7/sgPhfrmRf6NhghtAxs78toMli8q6ic2rnnuBBYigi5 pOg6IYPkxy3JFBZrshi5tOm7BL6cfoKnhdbFQF+BBdsPaPAWeD2oV/fba7K7Vdw5yvuP TpaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ljCCVdC5DeWRLXC8DJ5qZh4QFkwf58432B4hNO6ShlQ=; b=Crde677N7U1itFYKtdBtWcO9xna0XP+xApjgCBit7/YKmO6mFuAStWG5ub0dazdjtQ Bwz9GU+BBrf8PAZEG8WQGmg3lt1dJ5I4lOUwcgHddwfz+5d3y/IVRhUIubbgxx8KA/6p m55DYAy5pbcryVMmvnEq/GWuvoD32/ltKKXvdJTLebDkw3JJOoKXjEHJf8bdQQgWHjO7 4njBzUCPHWyROS70RAQ6+Cn0XreIerTZVTuTqtTcQxageRPbezLpup7r2ueRXOeYmD2F 5MljDIabXUIGm+xTQLD69o1ex29OQEVnRtayFpJ9KFXk8nyjUMyrHyxQE9cPhh+3nYoo 7kew== X-Gm-Message-State: AOUpUlGvbpNwYWpG2hYD5P164mFhiOA/KL0ntTyeacwu8M1qG1YI0hcN PEiPtL5Q49OrikFfZrGYmlM+nFHf0kEbnW37dRFyAsL4 X-Google-Smtp-Source: AAOMgpdq/SS3Fch9UDV3Tr8DIQxnvy7MD3nrkAdBI7BqTfwSKCf0N0ZT7d9UqfZcnD17I39JkNLEcitqtxwpPVNHWEM= X-Received: by 2002:a2e:1609:: with SMTP id w9-v6mr11744914ljd.120.1531777703376; Mon, 16 Jul 2018 14:48:23 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:3a13:0:0:0:0:0 with HTTP; Mon, 16 Jul 2018 14:48:22 -0700 (PDT) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Mon, 16 Jul 2018 21:48:22 +0000 Message-ID: To: Seth Blank Cc: dmarc@ietf.org, draft-ietf-dmarc-rfc7601bis@ietf.org Content-Type: multipart/alternative; boundary="000000000000e27e6a057124c928" Archived-At: Subject: Re: [dmarc-ietf] WGLC on draft-ietf-dmarc-rfc7601bis-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 21:48:46 -0000 --000000000000e27e6a057124c928 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 16, 2018 at 4:56 PM, Seth Blank wrote: > 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) between the current text in 2.3 and what's in 2.3 > of 7601. The text is supposed to be loosened so things like smtp.client-ip > and arc.oldest-pass info for ARC A-R stamps are allowable in the registry. > https://www.ietf.org/rfcdiff?url1=draft-ietf-dmarc-rfc7601bis-01&url2=rfc7601 They're inverted (RFC7601 is on the right) but have a look at 2.3. 2) Typo: Section 2.2 references "sob-domain" > Fixed in source. -MSK --000000000000e27e6a057124c928 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jul 16, 2018 at 4:56 PM, Seth Blank <seth@sethbl= ank.com> wrote:
I've reviewed. All the technical matters look good, and earlier com= ments have all been addressed. I have two final comments:

1) Section 6.4 mentions changes to section 2.3 which include slightly dif= ferent language than in 7601. I see no difference whatsoever (walking back = diffs 02-01, 01-00) between the current text in 2.3 and what's in 2.3 o= f 7601. The text is supposed to be loosened so things like smtp.client-ip a= nd arc.oldest-pass info for ARC A-R stamps are allowable in the registry.


They're inverted (RFC7601 is on the = right) but have a look at 2.3.

2) Typo: Section 2.2 refere= nces "sob-domain"

Fix= ed in source.

-MSK

--000000000000e27e6a057124c928-- From nobody Mon Jul 16 14:50:58 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE5813120D for ; Mon, 16 Jul 2018 14:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGc0D26wLMUT for ; Mon, 16 Jul 2018 14:50:55 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43A31130DF2 for ; Mon, 16 Jul 2018 14:50:55 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id s198-v6so77723202oih.11 for ; Mon, 16 Jul 2018 14:50:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=T8TMdiSEK1ZI8pA+JKEn/biW7EUxpwFN1mp5Jzu6/Rs=; b=A9Ev/rYcrLIy8jq6yjU+NE+r/M3nrPVS8E3Yzu/0d4vzoPV8QQGHPf4X2bQyIKtq8q CqKTAGsLgPHfcGHPnbRdwbgIhUFeuF+RtKhomk20Zx/3mH/DTH2KGm4vogmmN0WRi1tt L4if/Dmx8Th3xhZkM5NuDgqyyfmaX7ZNSLoA+D5MWo6f4nt0k3wn9Sxghj4it9rQOzLs 6eqlInZom7UuAc/+IIa1+KJC9a43MxgJ69dqT9V/kPT++3K4H4n6cuzo4JuD2afCCvav FIzewcMC/9FYV+0MM0XLCVcEtkoGSGEcjJrekt/Mj9hr/QKN1hC0rPbtI478IwqA7HqV 0ojA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=T8TMdiSEK1ZI8pA+JKEn/biW7EUxpwFN1mp5Jzu6/Rs=; b=HmGUNxrrj93kVZFljwLKnStKdbEbD5OgVo9CVvmwiDhjPjcfTFcfN6fI1xWgaR/Is8 841PCrvEpIAA5Z7wnn9IZa2sFELPfacj9Y3hril98iUy4UWIfMoLxbB4qlzPBP3ODEVV wt1Sw4wFVu42hXEeDotWYCwDIVk3iATxpGndhpcLn1FeTluwxJr3Ra7FejgtOUBeapCZ nt54tA2+wt3L0mRoC8FT9j0ktinWnKVvBFtRqwROZYIcUpJMXzyfjbVFY31+mpcxujJ5 DN0LqmacA8MPAzL9OO1R/680cQgt5t197yJR0gnNlNKtVJlBk58sSJRlMvRneb2CkK66 jnMw== X-Gm-Message-State: AOUpUlGPOiRB59EG0vY7/nvS3MD5eIgW45bdQvYl5uuDj4OMP//KsATw 1ABFry/stKkxiYjAIoof/m3aBjR4siCz5Pl5UBo+GA== X-Google-Smtp-Source: AAOMgpf4n5OLB+mXJKxJyM3tyC6+DhGJI89G8Az/810OYfn5n5xbSbBNCbbFl2aLbnPxxYumsza+xNAFiFBnmgzTt14= X-Received: by 2002:aca:3d05:: with SMTP id k5-v6mr1094456oia.86.1531777854446; Mon, 16 Jul 2018 14:50:54 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:2646:0:0:0:0:0 with HTTP; Mon, 16 Jul 2018 14:50:33 -0700 (PDT) In-Reply-To: References: From: Seth Blank Date: Mon, 16 Jul 2018 14:50:33 -0700 Message-ID: To: "Murray S. Kucherawy" Cc: dmarc@ietf.org, draft-ietf-dmarc-rfc7601bis@ietf.org Content-Type: multipart/alternative; boundary="000000000000e3b8d5057124d272" Archived-At: Subject: Re: [dmarc-ietf] WGLC on draft-ietf-dmarc-rfc7601bis-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 21:50:58 -0000 --000000000000e3b8d5057124d272 Content-Type: text/plain; charset="UTF-8" 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 >> 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) between the current text in 2.3 and what's in 2.3 >> of 7601. The text is supposed to be loosened so things like smtp.client-ip >> and arc.oldest-pass info for ARC A-R stamps are allowable in the registry. >> > > https://www.ietf.org/rfcdiff?url1=draft-ietf-dmarc- > rfc7601bis-01&url2=rfc7601 > > They're inverted (RFC7601 is on the right) but have a look at 2.3. > > 2) Typo: Section 2.2 references "sob-domain" >> > > Fixed in source. > > -MSK > > --000000000000e3b8d5057124d272 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 <superuse= r@gmail.com> wrote:
On Mon, Jul 16, 2018 at 4:56 PM, Seth Blank <s= eth@sethblank.com> wrote:
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 sect= ion 2.3 which include slightly different language than in 7601. I see no di= fference whatsoever (walking back diffs 02-01, 01-00) between the current t= ext in 2.3 and what's in 2.3 of 7601. The text is supposed to be loosen= ed so things like smtp.client-ip and arc.oldest-pass info for ARC A-R stamp= s are allowable in the registry.


They're inverted (RFC7601 is on the right)= but have a look at 2.3.

2) Typo: Section= 2.2 references "sob-domain"

Fixed in source.

-MSK


--000000000000e3b8d5057124d272-- From nobody Tue Jul 17 06:52:12 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C454312D7F8 for ; Tue, 17 Jul 2018 06:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-Sn2Hc9qzj7 for ; Tue, 17 Jul 2018 06:52:08 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63122129385 for ; Tue, 17 Jul 2018 06:52:08 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id p10-v6so1070153ljg.2 for ; Tue, 17 Jul 2018 06:52:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LJ8r4P0UXNR7J4B4xoC0ABgykhBWhb/awjRc2wFo46g=; b=HMATR1Uv1+MR+beK+l6rvBZjQipoQbd34b9DiOUrT8Z+bdgubNAIKwzDwRf3qBadBP USr6gOhgXhA+RevW3h3xXWLTAWNpif6gL/+WWWNMZo1rGrtBaRuVN8T95k/yTWHhsVe/ V8qv0ROjLtH9m4kue3Itey/ludbt/oYeAq45DA6Pc/WtWhf0hy008mZFDHqdKtyl9tPr mSKZZsLG55H4bvjRxz5RWhdY60rVB1UAvr7M9DYjqFML4G1Q9bRfS98B06oF/wgGDBtA XcgV6a+XxQN09pUMZm3dqYIIBS37+2q/z/TVqRmuQlWqAip/QGeYrjZrjnpktsyaOjm6 CnSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LJ8r4P0UXNR7J4B4xoC0ABgykhBWhb/awjRc2wFo46g=; b=a5JnAECRBdILKGn1B8hi0F3Wj8M48xkmlXOndlC77i05nKPOGsOWkGvOQZm0ffnoEe TIn/MiGkMtycgPTKHFwplwKwsR2RRrnkXLt2LWaEyxUlm5TxSuens0f7mJheYkIjMQGQ w6MLSz0MoeKxgBcK+bwgqmyKDv69fECghsHlq1Nd23s5V2c6Nc6nb8IcpNVnpQDksP0l OzgeJNdhxqmkXtxJbVzbJZz5WvFuG97uD2o21YuFKMCWs8VLHI9utkd1VKz7DclR+Atg Eu/y9ma1xuO8lZS0P4+l04eqAcb2Csv2o2+S5OvKZM0kui6AAxA7TuNNomC+YeSFb+sN PdzA== X-Gm-Message-State: AOUpUlFdoQrm1Phh9HKeh+GfHQkTD31qESjaOXwIExFBQAFoKRPzvdxF eZ0pG4QagLLXPMpiAO5TeVP4e6T+FGyDuI4X1/0= X-Google-Smtp-Source: AAOMgpfzvPPVM7EU3eANEm/HuXuMA1tFRKXhSyfuIJN6F5RNninMR9UAjdztCOFSKv7Y+26zK8S8jVM1QrI18EYCfnc= X-Received: by 2002:a2e:5519:: with SMTP id j25-v6mr1625631ljb.124.1531835526589; Tue, 17 Jul 2018 06:52:06 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:3a13:0:0:0:0:0 with HTTP; Tue, 17 Jul 2018 06:52:06 -0700 (PDT) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Tue, 17 Jul 2018 09:52:06 -0400 Message-ID: To: Barry Leiba Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="0000000000006ab34e05713240b4" Archived-At: Subject: Re: [dmarc-ietf] WGLC will be on ARC-16 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 13:52:11 -0000 --0000000000006ab34e05713240b4 Content-Type: text/plain; charset="UTF-8" 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 --0000000000006ab34e05713240b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jul 16, 2018 at 4:02 PM, Barry Leiba <barry= leiba@computer.org> 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.=C2=A0 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.=C2=A0 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= 9;s points on the basis that we don't want to derail the experiment tha= t is ARC.=C2=A0 I believe we punted on some of Bron's points as well ea= rly on.=C2=A0 I've taken this position because I think the thing that&#= 39;s critical here is to determine if ARC, in operation, provides any meani= ngful signal (or indeed, any damage) that we need to capture to solve the p= roblem this working group is chartered to address.

I'= ;m assuming that we will return and give these deferred points due consider= ation when we complete the experiment and come back around to doing a stand= ards track version.=C2=A0 Note that "due consideration" only guar= antees discussion; it does not guarantee that we'll come back and chang= e 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
--0000000000006ab34e05713240b4-- From nobody Tue Jul 17 06:56:43 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 812BC130F86 for ; Tue, 17 Jul 2018 06:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOBwFYwmfMPI for ; Tue, 17 Jul 2018 06:56:30 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A577130FC4 for ; Tue, 17 Jul 2018 06:56:29 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id z13-v6so1622563wma.5 for ; Tue, 17 Jul 2018 06:56:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2gl75F2D82LnTw97ZtKTau1z1VqRPtMclVsWXOLjmoI=; b=k8YgN701RqA62Mu9OVCopDzehNMhKzbW806h8B8x/xGmwZjk4R7MIFo8NiPatekZRh rsDSyX/4KUOwM43w/CsDz8tCC9XYkOiUegni8ILg5jo5CC6UO9dfUdADlQ2PnyUZB6BF we570kJ3NSSHJ5v8l6uub4/KBZWydBDnY4mCWbOMB7A8d6spvV/kjLm6RjBXBRgPxszn 45K/oCeJBHWXRRcRFWVJ6WUJ/jVnoYY8Eb3LWJYF1k/HAj73R/7NVYS8ZMhiQ0y7GeHF DaJZoSkxzb3H9tt1YJ+xd5SzAzOdwmpQylTsG0Teq433w6dhkkdS3UqYXwz5O3m/VIwd Cbhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2gl75F2D82LnTw97ZtKTau1z1VqRPtMclVsWXOLjmoI=; b=oIAWyjhdn2cQCyMDGEfbnDkt8G01es7Kve5RutgNrTnRKixq9ETUZPavymbjmiwVtr L8AloBIgprhGylR9LOYFblfv86KfSfxPCu2nW/Bjd+4/1qFSem00EIZZ3SabgQRTaDnR lq6KEole6OY+B8Cjniq+IBO0nqAfl21GqKzCHQH2JIrzLFEqMH9tRsOhL48tr9Xq1MKd gi28c7+GBH1VCb4+0d3G8aDNi9lFNYkXxYpIIj8NeCLT4hpag3r3OR70AcxZHI1Swzwh /KwaCf3lQuojNMBC8i3ttcWLQzKK6sgl7eJI4k97RZELLfLivHFpuLTLwt230mRgG1Yk Ajng== X-Gm-Message-State: AOUpUlH5ZDk0xVTOenR3jNn04PIrQimI08zOQ94oK95ukf9J0k2ediT2 f1HUEro1nSWB6d+9OAWriRjWIaUSpJs9Ep/INoY= X-Google-Smtp-Source: AAOMgpck0cTBe/cvoeEkF6zyTH4at977KrN/5tw2Oqyg1M/dqEmaDMFlMBrssNNManJgNGoOn4zDxTcctBdFVstdYhM= X-Received: by 2002:a1c:6d9a:: with SMTP id b26-v6mr1366188wmi.74.1531835788016; Tue, 17 Jul 2018 06:56:28 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:adf:a414:0:0:0:0:0 with HTTP; Tue, 17 Jul 2018 06:56:27 -0700 (PDT) In-Reply-To: References: From: Tim Wicinski Date: Tue, 17 Jul 2018 09:56:27 -0400 Message-ID: To: Barry Leiba Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="000000000000ffc0670571324fab" Archived-At: Subject: Re: [dmarc-ietf] WGLC will be on ARC-16 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 13:56:42 -0000 --000000000000ffc0670571324fab Content-Type: text/plain; charset="UTF-8" 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 > --000000000000ffc0670571324fab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Barry

I'll bring this up during DNS= OP on Wednesday. =C2=A0=C2=A0

Any issues we just b= lame Murray? of course not.=C2=A0

Tim
DN= SOP tri-chair



On Mon, Jul 16, 2018 at 4:02 PM, Barr= y Leiba <barryleiba@computer.org> wrote:
We have a good set of comments on -15, and thanks, eve= ryone, for that.
Kurt and Seth, please make the changes that make sense based on the
discussion, and publish -16 when you've done that.=C2=A0 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.=C2=A0 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

--000000000000ffc0670571324fab-- From nobody Tue Jul 17 07:04:28 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 624C0130DFD for ; Tue, 17 Jul 2018 07:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPqX2ggN9kDW for ; Tue, 17 Jul 2018 07:04:20 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 786D712D7F8 for ; Tue, 17 Jul 2018 07:04:20 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id l7-v6so1079830ioj.1 for ; Tue, 17 Jul 2018 07:04:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=xQ/AGmr6n8thSGMb6ml50Xf3Owfu+MXcn6ReBBE5ocY=; b=Etgbt9Tq9v/cDwc8nGBFNPiw5hfV42y9EkS12Uvv4VLTkYU61VhKyrFEXUBDuC36IH 943y+7O1Ys/5CNZOOykBCQajuQGrE/vbIWJMtLfInDFP9HiB+JPh+hJRHXuHN8Ysxigx /aEXF8i9VrtmTE+oItVOfd77hOtp8OR0F5ecE8LCBLIjpqHTvESNJr9Swm0vkHhAT11m qh6pGpWWmUcnA8zHs1aG7s9slbf5W18HavzYZs1rAhA9sZlrTUIYxOJiWOY3A7boU0sP OLbG1KRAr1obWvWDzldO49qzEeZyYqR/l5sdkYE1u5WoQMN5stvq8489lKzv6Qfq2U7m vExQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=xQ/AGmr6n8thSGMb6ml50Xf3Owfu+MXcn6ReBBE5ocY=; b=RgOMR9qh/UjvtbYb+Y54oJLtWqeelsD88cf4NYbZ6HrYGMLE0t0hgb3Q0pHnYJZ/IL u8fcFnpRnWlou0+Vu5Vtqxozn59kP13g48tBboHRJ04scc5pUxi3gIHAtGEpqyn65zbe Aj4ATvHoL+LVJErO5cnEgO+znui4wwxK/funI//hKYyAan2Xo1sv+W2WGffjzzVVFFXR 7SC644OXb0FIi+XPsjYPnubroMokWmVPRUeNt1wDaIIRmoml/p+e8xkD29wOiq9J7F7o 4GESzpG4pjTwZcPUjUyiqpXKvMuHsjC2uIo/a4xTCgU1NTalwiEs3HhlJAVw3Geb7dqr HNog== X-Gm-Message-State: AOUpUlFLdSgCv7AQym7DrXVgjbVMjugL7E9m1g+Vvqs6gHYBFK6Ln5Ht j1zTed6lW/i4ZfyabYcZSqgdNJwjtsrsSb9ZC/I= X-Google-Smtp-Source: AAOMgpfvHg2lJbWf2n3tlKL0PhOW0Yys9fHNqG7908ynMA8MfSSoTUad1fGGjsiGhy7oRAXkESWGfTb+NpaI2JvfNso= X-Received: by 2002:a6b:9bd1:: with SMTP id d200-v6mr1647600ioe.147.1531836259721; Tue, 17 Jul 2018 07:04:19 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 2002:ac0:8e88:0:0:0:0:0 with HTTP; Tue, 17 Jul 2018 07:04:18 -0700 (PDT) In-Reply-To: References: From: Barry Leiba Date: Tue, 17 Jul 2018 10:04:18 -0400 X-Google-Sender-Auth: TdMqKjtKr7JtXMRlHm2KB-hYuoI Message-ID: To: Tim Wicinski Cc: dmarc@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dmarc-ietf] WGLC will be on ARC-16 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 14:04:27 -0000 > I'll bring this up during DNSOP on Wednesday. Thanks, Tim. Barry From nobody Tue Jul 17 08:02:32 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5317130E27 for ; Tue, 17 Jul 2018 08:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w_E_WomI-sEM for ; Tue, 17 Jul 2018 08:02:09 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF8F0130F7F for ; Tue, 17 Jul 2018 08:02:01 -0700 (PDT) Received: from dhcp-84ae.meeting.ietf.org ([IPv6:2001:67c:370:128:9a9:ae6a:3054:aa81]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id w6HF1tt4008785 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 17 Jul 2018 08:01:57 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1531839718; bh=iYAip/Ykiu1QTITRdnB7vDoc8MTTRAPWCIOlwX5/Z3A=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=WI0wi/fNGFq8V/RbH7QLtEyt4yrGQZygmipsAk1qFQ9W7Tg1QlZZ4JQpl7vseYlrk T0cEDvR6kZmgVja+Bjt7sw9elmXwswVVfPcXxmUEiD7MWIvQlateKyCB3Rl0mfRROg Z8pFCHFF8BdPcc80qnaIn+RQNt642mYaPzZy0HXY= To: "Kurt Andersen (b)" Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" References: <20180712013919.1E61120020F35F@ary.qy> From: Jim Fenton Message-ID: <71da7d63-07b7-81d0-e0bb-503cceffe05c@bluepopcorn.net> Date: Tue, 17 Jul 2018 11:01:54 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------BAF88ABB2FD3711882ADC92C" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC protocol-15 posted X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 15:02:20 -0000 This is a multi-part message in MIME format. --------------BAF88ABB2FD3711882ADC92C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 7/16/18 1:00 PM, Kurt Andersen (b) wrote: > On Mon, Jul 16, 2018 at 7:06 AM, Jim Fenton > wrote: > > On 7/16/18 9:17 AM, Murray S. Kucherawy wrote: >> On Sun, Jul 15, 2018 at 6:27 PM, Jim Fenton >> > wrote: >> >> >> I suggest that as part of WG Last Call that the DNS >> Directorate be consulted, largely to socialize this with them >> so they aren't surprised by the request load requirements. >> >> >> Should the draft say more than what Section 9.2 already says? > > 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 consulting the > DNS directorate, it would be good to mention the operational > impact of 9.2. > > I also wonder if it would be helpful to mitigate the operational > impact by saying that AS SHOULD use the same selector as the > associated AMS. > > > I would be opposed to adding the suggestion of this sort of > restriction on the basis of hypothetical load impacts. 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 --------------BAF88ABB2FD3711882ADC92C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit On 7/16/18 1:00 PM, Kurt Andersen (b) wrote:
On Mon, Jul 16, 2018 at 7:06 AM, Jim Fenton <fenton@bluepopcorn.net> wrote:
On 7/16/18 9:17 AM, Murray S. Kucherawy wrote:
On Sun, Jul 15, 2018 at 6:27 PM, Jim Fenton <fenton@bluepopcorn.net> wrote:

I suggest that as part of WG Last Call that the DNS Directorate be consulted, largely to socialize this with them so they aren't surprised by the request load requirements.

Should the draft say more than what Section 9.2 already says?

 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 consulting the DNS directorate, it would be good to mention the operational impact of 9.2.

I also wonder if it would be helpful to mitigate the operational impact by saying that AS SHOULD use the same selector as the associated AMS.

I would be opposed to adding the suggestion of this sort of restriction on the basis of hypothetical load impacts.

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

--------------BAF88ABB2FD3711882ADC92C-- From nobody Tue Jul 17 08:12:06 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22C7A130F7B for ; Tue, 17 Jul 2018 08:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epNerCeqdXwq for ; Tue, 17 Jul 2018 08:11:29 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07115130F66 for ; Tue, 17 Jul 2018 08:11:29 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id y200-v6so1108468lfd.7 for ; Tue, 17 Jul 2018 08:11:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nLm8EliOfrkgYP7Fhkk5fdaFfIKZXPQslTDoDnXF9K4=; b=e/UENey0eOqchS1fplSbiXcI85iJhlf7YUB/tatJr3bpY+NoJd1MGfM+nG9lmBhCQ3 x+6hhP6NqtJkj9QTcgkD49dSWdDKGDMS9lR6WkDlXi1XFXQDjsNUMgg5HcT4zUq264cV NrHtqHcBBQjuqKOl9ENxF6h5mfTe6Wq8MssloTC9TPWyuwC1Z85wmj8kX6DXRD0G34tF 7w3DhI0HRhSEp52erTKeWKuZ+1NTb/zknU0giXHA196sLVXOt+V8L/f5q4G+9WYVs+Gf gfFP+yEx5dPh8qsQvfIzVEax4kRDMQvAooQfya2+NLNAXgz2O+90v7be/LelH8lhU2N3 99fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nLm8EliOfrkgYP7Fhkk5fdaFfIKZXPQslTDoDnXF9K4=; b=ZfiUvDn50hDAcu2go6g/JjissqpqmJW7XS8vepCQzYGjFZgGauo6mGOc6ni8pNWKxL VcNOWn9i8F1g2tSr6vXMU9Qh+6dDJBE2rde5LSqJRpqprME1q/cAMpAjHd2yS4C0LSfE HtbM3qjbFtKfa1vRP5OBX0r78F86hmLMF/xjZG8jPm63SvrjZAZwfHxnpTDQSHSREwoF wbkLrFKuNmFQDXQF2xJwTYzc9hR/yrx86zUm6TCkHQuCiE23/ON62vPRwxCgJyGSGp3o owE2oZqHeoDYxG6Wi6Pei1qhijHlwv35zLIt6A+iUI/NyuJkDI10w2vOCoc1+50sDho2 P/wA== X-Gm-Message-State: AOUpUlG5SLgnJEIgFs1si70Qyrp01Ww54X2YuQFO2MPrPfokQjGCyCXY oUFWdtawBLjjvU3AYvvyyZdpgI+HLAAyywsb+f6UNA== X-Google-Smtp-Source: AAOMgpdc0FEBEqafBmU1VHpZ3SqFRV0ix1rkJcqGKN9hOtiNBEWLiojWQdVXNqIOQ3wVUQhdshP2DurNt4lG17TfF00= X-Received: by 2002:a19:dd5c:: with SMTP id u89-v6mr1512380lfg.83.1531840287209; Tue, 17 Jul 2018 08:11:27 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:3a13:0:0:0:0:0 with HTTP; Tue, 17 Jul 2018 08:11:26 -0700 (PDT) In-Reply-To: <20180717144933.5BF5E20025B16B@dhcp-85af.meeting.ietf.org> References: <20180717144933.5BF5E20025B16B@dhcp-85af.meeting.ietf.org> From: "Murray S. Kucherawy" Date: Tue, 17 Jul 2018 11:11:26 -0400 Message-ID: To: John Levine Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="0000000000002bfc1c0571335c14" Archived-At: Subject: Re: [dmarc-ietf] WGLC on draft-ietf-dmarc-rfc7601bis-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 15:11:40 -0000 --0000000000002bfc1c0571335c14 Content-Type: text/plain; charset="UTF-8" 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&url1=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 ietf@ietf.org] What are they? This is WGLC, now's the time. -MSK --0000000000002bfc1c0571335c14 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 17, 2018 at 10:49 AM, John Levine <johnl@taugh.= com> wrote:
Try this:

=C2=A0https://w= ww.ietf.org/rfcdiff?url2=3Ddraft-ietf-dmarc-rfc7601bis-02&url= 1=3Drfc7601

Looks OK to me.=C2=A0 I have some minor editorial niggles about the wording=
of the EAI advice, but the substance is fine.


=
[re-adding dmarc@ietf.org,= removing ietf@ietf.org]

=
What are they?=C2=A0 This is WGLC, now's the time.

<= /div>
-MSK
--0000000000002bfc1c0571335c14-- From nobody Tue Jul 17 08:18:07 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2762C1271FF for ; Tue, 17 Jul 2018 08:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=goNdMhh0; dkim=pass (1536-bit key) header.d=taugh.com header.b=jRqW/TI4 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wXZk4ynLh5d for ; Tue, 17 Jul 2018 08:18:03 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5C65124C04 for ; Tue, 17 Jul 2018 08:18:02 -0700 (PDT) Received: (qmail 92767 invoked from network); 17 Jul 2018 15:18:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=16a5d.5b4e08a9.k1807; bh=Wz2fcZ+C+gH99dAeXGYq1NDC+BMGvRywMF48kUS2zfI=; b=goNdMhh03YeDPRtLfGd99o/0A8JkS0BtbQGADsBNyZIqjgVtQaDKIGchWGJNK8XvIm6rYUjqHIUjQIIhGlYEgaRYn6xc8MRQdxlAaBcbzWV2lgqlwMREtAbxNoHEpQCSP6IgtGS40U3rixRs8OlSPTDKD2JV3NIKKVw+EQnDNPJn4aZKVSiN5/hYu6oyUrt+bzzdDeSskhvvMnKHOoWfU1KTkZsRa6709+QGWOUbf0dhCR/D4Vc9/sq7XE2ehoBQ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=16a5d.5b4e08a9.k1807; bh=Wz2fcZ+C+gH99dAeXGYq1NDC+BMGvRywMF48kUS2zfI=; b=jRqW/TI4uut1CRTSR10s4Qfzbv4LJWvYI9GVSXGBDMGf4Uw53sC555wuuZ43SpRxm5BmpWFIa6+yuMoFiNvMytl9Ny3Oq5sKTLC0GosaqKYSZdGxm8vumQ1rl1/9ee+ETKYGLEwT1J0FxxP3B2CXdMZPXDV7/aYmzusDebsC9y807ApWB5LSa22Nfvl7Ca6ygSen0XqJlV8JNLL2tiD/IsRawplUqUqCxsoRQMEP3eV3pnKpXawJrNus7xCOhUZr Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 17 Jul 2018 15:18:01 -0000 Date: 17 Jul 2018 11:18:00 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" Cc: dmarc@ietf.org In-Reply-To: References: <20180717144933.5BF5E20025B16B@dhcp-85af.meeting.ietf.org> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] WGLC on draft-ietf-dmarc-rfc7601bis-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 15:18:06 -0000 >> https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-rfc7601bis-02&url1=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 From nobody Tue Jul 17 08:45:24 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B35130EE8 for ; Tue, 17 Jul 2018 08:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RChwvr-U1rXQ for ; Tue, 17 Jul 2018 08:45:04 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60F8F130F66 for ; Tue, 17 Jul 2018 08:45:01 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id k12-v6so2889365oiw.8 for ; Tue, 17 Jul 2018 08:45:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=ywRC1RsBumA05pVdFD+O7oNMPSV4+RY7CAfWW95dERg=; b=ZZiZkQ+JQfNBjXxTFwIx1MmwzaQvJac0CinAvR9TQnBoRUvcLCxI/gWGF24l5PBpjA SvxWZh+922E2gnvzc/DHW1YE3OL4XJQ3zMwWyRm8gI4Y3i4YVYlLx4eAfUN83v9X+/+/ KBtxdhXi/hrHuQ2DXKAY39BqR/FGhQs3fPezf0rUSSw2BYFFmhSvcRyEMer8Tx64m/kt urhwqwNI+C77MLKeFnyMld8Iu/uLQlY1rvDCawIIGH3Ri11liSM8rPVk17ozLEGz49F4 0oYm14iHu0W3taY3GEn1i7ELEsKADOTIYBwwBDndVgtRw/qAM++4lERK8QZjCa/ZHlkH aofg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=ywRC1RsBumA05pVdFD+O7oNMPSV4+RY7CAfWW95dERg=; b=GUN4SMWhO8wkGjSPTXsCRY6/uAxSYlTWSifpTNuRRzF+ydtdTE0vpvJHkwM7BuoVXd Z7U91paeVXxhORb8yToNZKcqR97d4eQv9iBXQrIj22sbKuvBAvTM12bXV9hr6MOgyp15 9oDzF8wN7CN5q7EN4mb1B3oQL2yOOhVoW+PGhJUuU1L2p4TF53yXpzNwLqe61VVSZFCm uLtBYemFecB6vnVVcd8az9OwdBtJUdUWqLfJtJHG5ypQSKyqdPnqzrFoCDoMzQ7AxHJa f5/HrTOTSp2t8Z+bM7++UKjMRLnVP2XaFVJYyNo43KwmuX40KPwnW4Gc+e/GsiDmTXRD QZNA== X-Gm-Message-State: AOUpUlFF4kR81gFmBW0NvR8M+l5uiHM5yXK8FvBo1Eb314D2ShIm/qu0 FTEGSiSdNBU9Sk9xigknpq5EFmWPQg9cFzNmh478TOhB X-Google-Smtp-Source: AAOMgpdBIdA3BdJrsce7NPeTHazIew+Ah9jgqSP6usYCkGHNzXsZO7tRw4Oly0WsM6gX+yv5VKq/UvzAUKgExdDs1fI= X-Received: by 2002:aca:a993:: with SMTP id s141-v6mr2367608oie.72.1531842300280; Tue, 17 Jul 2018 08:45:00 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:2646:0:0:0:0:0 with HTTP; Tue, 17 Jul 2018 08:44:39 -0700 (PDT) In-Reply-To: <71da7d63-07b7-81d0-e0bb-503cceffe05c@bluepopcorn.net> References: <20180712013919.1E61120020F35F@ary.qy> <71da7d63-07b7-81d0-e0bb-503cceffe05c@bluepopcorn.net> From: Seth Blank Date: Tue, 17 Jul 2018 08:44:39 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002918ab057133d434" Archived-At: Subject: Re: [dmarc-ietf] ARC protocol-15 posted X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 15:45:20 -0000 --0000000000002918ab057133d434 Content-Type: text/plain; charset="UTF-8" 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? --0000000000002918ab057133d434 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 17, 2018 at 8:01 AM, Jim Fenton <fenton@bluepopcorn.net&g= t; wrote:
=20 =20 =20
It wasn't meant as a restri= ction. 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 thi= nk it hurts to point out that it's a good thing to do, from the standpoin= t 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=3D/s=3D bind= ing language?=C2=A0
--0000000000002918ab057133d434-- From nobody Tue Jul 17 13:33:49 2018 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5695C130DD2; Tue, 17 Jul 2018 13:33:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dmarc@ietf.org Message-ID: <153185962729.12680.10783427723792084937@ietfa.amsl.com> Date: Tue, 17 Jul 2018 13:33:47 -0700 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-16.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 20:33:48 -0000 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/ From nobody Tue Jul 17 13:36:15 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9787A130DE2 for ; Tue, 17 Jul 2018 13:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLnpjhoKwn_A for ; Tue, 17 Jul 2018 13:36:10 -0700 (PDT) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 239A5130F13 for ; Tue, 17 Jul 2018 13:36:06 -0700 (PDT) Received: by mail-ed1-x52d.google.com with SMTP id b10-v6so2319588eds.4 for ; Tue, 17 Jul 2018 13:36:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=j7Lbn9VZDgeGstfa8VOm+T+doOQF85Wycw1iLzryP+Q=; b=FCSa8/E36YslH5tY06rScaN08hU4cxDqSm/V0lfdEqEfE8FIJ5LIw5cWm1u16JulgM Dx+iY6PO8saOleiq3KNFwV3UNvRwycIdmi7nqSsBOflJky81BN+S5YRkGXPkzPbtjQ0N hKLNUyIfuMlgLOxDEA4r2brnWD5OCeVNpckTs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=j7Lbn9VZDgeGstfa8VOm+T+doOQF85Wycw1iLzryP+Q=; b=A1K6DXuoWnI8oPq7gC4rVU+74dykR06GlNIWPRHhLjMV52ry1H39T4/oNX8iu4T2g1 YuaVd3LlChxhWftSOspqateTSjHI2sxgv0fgqfBOsAo2lIiTkSTvpu0Me/8Wt1KCwcer Npl7xLjxdQ7cRCwKWTn0uSxaTQA1GBACCBu3hjmBv8ZaPQPnf9DOEkiftJYnghgDC6ws z9gxkkUv8rMoN/UaLGUZMAoxLq9/YS9GCt7b7I1U8sWrepS7BiFgX0R33rNG50cQWwCI IjH3r/jlYnPBStTwyvTYXL/FXmLzYDcAPkLhofnle8RqkAEr2khKmh62emeZOWTyyhAk T4RQ== X-Gm-Message-State: AOUpUlGXbOpv2TqBTVphn6YFm6ZZarYVgMtRvFDPJ0vDBm3ema9A9aMM xGHPFkf/Fm/xXeptUicLhfZW+zEKkTwRgirD3D26fNNOrCs= X-Google-Smtp-Source: AAOMgpcK3PQo3/equb5sSi/xObpd9Tymlxs6lRey9yZl4cW39sMKXjp/z31lXmOUHBVQ2XkBnnhGnXS2XTcHisBkUQY= X-Received: by 2002:a50:a3ce:: with SMTP id t14-v6mr4098781edb.227.1531859764618; Tue, 17 Jul 2018 13:36:04 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 2002:aa7:da87:0:0:0:0:0 with HTTP; Tue, 17 Jul 2018 13:36:03 -0700 (PDT) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Tue, 17 Jul 2018 13:36:03 -0700 X-Google-Sender-Auth: phQbQ0rWxXQYgCmLxaYToeGqW74 Message-ID: To: Barry Leiba Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001db63d057137e543" Archived-At: Subject: Re: [dmarc-ietf] WGLC will be on ARC-16 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 20:36:14 -0000 --0000000000001db63d057137e543 Content-Type: text/plain; charset="UTF-8" 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 --0000000000001db63d057137e543 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Authenticated Received Chain (AR= C) Protocol
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Dat= e=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :=C2=A02018-07-17

<= div class=3D"gmail_quote">

<= div class=3D"gmail_extra">
There are also= htmlized versions available at:
A diff from the previou= s version is available at:
=

--Kurt
=C2=A0
--0000000000001db63d057137e543-- From nobody Tue Jul 17 14:27:25 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA55130E34 for ; Tue, 17 Jul 2018 14:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkYzE_e0xRLx for ; Tue, 17 Jul 2018 14:27:22 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D884130E03 for ; Tue, 17 Jul 2018 14:27:22 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id v26-v6so2271778iog.5 for ; Tue, 17 Jul 2018 14:27:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=MHwK5Z7LRc2ai3tpAtkgu2BGiOFNdX6+yr5Ex8q1GOU=; b=mFN6hOCaTMv4UlMVUDDRxoMzcucE9Q5GR+fxES4zi8MsIvjmW8KPhQKMaUbUy7L4wV B0rma54oBCdwfdI2BQQakomZByiPCfHmKQ5ETd7QcN+xtQISM6oQd8I34wGliyJZpBih Pf4dDdaEdGMZiME6i+LgF8GOERO/wVWHFxdRPv9YQ2bOPaLtYbGIXvGURl15p/JtHo8P hwGe6Bovci6+6Xw/s8ge6BRFFdlUQt2fnloMW/maWGyMSuREdMl8kuD+a2Qz52Gpmsrp OCATO8ZZrbeIC+R+/7QMqk8D9zVkwcfkxJOiEB1wDnpW1mBRC4XhV104fcYfxrvgHGyh yEfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=MHwK5Z7LRc2ai3tpAtkgu2BGiOFNdX6+yr5Ex8q1GOU=; b=hqJIIpWBbWuKvfW5bCBgfD0YuHJSBn3fYu9Ot7FiRSuU+z96m/nU8XT7Atz4ehZ4cG 6JHnY9c8nR0t+hCxOI3WwU/aeqzSXFaG8yRc/93m50rxIixUWNmVlJPjAqWvQWZ7LLYC 79Plw8WmAWLfwy78xDP6iag6VRiF2i8u9ODj6lN0lG1wliXud/VGsZ0amWflNffb3px3 8AeH2E1Fiv+Z6ux6YxwLNO8opFG36HmMXcFHE3A6eBpdiCPGiCOGZKxGTMdzY+wiC98w wYHVJqMsPm/PGZDICDwt5a4cjSDeYw1Umdj0/vGYldAV73bTyCvKWxhB8XQir8hA4L4O l40Q== X-Gm-Message-State: AOUpUlFxNEyuYrKkcPWBFP4cUj2wtJksECPhS8cQ6VRMnvyNmL3ih6o1 TIa6eas4UiNTrnRbNmVHRHd1NoiWLdQS9SDxvrH30K8J X-Google-Smtp-Source: AAOMgpdZUEL6D0P41Vd58NNfDd0+T960cN4iITfssCDjtUPdbiDb+wmmjvW+xFqcb4OwS0eI1grp9dj8C7Dq+TcySCs= X-Received: by 2002:a6b:9bd1:: with SMTP id d200-v6mr3153825ioe.147.1531862841675; Tue, 17 Jul 2018 14:27:21 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 2002:ac0:8e88:0:0:0:0:0 with HTTP; Tue, 17 Jul 2018 14:27:21 -0700 (PDT) From: Barry Leiba Date: Tue, 17 Jul 2018 17:27:21 -0400 X-Google-Sender-Auth: G-Q_3prbMK4gAxTD3LNkd5nrJC4 Message-ID: To: dmarc@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [dmarc-ietf] WGLC on draft-ietf-dmarc-arc-protocol-16 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 21:27:24 -0000 So begins Working Group Last Call (WGLC) on draft-ietf-dmarc-arc-protocol-16. Please review the latest version: https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/ .... and send comments to the DMARC working group mailing list by 3 August. If you review it and think it's ready to go and you have no comments, please post that as well. If you think your earlier comments have not been addressed and should have been, please say so. As you review, keep in mind that the target status is Experimental, and that after we've played with it for a while we'll have another chance to adjust it based on that experience. -- Barry, DMARC chair From nobody Tue Jul 17 16:59:59 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57432130E6A for ; Tue, 17 Jul 2018 16:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQ1JM-igvrPi for ; Tue, 17 Jul 2018 16:59:52 -0700 (PDT) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC58D130E2E for ; Tue, 17 Jul 2018 16:59:52 -0700 (PDT) Received: by mail-pg1-x52d.google.com with SMTP id y5-v6so1136193pgv.1 for ; Tue, 17 Jul 2018 16:59:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=yauLgZKJ5njEPxPB+ZZOnxjDS8lfWUO1nlBfuxIVISA=; b=rl4IRTjpzTM/+IdwbNKECEgDq9w86MQVZNTHYx2Ns/xX8nYF7t1ZkpVI6fnUrgxUqx MErmqEgHmE2yWA/3rjT7qVhn+XcvWdLhpDHbG0lKk2lx9OtWy51egTyhFjChB/PgEWG7 f6j3MGmaytUQadj2xPWacxgckBZ4PGV7bi689xDjlWqvQZ+QwJPX7eAuPGOwUR0a++mt wcVoBpA8WxvWLfm6mESv0wsxA8DgNrFy+8OM/kA2BdhC42ogwAIA5KO1msWR3AQU8rpe Wrmf2K4i/FRZfhTeEBSjHlNM81x0hQUQTADObk5IWGcfzLOt1YtzjaMvp0XYjBqCfLMP 2b+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=yauLgZKJ5njEPxPB+ZZOnxjDS8lfWUO1nlBfuxIVISA=; b=nOFQZSQFC1L5Dv/lB6Jd+LHU2Yvkmamm4S+H8QA/eTYXPsbujtjZLtgFgpw9+OWSoW 07b7vDAUyu2h6r1MOo6X6j8hu8MB8bh/jVzdA/MPQxcY3upDZnKhDBt4pFj1ceCekn49 FJ/9h4qgu1rDXEYzpkQmgoLmzvVYnVkJMjIO1Wv0/MaPBddO81T6lFP3FMiCk0xjaclw E/CaNObds9dVNQhQ64Yxy5TMU+TK5sDuEaeK42WD8X50YaE6N8oXcnYCmB6Dd9tYuL4e sk/l37CcYzjg4apwUf2eWUvzVJW/WuynFD6i0BnE5cD+5Qg9a9xM1BYPylhnI+bnbyIt nCcQ== X-Gm-Message-State: AOUpUlEJMgVs0695jLblmtlUiY+1uwudrQ/det7LdDZF8J8tnl4v3hB5 MJTuiSIriRpsy5JZ1uyzlFFC179U X-Google-Smtp-Source: AAOMgpfv0SRqz8rNyvNKpgMuhdCXudOQ+qeWwiKtnAXu2BxO+299Br3bek6va6bGUi4qfpwEP9Wblw== X-Received: by 2002:a65:608b:: with SMTP id t11-v6mr3509862pgu.259.1531871991763; Tue, 17 Jul 2018 16:59:51 -0700 (PDT) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net. [76.218.8.128]) by smtp.gmail.com with ESMTPSA id x6-v6sm7026716pfe.30.2018.07.17.16.59.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Jul 2018 16:59:50 -0700 (PDT) From: Dave Crocker To: IETF DMARC WG Message-ID: <71818a04-ba70-c4ff-e091-be0a996fd746@gmail.com> Date: Tue, 17 Jul 2018 16:59:48 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] Partial Review of: draft-ietf-dmarc-arc-protocol-16 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 23:59:58 -0000 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-Draft ARC-Protocol July 2018 > > > 5.2.1. All Failures Are Permanent . . . . . . . . . . . . . 16 > 5.2.2. Responding to ARC Validation Failures During the SMTP > Transaction . . . . . . . . . . . . . . . . . . . . . 16 > 5.3. Result of Validation . . . . . . . . . . . . . . . . . . 16 > 6. Communication of Validation Results . . . . . . . . . . . . . 17 > 7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 17 > 7.1. Communicate Authentication Results Across Trust > Boundaries . . . . . . . . . . . . . . . . . . . . . . . 17 > 7.1.1. Message Scanning Services . . . . . . . . . . . . . . 17 > 7.1.2. Multi-tier MTA Processing . . . . . . . . . . . . . . 18 > 7.1.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 18 > 7.2. Inform Message Disposition Decisions . . . . . . . . . . 18 > 7.2.1. DMARC Local Policy Overrides . . . . . . . . . . . . 19 > 7.2.2. DMARC Reporting . . . . . . . . . . . . . . . . . . . 19 > 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20 > 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 > 9.1. Increased Header Size . . . . . . . . . . . . . . . . . . 20 > 9.2. DNS Operations . . . . . . . . . . . . . . . . . . . . . 21 > 9.3. Message Content Suspicion . . . . . . . . . . . . . . . . 21 > 9.4. Message Sealer Suspicion . . . . . . . . . . . . . . . . 21 > 9.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 22 > 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 > 10.1. Email Authentication Results Names Registry Update . . . 22 > 10.2. Email Authentication Methods Registry Update . . . . . . 22 > 10.3. Definitions of the ARC header fields . . . . . . . . . . 23 > 11. Experimental Considerations . . . . . . . . . . . . . . . . . 23 > 11.1. Success Consideration . . . . . . . . . . . . . . . . . 24 > 11.2. Failure Considerations . . . . . . . . . . . . . . . . . 24 > 11.3. Open Questions . . . . . . . . . . . . . . . . . . . . . 24 > 11.3.1. Value of the ARC-Seal (AS) Header . . . . . . . . . 24 > 11.3.2. DNS Overhead . . . . . . . . . . . . . . . . . . . . 24 > 11.3.3. What Trace Information is Valuable . . . . . . . . . 25 > 12. Implementation Status . . . . . . . . . . . . . . . . . . . . 25 > 12.1. GMail test reflector and incoming validation . . . . . . 26 > 12.2. AOL test reflector and internal tagging . . . . . . . . 26 > 12.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 27 > 12.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . 27 > 12.5. Mailman 3.x patch . . . . . . . . . . . . . . . . . . . 27 > 12.6. Copernica/MailerQ web-based validation . . . . . . . . . 28 > 12.7. Rspamd . . . . . . . . . . . . . . . . . . . . . . . . . 28 > 12.8. PERL MAIL::DKIM module . . . . . . . . . . . . . . . . . 29 > 12.9. PERL Mail::Milter::Authentication module . . . . . . . . 29 > 12.10. Sympa List Manager . . . . . . . . . . . . . . . . . . . 29 > 12.11. Oracle Messaging Server . . . . . . . . . . . . . . . . 30 > 12.12. MessageSystems Momentum and PowerMTA platforms . . . . . 30 > 12.13. Exim . . . . . . . . . . . . . . . . . . . . . . . . . . 30 > 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 > 13.1. Normative References . . . . . . . . . . . . . . . . . . 31 > > > > Andersen, et al. Expires January 18, 2019 [Page 3] > > Internet-Draft ARC-Protocol July 2018 > > > 13.2. Informative References . . . . . . . . . . . . . . . . . 32 > 13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 33 > Appendix A. Appendix A - Design Requirements . . . . . . . . . . 33 > A.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 34 > A.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 34 > Appendix B. Appendix B - Example Usage . . . . . . . . . . . . . 34 > Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 34 > Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 35 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 > > 1. Introduction > > The utility of widely deployed email authentication technologies such > as Sender Policy Framework (SPF) [RFC7208] and DomainKeys Identified > Mail (DKIM) [RFC6376] is impacted by the processing of Internet Mail > by intermediate handlers. This impact is thoroughly documented in > the defining documents for SPF and DKIM and further discussed in > [RFC6377] and [RFC7960]. > > The utility of technologies that build upon SPF and DKIM (such as > DMARC [RFC7489]) is similarly impacted by intermediate handlers. The > disruption of authentication mechanisms for legitimate messages by > intermediate handlers can impact all aspects of Internet Mail - > message authors, message recipients, and even the intermediary > handler itself. editorial, to simplify and reduce redundancies, replace the above paragraph: DMARC [RFC7489] relies on mechanisms such as SPF and DKIM. So their failures that are caused by the actions of intermediate handlers can in turn cause legitimate mail to be incorrectly rejected or misdirected. (drop the 'all aspects' sentence.) > > Authenticated Received Chain (ARC) creates a mechanism for individual > Internet Mail Handlers to add their authentication processing results > to a message's ordered set of processing results. ARC encapsulates > processing results in a DKIM signature derivative to grant other > handlers the ability to verify the authenticity of the individual > processing results as well as the aggregate set and sequence of > results. > > Ordered sets of processing results can be used by ARC-enabled > Internet Mail Handlers to inform message handling disposition, to > identify where alteration of message content might have occurred, and > to provide additional trace information for use in understanding > message handling paths. > > 2. General Concepts > > ARC is loosely based on concepts from evidence collection. Evidence > is usually collected, labeled, stored, and transported in specific > ways to preserve the state of evidence and to document all processing > steps. I think this means based on 'legal' concepts of evidence, really. While it theoretically should apply to all handling of anything one might call evidence, this really is drawing from the legal world, isn't it? > Andersen, et al. Expires January 18, 2019 [Page 4] > > Internet-Draft ARC-Protocol July 2018 > > > 2.1. Evidence A term like "authentication state" needs to be defined or at least explained, given its importance to the text here. There's an argument one can make that the term is actually inappropriate. I don't think this activity has a concept of an authentication state machine. One might invent such a thing and might even be useful, but it hasn't been done, has it? While it's not as verbally tight, I suspect language more like "validation of message authentication information" or "authentication assessment" or "authentication validity" are both more intuitive and correct. (BTW, this might be why 'evidence' is a problematic term, since, really, assertions about prior validations constitute a kind of hear-say; it's second-hand information, not direct, objective 'evidence'. Though it might be a bit facile, an alternative choice could be 'testimony'...) > In ARC's situation, the "evidence" is a message's authentication > state at any point along the delivery path between origination and > final delivery. Authentication state can change when intermediate > handlers modify message content (headers and/or body content), route > messages through unforeseen paths, or change envelope information. > > The authentication state of a message is determined upon receipt of a > message and documented in the Authentication-Results header field(s). > ARC extends this mechanism to survive transit through intermediary > ADMDs. > > 2.2. Custody > > "Custody" refers to when an ARC-enabled Internet Mail Handler > processes a message. When a handler takes custody of a message, the > handler becomes a Custodian and attaches their own evidence > (authentication state upon receipt) to the message. Evidence is > added in such a way so that future handlers can verify the > authenticity of both evidence and custody. Custody refers to when any Internet Mail handler processes a message. (Applicability of the term does not depend on ARC, or at least it shouldn't.) ARC provides a means of /authenticating/ custody. *** MAJOR *** ARC does /not/ allow verifying the authenticity of earlier 'evidence', other than the evidence of handling signatures. That is, assertions about prior validations are not really 'evidence'. This is a persistent point of confusion about ARC and I consider it serious. Using ARC requires developing trust in the handlers that make these ARC assertions of earlier validity. This is quite different from a later handler 'verifying' that validity, since it can't. *** *** > 2.3. Chain of Custody > > The "chain of custody" of ARC is the entire set of evidence and > custody that travels with a message. > > 2.4. Validation of Chain of Custody > > Any ARC-enabled Internet Mail Handler can validate the entire set of > evidence and custody to yield a valid Chain of Custody. If the No, it can validate who made what assertions -- and in what order -- not that the assertions were valid. > evidence-supplying Custodians can be trusted, then the validated > Chain of Custody describes the (possibly changing) authentication > state as the message traveled through various Custodians. It can validate statements about authentication, not the actual state/correctness of those statements. > Even though a message's authentication state might have changed, the > validated chain of custody can be used to determine if the changes > (and the Custodians responsible for the changes) can be tolerated. > > 3. Terminology and Definitions > > This section defines terms used in the rest of the document. > > Readers should to be familiar with the contents, core concepts, and > definitions found in [RFC5598]. The potential roles of > intermediaries in the delivery of email are directly relevant. The term 'intermediaries' does not appear in 5598. Nor does a term like 'intermediate handler'. Worse, the document here probably needs a term that covers both regular MTAs AND delivery/re-posting agents such as mailing lists, which is what RFC 5598 calls 'mediators'. I was going to suggest just saying 'handler' or the like but RFC 5598 uses the word differently. So the best I can suggest from RFC 5598 is 'transit service' which ought to cover both regular MTA service and upper-level services like mailing lists. > > > > > > Andersen, et al. Expires January 18, 2019 [Page 5] > > Internet-Draft ARC-Protocol July 2018 > > > Language, syntax (including some ABNF constructs), and concepts are > imported from DKIM [RFC6376]. Specific references to DKIM are made > throughout this document. The following terms are imported from > [RFC5598]: > > o ADministrative Management Domain (ADMD), Section 2.3 > > o Message Transfer Agents (MTA), Section 4.3.2 > > o Message Submission Agent (MSA), Section 4.3.1 > > o Message Delivery Agent (MDA), Section 4.3.3 > > Internet Mail Handlers process and deliver messages across the > Internet and include MSAs, MTAs, MDAs, gateways, and mailing lists. > > Syntax descriptions use Augmented BNF (ABNF) [RFC5234] and [RFC7405]. > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in > BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all > capitals, as shown here. These words may also appear in this > document in lower case as plain English words, absent their normative > meanings. > > 3.1. ARC Set > > Section 4.1 introduces three (3) ARC header fields. Together, the 3 fields -> fields that are added to a message by an ARC transit system. (That is, an arc set is a specific instance, not the abstraction that defines those 3 fields.) > header fields compose a single "ARC Set". An ARC Set provides the > means for an Internet Mail Handler to attach authentication state to > a message in a manner that can be verified by future handlers. A > single message can contain multiple ARC Sets. > > In General Concept terms, an ARC Set represents Evidence and Custody. > > 3.2. Authenticated Received Chain (ARC) > > The complete sequence of ARC Sets attached to a message is called the > Authenticated Received Chain. An Authenticated Received Chain is a > recording of individual authentication states as a message traverses > through ARC-participating ADMDs. "The complete sequence" Hmmm... /What/ complete sequence? Do you mean the complete sequence attached to a message at any one point during transit? Or do you mean the complete sequence attached to the message after final delivery? Or...? (On reflection, I suggest calling a sequence under development -- that is, one being built during transit -- a 'partial sequence' and save 'complete sequence' to refer to what exists after final delivery.) > > The first attachment of an ARC Set to a message causes an > Authenticated Received Chain to be created. Additional attachments > of ARC Sets cause the Authenticated Received Chain to be extended. > > > > > > Andersen, et al. Expires January 18, 2019 [Page 6] > > Internet-Draft ARC-Protocol July 2018 > > > In General Concept terms, an Authenticated Received Chain represents > Chain of Custody. > > 3.3. Sealer > > A Sealer is an Internet Mail Handler that attaches a complete and > valid ARC Set to a message. > > In General Concept terms, a Sealer adds Evidence and proof of Custody > to the Chain of Custody. Might be worth explaining why the term 'signer' isn't sufficient for this, since a reader will likely think it the more natural choice. > > 3.4. Validator > > A Validator is an ARC-enabled Internet Mail Handler that evaluates an > Authenticated Received Chain for validity and content. The process > of evaluation of the individual ARC Sets that compose an > Authenticated Received Chain is described in Section 5.2. > > In General Concept terms, a Validator inspects the Chain of Custody > to determine the content and validity of individual Evidence supplied > by Custodians. > > 3.5. Imported ABNF Tokens > > The following ABNF tokens are imported: > > o tag-list ([RFC6376] section 3.2) > > o authres-payload ([I-D-7601bis] section 2.2) > > o cfws ([RFC5322] section 3.2.2) > > 3.6. Common ABNF Tokens > > The following ABNF tokens are used elsewhere in this document: > > position = 1*2DIGIT ; 1 - 50 > instance = [CFWS] %s"i" [CFWS] "=" [CFWS] position [CFWS] ";" > chain-status = ("none" / "fail" / "pass") > seal-cv-tag = %s"cv" [CFWS] "=" [CFWS] chain-status Over the years, I've come to believe that good ABNF formatting aids readers quite a bit. So I suggest something like: position = 1*2DIGIT ; 1 - 50 instance = [CFWS] %s"i" [CFWS] "=" [CFWS] position [CFWS] ";" chain-status = ("none" / "fail" / "pass") seal-cv-tag = %s"cv" [CFWS] "=" [CFWS] chain-status << stopped here. /d >> d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Jul 18 10:38:01 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1165130F1F for ; Wed, 18 Jul 2018 10:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iyew8Av2ql3z for ; Wed, 18 Jul 2018 10:37:50 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EB34130E80 for ; Wed, 18 Jul 2018 10:37:47 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id s198-v6so10311583oih.11 for ; Wed, 18 Jul 2018 10:37:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=cUK+rKEMSv3gIAxJl7evGsGDAFPDtdvG7z0n3isbc7E=; b=SjVpHBK4jQb5xJokSMwqiPNA4/ONcu9/hQyHWUiWYpz+V4N0Am8u71dFdRCwy+MhfS uuBUozDe5VXn3Txgdmi6xxn2fSRLTe0JY6h0cOg09mZEcHW9WyQBWR1WlHLAZNJ4OzTw AfGH7ScBCUGBDstDRGKj0pIX6iuY5FaxWbh+9j3xBWh9cqNzAyM6LCKI7xXnpkww5H+H OVI1Hy8+6DML/ZJ92XpfDVDEq2PFDPaYQakPztu31E5bgDrsptgs0PbkMWIwE/fNSYFB ewVkQFUNbpPp142ybp1SIBgdYDwcNWIGjt9SFvKhxxI1716elwoH4b25TN2AwdC8NoHY I+lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=cUK+rKEMSv3gIAxJl7evGsGDAFPDtdvG7z0n3isbc7E=; b=dswakhIguUCGmkRMRgjGnges64LXsyIMZB66mJ8gPS+CwemSmQNQKxAAbwfCskdR3M yv+cVrn6pEPNBxkQbS2twfItSXObT8GtUbnwZRZDhkA0LbnfmuSsGip4lWFoafc25gVT QEEPEjPmvOBjvpt6H9y535giroSQek8GAheJ2FyPEWPJfrIZR7bxqeMiy+vIJ/TdrNCy K92xYdwYhP7+ouTC7bkj0Lgoaf1sYSF8uMvEeKzhFtl3wIgN2oqjAEsUE+4HbDfkjuqg W2Szmq7FfTJUq45917yJKh1T8TlB97rsR9kmWrHlpyw/s7+4Zmb6yaJH0A8EH2ezVBj4 cX6g== X-Gm-Message-State: AOUpUlGoJ9VffnWL7UWNuKi4eJ9HXaRlIJaAcMEbIn9F3XZQzNUbcIMH 958MQL1wkGsj0FxjBGcUj35wpQ6QT5i8X6/q7bT/RYm8 X-Google-Smtp-Source: AAOMgpfZ3J0YI53Kj+ZKOh+bPQJsTzO1+u0sXN5B8bBQpBBtaigiOtknnJfWhziwNZl/ItIMWD2WUwo4jYi60SOikBY= X-Received: by 2002:aca:bd8b:: with SMTP id n133-v6mr7542730oif.108.1531935465809; Wed, 18 Jul 2018 10:37:45 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:2646:0:0:0:0:0 with HTTP; Wed, 18 Jul 2018 10:37:25 -0700 (PDT) In-Reply-To: <71818a04-ba70-c4ff-e091-be0a996fd746@gmail.com> References: <71818a04-ba70-c4ff-e091-be0a996fd746@gmail.com> From: Seth Blank Date: Wed, 18 Jul 2018 10:37:25 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000042451205714985c0" Archived-At: Subject: Re: [dmarc-ietf] Partial Review of: draft-ietf-dmarc-arc-protocol-16 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 17:38:00 -0000 --00000000000042451205714985c0 Content-Type: text/plain; charset="UTF-8" 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 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/ > Thanks for this, and keep them coming. Your review of -14 was heavily folded into the rewrite of -15, but I don't believe anyone ever said this on list. That was an oversight. > 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. > The abstract's been rewritten numerous times, including with the help of the Chairs and AD. I do like your suggestion, but would appreciate hearing if other members of the working group concur with your guidance. > 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. > This is a fair point, but I think discussing custody in the abstract has led us down less clear paths previously. Raising these issues in a General Concepts section seems to have clarified and simplified the document. editorial, to simplify and reduce redundancies, replace the above paragraph: > > DMARC [RFC7489] relies on mechanisms such as SPF and DKIM. So their > failures that are caused by the actions of intermediate handlers can in > turn cause legitimate mail to be incorrectly rejected or misdirected. > > (drop the 'all aspects' sentence.) > That works. > I think this means based on 'legal' concepts of evidence, really. While >> it theoretically should apply to all handling of anything one might call >> evidence, this really is drawing from the legal world, isn't it? > > The original text here referenced legal concepts, but it didn't add anything valuable and was stricken for the sake of simplicity and clarity. > A term like "authentication state" needs to be defined or at least > explained, given its importance to the text here. > Agreed. > There's an argument one can make that the term is actually inappropriate. > I don't think this activity has a concept of an authentication state > machine. One might invent such a thing and might even be useful, but it > hasn't been done, has it? > > While it's not as verbally tight, I suspect language more like "validation > of message authentication information" or "authentication assessment" or > "authentication validity" are both more intuitive and correct. > > (BTW, this might be why 'evidence' is a problematic term, since, really, > assertions about prior validations constitute a kind of hear-say; it's > second-hand information, not direct, objective 'evidence'. Though it might > be a bit facile, an alternative choice could be 'testimony'...) > Also agreed. We'll review and suggest language; I'm leaning towards "authentication assessment." Custody refers to when any Internet Mail handler processes a message. >> > > (Applicability of the term does not depend on ARC, or at least it > shouldn't.) > > ARC provides a means of /authenticating/ custody. > The General Concept Terms exist to provide a framework for those unfamiliar with ARC to understand it. While you are correct that any handler has Custody irrespective of ARC, while setting up the framework for those new to ARC we're only specifically talking about the ARC representation of custody. Removing the reference to ARC makes this less clear to a new reader. You are correct that ARC provides a means of authenticating custody of a message; we will look at folding this language into section 2.4, I believe it is more clear than the current text. > *** MAJOR *** > > ARC does /not/ allow verifying the authenticity of earlier 'evidence', > other than the evidence of handling signatures. That is, assertions about > prior validations are not really 'evidence'. > > This is a persistent point of confusion about ARC and I consider it > serious. > > Using ARC requires developing trust in the handlers that make these ARC > assertions of earlier validity. This is quite different from a later > handler 'verifying' that validity, since it can't. > > *** *** > I concur with your final thought, but am unaware of this being a point of confusion. This is explicitly called out in Security Considerations 9.4. > No, it can validate who made what assertions -- and in what order -- not > that the assertions were valid. > Yes. That was the intent of this language, we'll clarify. > evidence-supplying Custodians can be trusted, then the validated >> Chain of Custody describes the (possibly changing) authentication >> state as the message traveled through various Custodians. >> > > It can validate statements about authentication, not the actual > state/correctness of those statements. > Correct. I believe this clarifies itself when we change "authentication state" to "authentication assessment" and have that properly defined earlier in the document. > The term 'intermediaries' does not appear in 5598. Nor does a term like > 'intermediate handler'. Worse, the document here probably needs a term > that covers both regular MTAs AND delivery/re-posting agents such as > mailing lists, which is what RFC 5598 calls 'mediators'. > This is why "Internet Mail Handler" was defined in section 3. However, its prominence appears lost due to formatting. We'll fix that. > fields -> fields that are added to a message by an ARC transit system. > > > (That is, an arc set is a specific instance, not the abstraction that > defines those 3 fields.) > Fixed. > "The complete sequence" > > Hmmm... /What/ complete sequence? Do you mean the complete sequence > attached to a message at any one point during transit? Or do you mean the > complete sequence attached to the message after final delivery? Or...? > > (On reflection, I suggest calling a sequence under development -- that is, > one being built during transit -- a 'partial sequence' and save 'complete > sequence' to refer to what exists after final delivery.) > I think this is clarified by simply stating "the complete sequence of ARC Sets attached to the message at any given time" > Might be worth explaining why the term 'signer' isn't sufficient for this, > since a reader will likely think it the more natural choice. > This is why 5.1.6 exists; in general concepts this nuance is confusing. Over the years, I've come to believe that good ABNF formatting aids readers > quite a bit. So I suggest something like: > > position = 1*2DIGIT ; 1 - 50 > instance = [CFWS] %s"i" [CFWS] "=" > [CFWS] position [CFWS] ";" > chain-status = ("none" / "fail" / "pass") > seal-cv-tag = %s"cv" [CFWS] "=" > [CFWS] chain-status Yes, there are several formatting issues that need to be fixed in the final XML. Thanks, Seth --00000000000042451205714985c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 17, 2018 at 4:59 PM, Dave Crocker <dcrocker@gmail.com> wrote:
Review of:=C2=A0 =C2=A0 draft-= ietf-dmarc-arc-protocol-16 (partial)
Date:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A017 Jul 18
Reviewed by:=C2=A0 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 per= vasive language problems that are serious enough to make it likely that a r= eader will misunderstand core ARC concepts.=C2=A0 I've suggested altern= ative language, where I could.

d/

Thanks for this, and keep them comin= g.

Your review of -14 was heavily folded into the = rewrite of -15, but I don't believe anyone ever said this on list. That= was an oversight.

=C2=A0
My review of -14 noted problems with the abstract.=C2=A0 Whil= e there have been some changes, the Abstract remains too... abstract.=C2=A0= 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 bene= fit that it enables.

Text like this needs to be written for people who are not trained in theore= tical computer science and are not already deeply enmeshed in this work.

The abstract's been rewritten numerou= s times, including with the help of the Chairs and AD. I do like your sugge= stion, but would appreciate hearing if other members of the working group c= oncur with your guidance.
=C2=A0
Note also that while typical discussion of ARC refers to it as establis= hing a chain of custody, no language like that is in the Abstract.=C2=A0 I = think that's a serious omission.

Th= is is a fair point, but I think discussing custody in the abstract has led = us down less clear paths previously. Raising these issues in a General Conc= epts section seems to have clarified and simplified the document.

editorial, to simplify and reduce redundancies, replace the above paragraph= :

=C2=A0 =C2=A0 =C2=A0DMARC [RFC7489] relies on mechanisms such as SPF and DK= IM. So their failures that are caused by the actions of intermediate handle= rs can in turn cause legitimate mail to be incorrectly rejected or misdirec= ted.

(drop the 'all aspects' sentence.)

<= div>That works.
=C2=A0
I think this means based on 'legal' concep= ts of evidence, really.=C2=A0 While it theoretically should apply to all ha= ndling of anything one might call evidence, this really is drawing from the= legal world, isn't it?

Th= e original text here referenced legal concepts, but it didn't add anyth= ing valuable and was stricken for the sake of simplicity and clarity.
=

=C2=A0
A term like "authentication state" needs to be defined or at leas= t explained, given its importance to the text here.
Agreed.
=C2=A0
There's an argument one can make that the term is actually inappropriat= e. I don't think this activity has a concept of an authentication state= machine.=C2=A0 One might invent such a thing and might even be useful, but= it hasn't been done, has it?

While it's not as verbally tight, I suspect language more like "va= lidation of message authentication information" or "authenticatio= n assessment" or "authentication validity" are both more int= uitive and correct.

(BTW, this might be why 'evidence' is a problematic term, since, re= ally, assertions about prior validations constitute a kind of hear-say; it&= #39;s second-hand information, not direct, objective 'evidence'.=C2= =A0 Though it might be a bit facile, an alternative choice could be 'te= stimony'...)

Also agreed. We'll= review and suggest language; I'm leaning towards "authentication = assessment."

Custody refers to when any Internet Mail han= dler processes a message.

(Applicability of the term does not depend on ARC, or at least it shouldn&#= 39;t.)

ARC provides a means of /authenticating/ custody.

=
The General Concept Terms exist to provide a framework for those= unfamiliar with ARC to understand it. While you are correct that any handl= er has Custody irrespective of ARC, while setting up the framework for thos= e new to ARC we're only specifically talking about the ARC representati= on of custody. Removing the reference to ARC makes this less clear to a new= reader.

You are correct that ARC provides a means= of authenticating custody of a message; we will look at folding this langu= age into section 2.4, I believe it is more clear than the current text.

=C2=A0
*** MAJOR ***

ARC does /not/ allow verifying the authenticity of earlier 'evidence= 9;, other than the evidence of handling signatures.=C2=A0 That is, assertio= ns about prior validations are not really 'evidence'.

This is a persistent point of confusion about ARC and I consider it serious= .

Using ARC requires developing trust in the handlers that make these ARC ass= ertions of earlier validity.=C2=A0 This is quite different from a later han= dler 'verifying' that validity, since it can't.

***=C2=A0 =C2=A0***

I concur with your = final thought, but am unaware of this being a point of confusion. This is e= xplicitly called out in Security Considerations 9.4.
=C2=A0
=
No, it can validate who made what assertions -- and in what order -- not th= at the assertions were valid.

Yes. That= was the intent of this language, we'll clarify.
=C2=A0
=
=C2=A0 =C2=A0evidence-supplying Custodians can be trusted, then the validat= ed
=C2=A0 =C2=A0Chain of Custody describes the (possibly changing) authenticat= ion
=C2=A0 =C2=A0state as the message traveled through various Custodians.

It can validate statements about authentication, not the actual state/corre= ctness of those statements.

Correct. I = believe this clarifies itself when we change "authentication state&quo= t; to "authentication assessment" and have that properly defined = earlier in the document.
=C2=A0
The term 'intermediaries' does not appear in 5598.=C2=A0 Nor does a= term like 'intermediate handler'.=C2=A0 Worse, the document here p= robably needs a term that covers both regular MTAs AND delivery/re-posting = agents such as mailing lists, which is what RFC 5598 calls 'mediators&#= 39;.

This is why "Internet Mail Ha= ndler" was defined in section 3. However, its prominence appears lost = due to formatting. We'll fix that.
=C2=A0
fields -> fields that ar= e added to a message by an ARC transit system.

(That is, an arc set is a specific instance, not the abstraction that defin= es those 3 fields.)

Fixed.
= =C2=A0
=C2=A0 "The complete sequence"

Hmmm...=C2=A0 /What/ complete sequence?=C2=A0 Do you mean the complete sequ= ence attached to a message at any one point during transit?=C2=A0 Or do you= mean the complete sequence attached to the message after final delivery?= =C2=A0 Or...?

(On reflection, I suggest calling a sequence under development -- that is, = one being built during transit -- a 'partial sequence' and save = 9;complete sequence' to refer to what exists after final delivery.)
=

I think this is clarified by simply statin= g "the complete sequence of ARC Sets attached to the message at any gi= ven time"

=C2=A0
Might be worth explaining why the term 'signer' isn't sufficien= t for this, since a reader will likely think it the more natural choice.

This is why 5.1.6 exists; in general conc= epts this nuance is confusing.

Over the years, I've come to believe that good ABNF formatting aids rea= ders quite a bit.=C2=A0 =C2=A0So I suggest something like:

=C2=A0 =C2=A0 position=C2=A0 =C2=A0 =C2=A0 =3D=C2=A0 1*2DIGIT=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0; 1 - 50
=C2=A0 =C2=A0 instance=C2=A0 =C2=A0 =C2=A0 =3D=C2=A0 [CFWS] %s"i"= [CFWS] "=3D"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0[CFWS] position [CFWS] ";"
=C2=A0 =C2=A0 chain-status=C2=A0 =3D=C2=A0 ("none" / "fail&q= uot; / "pass")
=C2=A0 =C2=A0 seal-cv-tag=C2=A0 =C2=A0=3D=C2=A0 %s"cv" [CFWS] &qu= ot;=3D"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0[CFWS] chain-status

Yes, there are sever= al formatting issues that need to be fixed in the final XML.

=
Thanks,

Seth=C2=A0

--00000000000042451205714985c0-- From nobody Wed Jul 18 11:10:36 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 672DB130EC2 for ; Wed, 18 Jul 2018 11:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWFCY7S7GxA5 for ; Wed, 18 Jul 2018 11:10:31 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DD0A130E8B for ; Wed, 18 Jul 2018 11:10:30 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id u7-v6so4901102lji.3 for ; Wed, 18 Jul 2018 11:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FkeJT8pQWtH5evCHU2WIgdIzYYdcux2cHiN7gPkIBVM=; b=n5bSQ6uJV6cUQdk9vLmeHRgPdjdL/csm3i2imPzGpMlHtS2+MkAv2PR2RbH891nRHq OFfr+6GSbnueZ02OHo/8w8QxJODmLPMDMtU5Y3QfafgJUngsmESWi4PfYA32HvSzEZaG 6GB76c1aq2emtTgGNjqun01U7g3bL+pSXGFJ5kkV4Kd+NY8STHQY5HT7ResUw7BCXDDY 0zWIA6riGFKIeg7/7LSLd7uLRE3sVZfyrFCv77nkaC9WjH7a0VB04T7xu33pr3GxeZGz PMbIbqyTbSUAr97kqUdDwYzKGCPqmrg4FF6CSvYHNYlpPHVQtIO/aSJrYQtSggDl96aM 8dQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FkeJT8pQWtH5evCHU2WIgdIzYYdcux2cHiN7gPkIBVM=; b=Gct6Jd6atMy7zI4uoAGPUoIrC5g229cle+l21htIgOlD9n0U4p60iZToWM/Ce1gNBc r4hR2OH8hXIN0K8dS+bzCC/gLZOxpL2WTngcpa/TgDzW5cuquY5XsZ5GP/peqyrwDVQO kN7xrKDVB5h7ZqeXP4pvX852aTRbFTCAiPTsoPJKzZ6K+r2vDlk5RK1osM4tuQ64dIm2 owyxIz6A096vYgTvZJw6ypyLatGC9ybU2RwjyXJdYE1pD6uOAOa1nLhz+5ZTe4ZAXgoi 6llFhm4AHv3/xK48UcVuT7IqV4TLrdC/VtMHVdYdzZdDEdns3uJYnK4SCF35f4z0CoKM BvDw== X-Gm-Message-State: AOUpUlFJh6x/cmi2ADF1tG/braP+qkZT5sNdVnRhKdnUEgu2DK0AEDZi BuID99EHcuVTRxaXHXiQmpSYnslwGy3tcl8pn8M73Q== X-Google-Smtp-Source: AAOMgpfdlOhpQK5Rfyz0RVZBlf/6wmCzInN1Y07bHMUxjCgH5UAs82zgTsWbTNEJ5QdOLNqvxqB4Cqn/rh1YAipvHqQ= X-Received: by 2002:a2e:1dc8:: with SMTP id w69-v6mr5660355lje.110.1531937428870; Wed, 18 Jul 2018 11:10:28 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:3a13:0:0:0:0:0 with HTTP; Wed, 18 Jul 2018 11:10:28 -0700 (PDT) In-Reply-To: References: <71818a04-ba70-c4ff-e091-be0a996fd746@gmail.com> From: "Murray S. Kucherawy" Date: Wed, 18 Jul 2018 14:10:28 -0400 Message-ID: To: Seth Blank Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000441a44057149faba" Archived-At: Subject: Re: [dmarc-ietf] Partial Review of: draft-ietf-dmarc-arc-protocol-16 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 18:10:34 -0000 --000000000000441a44057149faba Content-Type: text/plain; charset="UTF-8" On Wed, Jul 18, 2018 at 1:37 PM, Seth Blank wrote: > > >> 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. >> > > The abstract's been rewritten numerous times, including with the help of > the Chairs and AD. I do like your suggestion, but would appreciate hearing > if other members of the working group concur with your guidance. > Dave, do you have sample text to suggest? > >> 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. >> > > This is a fair point, but I think discussing custody in the abstract has > led us down less clear paths previously. Raising these issues in a General > Concepts section seems to have clarified and simplified the document. > I haven't ever felt comfortable with the references to terminology like "chain of custody". In particular, that term typically references something that is handled by one party at a time and critically insulated against tampering, but (a) it's not clear to me that the chain is complete (non-participants do technically handle the thing of interest) and (b) the custody of what, exactly? If we want to keep that language or general concept, I think we need to be clear what the payload we're discussing actually is. It's not simply "the body" or "the message"; there's more to it than that. Is it "everything the latest ARC-Seal covers", for example? -MSK --000000000000441a44057149faba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 18, 2018 at 1:37 PM, Seth Blank <seth@sethbl= ank.com> wrote:
=C2=A0
My review of -14 noted problems with the abstract.=C2=A0 While there hav= e been some changes, the Abstract remains too... abstract.=C2=A0 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 theore= tical computer science and are not already deeply enmeshed in this work.

The abstract's been rewritten = numerous times, including with the help of the Chairs and AD. I do like you= r suggestion, but would appreciate hearing if other members of the working = group concur with your guidance.
<= br>
Dave, do you have sample text to suggest?

=C2=A0
Note also that while typical discussion of ARC refers to= it as establishing a chain of custody, no language like that is in the Abs= tract.=C2=A0 I think that's a serious omission.
This is a fair point, but I think discussing custody in= the abstract has led us down less clear paths previously. Raising these is= sues in a General Concepts section seems to have clarified and simplified t= he document.

I have= n't ever felt comfortable with the references to terminology like "= ;chain of custody".=C2=A0 In particular, that term typically reference= s something that is handled by one party at a time and critically insulated= against tampering, but (a) it's not clear to me that the chain is comp= lete (non-participants do technically handle the thing of interest) and (b)= the custody of what, exactly?

If we want to keep = that language or general concept, I think we need to be clear what the payl= oad we're discussing actually is.=C2=A0 It's not simply "the b= ody" or "the message"; there's more to it than that.=C2= =A0 Is it "everything the latest ARC-Seal covers", for example?

-MSK
--000000000000441a44057149faba-- From nobody Sun Jul 22 19:07:13 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC25E1310CF for ; Sun, 22 Jul 2018 19:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=V/rau5bs; dkim=pass (1536-bit key) header.d=taugh.com header.b=CdmjvhmX Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-d_9-TBK6GO for ; Sun, 22 Jul 2018 19:07:02 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B9C11310D1 for ; Sun, 22 Jul 2018 19:07:02 -0700 (PDT) Received: (qmail 6029 invoked from network); 23 Jul 2018 02:07:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=178b.5b553845.k1807; bh=5WOfuFQTo2ZQpD2gkhXDln5N3bkSVodBxEFFYhJEbV0=; b=V/rau5bsBElTOscrAT0916Hi+p1q+/3+yrEXxrFkodUxttAGkj0BCJZVdxD5YpZ3bzIVD2IZgVCDqYB3O5YYrqq0wVU3kssxPc25deKEchR4UFX8WTK2T/stNTwPXzPWfvz+H7hjt6pnct5g0iZU5PKL99NKej2IlJibtaS3dd6bgDY/tJwUMrvAHU68bYdaAsparDKqWm32QmF9XP+cTVnXGNDuUor7sEEcYdaJxm9qazdpRz8eaw/OIKjlZG1R DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=178b.5b553845.k1807; bh=5WOfuFQTo2ZQpD2gkhXDln5N3bkSVodBxEFFYhJEbV0=; b=CdmjvhmXgR3hiqWG6wqSnEzMmuLG85KsKXJlImpEC1+OgFt47d6OxnWfWduZSpqMnvhm76OWyxTxgw+ZLqRIsSdjZSAZaWbXh8wi88c0DfJRgGza43iKzrrVcsJl+noxSqJL6x+0xBKT9C3T4gg1j/ux0zbtitUmnrS4evogm0xwlQ8czcCHO1zIoq7eHfZnMKQ9sP+63IzLGUuZdXR825N6S3JN2tCVR76Bfu3uCljGq2mdt8OXNQPZxTbdGHJm Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 23 Jul 2018 02:07:01 -0000 Date: 22 Jul 2018 22:07:00 -0400 Message-ID: From: "John R Levine" To: dmarc@ietf.org User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [dmarc-ietf] Sort of erratum on RFC 7601 for 7601bis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 02:07:11 -0000 An erratum on RFC7601 just appeared that reports a bug in the ABNF for the resinfo rule. I think the purported bug is not a bug but his suggested rewrite to the ABNF is cleaner than what's there now. https://www.rfc-editor.org/errata/eid5435 Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Jul 23 02:33:49 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA066130DE8 for ; Mon, 23 Jul 2018 02:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MabrChdg9b6d for ; Mon, 23 Jul 2018 02:33:46 -0700 (PDT) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C6311277D2 for ; Mon, 23 Jul 2018 02:33:46 -0700 (PDT) Received: by mail-yb0-x229.google.com with SMTP id h127-v6so6999166ybg.12 for ; Mon, 23 Jul 2018 02:33:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:mime-version:to:from:subject:date:importance:in-reply-to :references; bh=/141f8VY/OTB6BX7vs9D/DtMLdtXe7tiHMWqUu28hsM=; b=pMFTFA+upvJ9gXJVSLiQDKjThQqy26WX3ieTVSxYxZpvI9n5BahQLrUy6ofC+BAer5 TfRsz5JVOr+nd/2e7TIs/Vt53N8uj+WcoxV2i8B9Mfvi5eN3qp8kjYbekj+H+n66jzsN 2QMlOZtUP5WroIj4FurqR7kuY7Vy/ltIbTP8qtyjZywOXA9MOI+W2bvuft4Rb14woNyA sWM0hJFp9dFpAPWe8VlATzKKoNCsBn7oV3a8btk6dRvrN1h3HxsehdzDg4rZC+7OIk4L lsg32buBH312q2vHMR9+NJGVkn3K4L4F32lB74fhkbaFp0m/GL1M4C5vcST9LitRoEKu AWVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version:to:from:subject:date :importance:in-reply-to:references; bh=/141f8VY/OTB6BX7vs9D/DtMLdtXe7tiHMWqUu28hsM=; b=suA+825MTIR6Td/4JVU4h+vu4fn1jAGiRn1GYoHk93ZsltBIB073NIKeHnILtcu7go VqlVKcH8Hkgx6gEEalyIXudhH1B5YG0nMTJo6CtBDn+QRh3mKb+R35sGlmQOK7o90egE pkE9vV10ID3F3zcehwfAlVnw3zattfGtMpEKQYpa/XKlZSf8YYlYYTXXAG5FAPwPOzWQ g8mnpCYigQfH8iUJKUIibGG4HD1Md8ZMHM4vA/dxbjTAR3V7yYMiQbS+VInV3xLABKLF YaZjjbPdt2S+cql/jlSqoQGahcKqNduE08cEyQgNDxad8AD3zWSkHBEeWV/LjJuSJxXm DNGw== X-Gm-Message-State: AOUpUlGjYNxSByTZI+UXa2L7cvLs7+mI3pdDPdVC3ZDOX08qXmdcdpLp orYgCo26fa21UJfqBK+rQwCU1AAH X-Google-Smtp-Source: AAOMgpdeV8aXLH88Eifiu7jZ5Ivwi21iD/oyr3S7jEP67yOqSOZddvRqguzu3db7mieeajSEc9oTcw== X-Received: by 2002:a25:2395:: with SMTP id j143-v6mr6561143ybj.55.1532338425147; Mon, 23 Jul 2018 02:33:45 -0700 (PDT) Received: from ?IPv6:2601:192:4e00:596:22:8b71:4eb9:6006? ([2601:192:4e00:596:22:8b71:4eb9:6006]) by smtp.gmail.com with ESMTPSA id l127-v6sm4074592ywc.5.2018.07.23.02.33.43 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Jul 2018 02:33:44 -0700 (PDT) Message-ID: <5b55a0f8.1c69fb81.123a9.53ea@mx.google.com> MIME-Version: 1.0 To: "dmarc@ietf.org" From: Peter Occil Date: Mon, 23 Jul 2018 05:33:45 -0400 Importance: normal X-Priority: 3 In-Reply-To: <5b5539e6.1c69fb81.b4b6d.5477@mx.google.com> References: <20180723000558.CD758B80F99@rfc-editor.org> <5b5539e6.1c69fb81.b4b6d.5477@mx.google.com> Content-Type: multipart/alternative; boundary="_327C9D1B-7640-45BB-BBE1-C1B3C6733CC9_" Archived-At: Subject: [dmarc-ietf] Comments on certain drafts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 09:33:48 -0000 --_327C9D1B-7640-45BB-BBE1-C1B3C6733CC9_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" draft-ietf-dmarc-arc-protocol The production =E2=80=9Carc-info=E2=80=9D includes a semicolon after =E2=80= =9Cinstance=E2=80=9D, which in turn has a semicolon at the end.=C2=A0 Howev= er, a great number of Arc-Authentication-Results header fields I=E2=80=99ve= seen in practice include only one semicolon between the instance and the = =E2=80=9Cauthres-payload=E2=80=9D; for example: =E2=80=9Ci=3D1; mx.example.= com; =E2=80=A6=E2=80=9D. draft-ietf-dmarc-rfc7601bis I also want to report on another form of the Authentication-Results field t= hat I've seen in practice. It has the form: authserv from=3Ddomain; method=3Dresult (comment); from=3Ddomain; meth= od=3Dresult (comment) where "authserv" (from what I've seen) is a domain name that always ends in= "yahoo.com". --Peter --_327C9D1B-7640-45BB-BBE1-C1B3C6733CC9_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

draft-ietf-dmarc-arc-protocol

 

The = production =E2=80=9Carc-info=E2=80=9D includes a semicolon after =E2=80=9Ci= nstance=E2=80=9D, which in turn has a semicolon at the end.  However, = a great number of Arc-Authentication-Results header fields I=E2=80=99ve see= n in practice include only one semicolon between the instance and the =E2= =80=9Cauthres-payload=E2=80=9D; for example: =E2=80=9Ci=3D1; mx.example.com= ; =E2=80=A6=E2=80=9D.

 

draft-ietf-dmarc-rfc7601bis

 = ;

I also want to report on another form of th= e Authentication-Results field that I've seen in practice.=C2=A0 It has the= form:

 

= =C2=A0=C2=A0=C2=A0=C2=A0 authserv from=3Ddomain; method=3Dresult (comment);= from=3Ddomain; method=3Dresult (comment)

&nbs= p;

where "authserv" (from what I've= seen) is a domain name that always ends in "yahoo.com".

 

--Peter

= --_327C9D1B-7640-45BB-BBE1-C1B3C6733CC9_-- From nobody Mon Jul 23 09:08:48 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3D72130EAC for ; Mon, 23 Jul 2018 09:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=lAxmF36X; dkim=pass (1536-bit key) header.d=taugh.com header.b=gcHJ2dCj Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAQtpHRkfi2Q for ; Mon, 23 Jul 2018 09:08:45 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FEC4130E87 for ; Mon, 23 Jul 2018 09:08:45 -0700 (PDT) Received: (qmail 92617 invoked from network); 23 Jul 2018 16:08:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=169c6.5b55fd8b.k1807; bh=QlPdMELmLDl4Tqf98DNLGWOWNPUOaG3Dr4TeG9PB1Ag=; b=lAxmF36XgG2DMt7EiVLi0bu9CPEFozHq7ONu+ZxyZnomuJVJJQ8ppBqTQOrY2N6czu9DzBEK+k9MV5vbfprDf/+lJgyygJFCz2fGj093LQtHly5aLG5fTpgFnyuT/eTSG+f8CuVPSanoPJaUiLGFinjvR15KTiJ6EtlNkjvb/BNK7IB2Vk9fdOBTwzt4KSe0P719g1A8TTlK4TAvWZzMXQhnRyZxbfkO/ljQr3Nwls77K76C0tk2bWeOjjfI6dEy DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=169c6.5b55fd8b.k1807; bh=QlPdMELmLDl4Tqf98DNLGWOWNPUOaG3Dr4TeG9PB1Ag=; b=gcHJ2dCj4DWBzhUa9gz2N53BhFKqlSOlfYZWNC1xTKyqbL8D6267CVXK0vOIb/tnZ8Chg6tIfpeTO3pRDtfYeHUyR2+tWartnj3cmvsRgh71NFoys9WnRV4aoP91ZlagQ6tFq3GOCOtelOrdbrDFIhWuGuQBxx/58FM6hHfj9gY0BARP69zgrQs2JzgK5/FR/9otNTxHJaRrUiDmEsqMxwvOgRAsxsZnBYR02vkGVn9uBBgpFVL00Udj+SXc8Lw6 Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 23 Jul 2018 16:08:43 -0000 Received: by ary.qy (Postfix, from userid 501) id 5498120029643E; Mon, 23 Jul 2018 12:08:43 -0400 (EDT) Date: 23 Jul 2018 12:08:43 -0400 Message-Id: <20180723160843.5498120029643E@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: poccil14@gmail.com In-Reply-To: <5b55a0f8.1c69fb81.123a9.53ea@mx.google.com> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] abnf bug in arc-protocol, was Comments on certain drafts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 16:08:47 -0000 In article <5b55a0f8.1c69fb81.123a9.53ea@mx.google.com> you write: >-=-=-=-=-=- > >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 include only >one semicolon between the instance and the “authres-payload”; for example: “i=1; mx.example.com; …”. > >draft-ietf-dmarc-rfc7601bis You're right, that's a bug in the ABNF. The definition of instance in section 3.6 shouldn't have a semicolon because both places it's used, arc-info and arc-as-info, put a semicolon after it. I suppose we could take the semicolon out of arc-info and arc-as-info instead. >I also want to report on another form of the Authentication-Results field that I've seen in practice. It has the form: > > authserv from=domain; method=result (comment); from=domain; method=result (comment) > >where "authserv" (from what I've seen) is a domain name that always ends in "yahoo.com". Yeah, Yahoo implemented it wrong. I'll remind them when I see them at M3AAWG. R's, John From nobody Tue Jul 24 15:55:55 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC8113121F for ; Tue, 24 Jul 2018 15:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=jJzWA94h; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=tII3lH8U Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1k7x5KYAfvo6 for ; Tue, 24 Jul 2018 15:55:51 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAB48131217 for ; Tue, 24 Jul 2018 15:55:51 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 3D8BA21687 for ; Tue, 24 Jul 2018 18:55:48 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Tue, 24 Jul 2018 18:55:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=HujW4RMpg7+NSSiG0FlIwqSYDXhgu7p/csWBioAAk dI=; b=jJzWA94hG3yz4jTzGv9IBFNDS9l5X98uaildLCI9aItq7YeKO3UBrT11D Qr/Yd6sLUxkn6whhf39C8XazV/gqmLE3SFJdrUordNhUzMHukAcDXpiXLlNqtm0J lwjl7sdsxvktq3ZBc1cCImtO/TXgtRicuTJqBbjTdbLMUgjeE5UySFo1CNeuBQo0 RsLZRi4M7zSTXv/5elANXzRSx+dtXq5tY0eMqRBxHalaUV5Mg+WxaiYPlLCT+7H7 G+ZziFypht3JSsKvKGXA9hLMX1d1SuorydhTL1uSbMHx2T95EQU/tZjO3ZzF0aU5 3dyvDd69Tkad2vi13EWkvJ7cmEezA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=HujW4RMpg7+NSSiG0FlIwqSYDXhgu 7p/csWBioAAkdI=; b=tII3lH8UkPQXYBwGb/ms5x+XImI5d3PsE/Sqj3ik6tJJd fBl/E0KZuHtEisd7M6HMVx8ydO5Q1XqrURhn27Zy5r8AhlzHxYdw+0v1mpq5No79 nDq/rmePmi3iEZ8BjUAnvZfzQV6NZSJVAKmQ7RwhPSIYpawoYzTpvRbIwySxjgsq +Q5BnFTWwWP0FpRHDM9KsLT8qS3xgClFz+GWjodiOCqkxjlxdSRDeAnGgjuhuPBI TcFMvgPAAGJvu+sGT3G/nGIiAZnu1D0oSesFK8JTNiF8VsJkgsV3OVjN/Re52Kr6 dDpHlTWtA/gkkBbW8NPFJ0plqLBVTmkOLU6DdMlww== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id E76E3BA43B; Tue, 24 Jul 2018 18:55:47 -0400 (EDT) Message-Id: <1532472947.3343083.1451792120.35CD7BCD@webmail.messagingengine.com> From: Bron Gondwana To: dmarc@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153247294733430834" X-Mailer: MessagingEngine.com Webmail Interface - ajax-0843ff3e Date: Wed, 25 Jul 2018 08:55:47 +1000 Archived-At: Subject: [dmarc-ietf] Approval of draft-ietf-dmarc-arc-protocol-16 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 22:55:54 -0000 This is a multi-part message in MIME format. --_----------=_153247294733430834 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" This isn't a detailed review, because I haven't had time to do it, but I've been following the process and I'm happy that ARC-16 is ready as an experimental standard. I'm also happy with Dave's suggested improvements to the descriptive text. My general belief is that descriptive text is important, but test cases are importanter, when it comes to getting good quality implementations! Having implementations out there which have been tested against each other is part of getting interoperability, and the hackathons have been good for this, but having an experimental standard to encourage more deployment so we can collect data on real mail flows is important too. Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_153247294733430834 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
This isn't a detailed review, because I haven't had time to do it, but I've been following the process and I'm happy that ARC-16 is ready as an experimental standard.

I'm also happy with Dave's suggested improvements to the descriptive text.  My general belief is that descriptive text is important, but test cases are importanter, when it comes to getting good quality implementations!  Having implementations out there which have been tested against each other is part of getting interoperability, and the hackathons have been good for this, but having an experimental standard to encourage more deployment so we can collect data on real mail flows is important too.

Cheers,

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_153247294733430834-- From nobody Tue Jul 24 20:17:24 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E80E130F84; Tue, 24 Jul 2018 20:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6gBRjgqzCzs; Tue, 24 Jul 2018 20:17:10 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0EDE130F66; Tue, 24 Jul 2018 20:17:09 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id q129-v6so2358225ywg.8; Tue, 24 Jul 2018 20:17:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:mime-version:to:cc:from:subject:date:importance :in-reply-to:references; bh=IUiVG+MkICAFv043J5sfFKD+3xx9trjkQoCZwHWrQ7U=; b=MfKa2eaRk6zBmQ2mmmLfbQCVaaU2NgFRC1Ln66EgWC0VhQrQxMYSId8s1xruVAsEC3 ME0Jj1QGhSNYtgfDPhHj3u2qXub64QOs+i1HjoILNLlNYOPFUdFJShaEfSYj6B28bGQa S8W5/7FGH1mLFdePqejshrozKOkU0qd5miSz1H9OW22nVy2pBvlA3Q41uvSUgV+DsUk4 7lTre/TN7CvgoCySRqTbGbXJxKSmSN58l5wuanalMURT56/jPOI9fFi+1xBkxOG4ketk c5jpqpKdXf94VYsCLyKSyVGh4lue/sRUBOp9ueZQYdoKeLI5GdOo6NxmFcD7nTdImXDX PEuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version:to:cc:from:subject:date :importance:in-reply-to:references; bh=IUiVG+MkICAFv043J5sfFKD+3xx9trjkQoCZwHWrQ7U=; b=sUUuwvtjgo9MNU0YrU4q4a8lzCrIM5gq7LJqwIRTcSLHQ303L5NPqYlqVo2PMEL7rQ IgYx6hEKDgqVwsz76Z/1CP2lhEnuj6qc7d9H0oy2O1ku7Cvi5cOf9M7fCGnvo8bEF6Gj nh+l53zSDm6eMlEEELszve/2PL1LIkKlKLg2143V1g8LTs6Jkjoji8UShV4j3cF3ucEy ZVUDc0+c0LpDa+iErvfeWFKfjUjoy3opfBpIEOJWNLukgHtkPm5K+iHVa12ztZR07xSq CC1ksO2xIvL3ZXMGv/tAvedgOMOeUBhrhGSbmgVYXVlnX/YyNXF2kKl2pN4QNV2LVaAf 3TpA== X-Gm-Message-State: AOUpUlHG9XZYcyRHfkEXf8+sSy7pYuhRH5zaI30uLvVe1EOWvQ1GTu0V vPlaFg/mts44n4UgKvjv4dvBt6UXIW0= X-Google-Smtp-Source: AAOMgpc1zhkYufNhXWJy2i/Y4SryDlY3M7gG5yNyINmeqULp5NLvfJIaRgozwR6RgEAXMmS7F9amig== X-Received: by 2002:a81:e301:: with SMTP id q1-v6mr10762917ywl.499.1532488628807; Tue, 24 Jul 2018 20:17:08 -0700 (PDT) Received: from ?IPv6:2601:192:4e00:596:22:8b71:4eb9:6006? ([2601:192:4e00:596:22:8b71:4eb9:6006]) by smtp.gmail.com with ESMTPSA id n66-v6sm10660810ywn.77.2018.07.24.20.17.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Jul 2018 20:17:08 -0700 (PDT) Message-ID: <5b57ebb4.1c69fb81.6780d.c349@mx.google.com> MIME-Version: 1.0 To: "ietf-822@ietf.org" Cc: "dmarc@ietf.org" , "spfbis@ietf.org" From: Peter Occil Date: Tue, 24 Jul 2018 23:17:08 -0400 Importance: normal X-Priority: 3 In-Reply-To: <5b569cf1.1c69fb81.faa6a.8e55@mx.google.com> References: <5b569cf1.1c69fb81.faa6a.8e55@mx.google.com> Content-Type: multipart/alternative; boundary="_2FF26A6A-47FD-4B50-A24C-2E5003C5B5E4_" Archived-At: Subject: Re: [dmarc-ietf] Most common mail header fields seen with nonsyntactic values X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 03:17:13 -0000 --_2FF26A6A-47FD-4B50-A24C-2E5003C5B5E4_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Adding additional mailing lists because three header fields listed below (R= eceived-SPF, Authentication-Results, Arc-Authentication-Results) are within= their scope. --Peter From: Peter Occil Sent: Monday, July 23, 2018 11:28 PM To: ietf-822@ietf.org Subject: Most common mail header fields seen with nonsyntactic values The following is a list of email header fields where I find a significant p= roportion of those fields in practice using a different form from the docum= ented syntax of those fields. This list is, for the moment, for your information only.=C2=A0 Whether the = documents defining the header fields listed below should be updated (whethe= r to accommodate how those fields are used in practice or otherwise), or wh= at error handling a program should use if it encounters any of these header= fields, are matters that require further discussion.=C2=A0 (In one case, t= he note in RFC 5322 provides guidance on error handling, but in many other = cases, those documents don't seem to suggest or require any particular erro= r-handling behavior.) ARC-Authentication-Results. Some nonsyntactic values of this header field contain a "header.b" paramete= r value containing a slash, which cannot occur in a "pvalue". Authentication-Results. Many nonconforming Authentication-Results values are of an unusual form tha= t I've already reported elsewhere, in the "dmarc" mailing list.=C2=A0 Unlik= e most of the other forms I report here, this one may be truly nonconformin= g. Other nonsyntactic Authentication-Results values-- - don't mention the domain name of the authentication server (they generall= y have a comment like "(sender IP is ...)"), - contain a "header.b" parameter value containing a slash, which cannot occ= ur in a "pvalue", - contain an "x-tls.subject" parameter right after the authserv name (which= only one specific implementation apparently generates), and/or - contain "d=3D" or "reason=3D" after the form "=3D= (comment)", which doesn't conform to the documented syntax. Content-ID. Of the Content-ID header fields I've seen in practice, a significant propor= tion of them (almost half) do not follow the syntax of "msg-id", even thoug= h they contain angle-brackets.=C2=A0 Some examples use UUIDs inside angle-b= rackets rather than "msg-id"s with an at-sign, while other examples, such a= s "" and "", were obviously generated to be messag= e-unique rather than "world-unique" as required by RFC 2045 sec. 7.=C2=A0 (= On the other hand, I see very few instances of Message-ID header fields not= following the syntax of that header field.)=C2=A0 A smaller number of fiel= ds do not use angle-brackets at all, and some of them include the values "h= tml-body" and "text-body". List-Archive. All of the nonsyntactic List-Archive values I've seen so far involve GitHub= URLs.=C2=A0 Here the URL appears without angle brackets. List-ID. Some List-ID values either include no dots or domain names, or they are num= bers or underscore-separated number sequences with no angle-brackets. List-Unsubscribe. Many nonsyntactic List-Unsubscribe values involve either URLs not appearing= in angle brackets, or URLs encoded with RFC 2047 encoded words (compare wi= th Content-Location, which does allow the latter). Received. Many nonsyntactic Received bodies-- - include fractional seconds in the date and time, - include unquoted IPv6 addresses (which contain colons and don't conform t= o the "received-token" syntax),=20 - have no semicolon before the date/time, and/or - include a "for" clause containing "" (without the qu= otation marks). In one case, I have noticed a Received header field with an ASCII control c= haracter (U+0001, I think) in the "by" clause; unfortunately such a field i= s not downgradable under RFC 6857, nor can it appear in a generated header = field under RFC 5322. Received-SPF. Many nonsyntactic Received-SPF bodies include an unquoted IPv6 in the "clie= nt-ip" parameter (which conform to neither "dot-atom" nor "quoted-string" b= ecause of the colons), and some include an unquoted email address in the "e= nvelope-from" parameter. Return-Path. Many Return-Path header-field values don't include angle brackets (and appe= ar as "addr-spec", rather than "path" as required by RFC 5322.)=C2=A0 A ver= y small number also include a display name (and appear as "mailbox" under t= hat RFC). ------- For other standard header fields, nonconforming values occur very rarely if= at all (in my experience). --Peter --_2FF26A6A-47FD-4B50-A24C-2E5003C5B5E4_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

Adding additional mailing lists beca= use three header fields listed below (Received-SPF, Authentication-Results,= Arc-Authentication-Results) are within their scope.

 

--Peter

 

From: Peter Occil
Sent: Monday, July 23, 2018 11:28 = PM
To: ietf-822@ietf.org=
Subject: Most common mail header fields seen with nonsyntactic v= alues

 

The following is a list of email header fields where I find a significan= t proportion of those fields in practice using a different form from the do= cumented syntax of those fields.

&n= bsp;

This list is, for the moment, for your i= nformation only.  Whether the documents defining the header fields lis= ted below should be updated (whether to accommodate how those fields are us= ed in practice or otherwise), or what error handling a program should use i= f it encounters any of these header fields, are matters that require furthe= r discussion.  (In one case, the note in RFC 5322 provides guidance on= error handling, but in many other cases, those documents don't seem to sug= gest or require any particular error-handling behavior.)

 

ARC-Authenticati= on-Results.

 

Some nonsyntactic values of this header field contain a "= ;header.b" parameter value containing a slash, which cannot occur in a= "pvalue".

 

Authentication-Results.

 

Many nonconforming Authent= ication-Results values are of an unusual form that I've already reported el= sewhere, in the "dmarc" mailing list.  Unlike most of the ot= her forms I report here, this one may be truly nonconforming.

 

Other nonsy= ntactic Authentication-Results values--

=  

- don't mention the domain name o= f the authentication server (they generally have a comment like "(send= er IP is ...)"),

- contain a "= header.b" parameter value containing a slash, which cannot occur in a = "pvalue",

- contain an "x= -tls.subject" parameter right after the authserv name (which only one = specific implementation apparently generates), and/or

- contain "d=3D<pvalue>" or "reason=3D&l= t;pvalue>" after the form "<method>=3D<result> (co= mment)", which doesn't conform to the documented syntax.

 

 =

Content-ID.

 

Of the Content-ID header field= s I've seen in practice, a significant proportion of them (almost half) do = not follow the syntax of "msg-id", even though they contain angle= -brackets.  Some examples use UUIDs inside angle-brackets rather than = "msg-id"s with an at-sign, while other examples, such as "&l= t;example.jpg>" and "<down_arrow>", were obviously = generated to be message-unique rather than "world-unique" as requ= ired by RFC 2045 sec. 7.  (On the other hand, I see very few instances= of Message-ID header fields not following the syntax of that header field.= )  A smaller number of fields do not use angle-brackets at all, and so= me of them include the values "html-body" and "text-body&quo= t;.

 

List-Archive.

 

All of the nonsyntactic List-Archive values I've seen= so far involve GitHub URLs.  Here the URL appears without angle brack= ets.

 

List-ID.

 

Some List-ID values either include no dots or domain name= s, or they are numbers or underscore-separated number sequences with no ang= le-brackets.

 

List-Unsubscribe.

&n= bsp;

Many nonsyntactic List-Unsubscribe value= s involve either URLs not appearing in angle brackets, or URLs encoded with= RFC 2047 encoded words (compare with Content-Location, which does allow th= e latter).

 

Received.

 =

Many nonsyntactic Received bodies--

=

 

- include fr= actional seconds in the date and time,

-= include unquoted IPv6 addresses (which contain colons and don't conform to= the "received-token" syntax),

- have no semicolon before the date/time, and/or

- include a "for" clause containing "<multip= le recipients>" (without the quotation marks).

 

In one case, I hav= e noticed a Received header field with an ASCII control character (U+0001, = I think) in the "by" clause; unfortunately such a field is not do= wngradable under RFC 6857, nor can it appear in a generated header field un= der RFC 5322.

 

Received-SPF.

 = ;

Many nonsyntactic Received-SPF bodies inclu= de an unquoted IPv6 in the "client-ip" parameter (which conform t= o neither "dot-atom" nor "quoted-string" because of the= colons), and some include an unquoted email address in the "envelope-= from" parameter.

 <= /p>

Return-Path.

 

Many Return-Path header-field values= don't include angle brackets (and appear as "addr-spec", rather = than "path" as required by RFC 5322.)  A very small number a= lso include a display name (and appear as "mailbox" under that RF= C).

 

-------

 

For other standard header fields, nonconforming values occu= r very rarely if at all (in my experience).

 

--Peter

 

 

= --_2FF26A6A-47FD-4B50-A24C-2E5003C5B5E4_-- From nobody Wed Jul 25 11:57:37 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE7BB130EBB for ; Wed, 25 Jul 2018 11:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6AgGafJGbcVa for ; Wed, 25 Jul 2018 11:57:33 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7F91129385 for ; Wed, 25 Jul 2018 11:57:32 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id b22-v6so6153056lfa.3 for ; Wed, 25 Jul 2018 11:57:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=S0NbC3IuORT3RzU2sC1EhQAVmnG3WamxIf1148EzlCE=; b=Qqd9BngT+PgwrtCI3SqclKlYJo75iMX3O2tIhT/47cubCmTraID3A+yl3cc8PEq9OH 9F3jBR9cGJ1fW2riWzMfzCiGZEx441j8N7RZJ633cWPQXsd+uJGdumDNvdzeUscpAA1q WkWNoPBYJ1MbV45YR+pKb9bWMM0mFGo9L/VOR+J1i55xwrkVzmWrm4psSZ8TI+pK7kGw R9ahL3hqsIgK0Zp+U/9dqVfV83WCnaRppJFvN4tPFz0+2FR6xhV2gyri5l9aeH2eUWPK dxsMDxOqU05D1uFIyeCu7Wxk38kTpbGPh+bee2tKhhaeXojbk4oCkJ+FBhogsVUNSS7B YLGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=S0NbC3IuORT3RzU2sC1EhQAVmnG3WamxIf1148EzlCE=; b=CF9PQVv9PFHar9ZnQJrYjhkJ2NN+cIb/GYLXcWgEQahQY9b0M8DwbmyjKDr9v1riwq jpRCM5fPL0RjJR3Ienxt3i+ZooCj1+iCfuQnaAwRf7TrSkxaENLKWBSFM0CwnVQDVeHC eZQFm3MYDDnGWOH5n22e+TKZF6moPZW80QJye6T7aFj76SRkYpPZJJlPLPptIrMKhPVX 1ixNBdG/5g2lW9A5c7VPbjv+dKnrTBIL3dxylYHbVX/kQ+VFogdhxS7w0bDUpw5fl5bq HVcbi51GA3+NGn7NBeijpusRyi8H5+TL6Ghhf0Mh5ejFOytotm7sjDrrX7Lsmw8c5o7w Iyjw== X-Gm-Message-State: AOUpUlFX5IeqDkQvTIGz/QDMQ7zARE4J+XDRHbj58HuvnurAkDMMxoFw TtyV5RDBAKrBTfIhES7uBDARqV3oz5/IUsiqhtzH/A== X-Google-Smtp-Source: AAOMgpcGslHnBh9cBKz0vo87SlUesq0XX4uGyjT5HC7HRHJ6O0RZbnT9HdFfnW9w+3aFCyBPd8jBofM26/yS9aySm+I= X-Received: by 2002:a19:e1cc:: with SMTP id l73-v6mr14223093lfk.102.1532545050928; Wed, 25 Jul 2018 11:57:30 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:3a13:0:0:0:0:0 with HTTP; Wed, 25 Jul 2018 11:57:30 -0700 (PDT) In-Reply-To: <1532472947.3343083.1451792120.35CD7BCD@webmail.messagingengine.com> References: <1532472947.3343083.1451792120.35CD7BCD@webmail.messagingengine.com> From: "Murray S. Kucherawy" Date: Wed, 25 Jul 2018 11:57:30 -0700 Message-ID: To: Bron Gondwana Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000005ceb5f0571d773e7" Archived-At: Subject: Re: [dmarc-ietf] Approval of draft-ietf-dmarc-arc-protocol-16 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 18:57:35 -0000 --0000000000005ceb5f0571d773e7 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 24, 2018 at 3:55 PM, Bron Gondwana wrote: > This isn't a detailed review, because I haven't had time to do it, but > I've been following the process and I'm happy that ARC-16 is ready as an > experimental standard. > What's an "experimental standard"? -MSK --0000000000005ceb5f0571d773e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 24, 2018 at 3:55 PM, Bron Gondwana <br= ong@fastmailteam.com> wrote:
This isn't a detailed review, bec= ause I haven't had time to do it, but I've been following the proce= ss and I'm happy that ARC-16 is ready as an experimental standard.
<= /div>

What's an "experimenta= l standard"?

-MSK
--0000000000005ceb5f0571d773e7-- From nobody Wed Jul 25 12:36:11 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3655130E7D for ; Wed, 25 Jul 2018 12:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=LU5ofZQu; dkim=pass (1536-bit key) header.d=taugh.com header.b=XWiDxhF6 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4UrNw4BrV8X for ; Wed, 25 Jul 2018 12:36:04 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5E8A130DD8 for ; Wed, 25 Jul 2018 12:36:03 -0700 (PDT) Received: (qmail 53786 invoked from network); 25 Jul 2018 19:36:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=d218.5b58d122.k1807; bh=J4pSCRo+5eLWtYxUXj6GaspkaaTxHlWzP/eeYwRX148=; b=LU5ofZQu+UhH9DVGwC0qjsZyyRSnoC9AV5hi/YKQl/HghxuWSQpa5Si363gX/psFcOYQNOrSCDa+aq0sYLgV1TrGCx5nMev3zp1Vu1xNzeXrsg9ZOfeu3jtwd7S2bRbuq8wqAgcvYqqaal5WBouUHJeGd/lahbTfNVc9k7BHMlJhgJlYjDTAXjk5A/uQKFO49L1uS8fe0tntXj2XiYy8rnUSsB5RKQAdbEMYHVOo4jzJexG2N6lGfgKorXQ2vN0H DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=d218.5b58d122.k1807; bh=J4pSCRo+5eLWtYxUXj6GaspkaaTxHlWzP/eeYwRX148=; b=XWiDxhF6mM5u4bCGNlcgTXlNHfqDn50j1WlnkYSsrrGgQeoHEa6yt1nnr90ubx9A03Otj6y5IG/vxX3+AHactTpXGsjheloUaw37phznw+nZ1FyNw+EO60oUOq/Rl8h67fJcLhO4G641A/PCVRhdRK2609h4pjCNVf+zI0AWvAI/uCEHPUydsM9LUMM2rJ8E9gxWz6iuHjWjTyLLjEmquIiqUjh0Mi+vWi0pr+65vAiRqAnb8cubhEjUhFpQ7KIo Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 25 Jul 2018 19:36:02 -0000 Date: 25 Jul 2018 15:36:01 -0400 Message-ID: From: "John R Levine" To: dmarc@ietf.org User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: [dmarc-ietf] [Technical Errata Reported] RFC7489 (5440) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 19:36:10 -0000 Something I noticed in a conversation on mailop. ---------- Forwarded message ---------- Date: Wed, 25 Jul 2018 15:26:57 From: RFC Errata System To: superuser@gmail.com, zwicky@yahoo-inc.com, rfc-ise@rfc-editor.org Cc: johnl@taugh.com, rfc-editor@rfc-editor.org Subject: [Technical Errata Reported] RFC7489 (5440) The following errata report has been submitted for RFC7489, "Domain-based Message Authentication, Reporting, and Conformance (DMARC)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5440 -------------------------------------- Type: Technical Reported by: John Levine Section: 7.1 Original Text ------------- containing at least "v=DMARC1" similarly in three places in B.2.3: "v=DMARC1" Corrected Text -------------- containing at least "v=DMARC1;" similarly in three places in B.2.3: 'v=DMARC1;' Notes ----- The ABNF of dmarc-record in section 6.4 says that there has to be a semicolon after v=DMARC1, but several of the examples for the _report._dmarc record are missing the semicolon. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7489 (draft-kucherawy-dmarc-base-12) -------------------------------------- Title : Domain-based Message Authentication, Reporting, and Conformance (DMARC) Publication Date : March 2015 Author(s) : M. Kucherawy, Ed., E. Zwicky, Ed. Category : INFORMATIONAL Source : INDEPENDENT Area : N/A Stream : INDEPENDENT Verifying Party : ISE & Editorial Board From nobody Wed Jul 25 13:54:32 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA8D0130ED9 for ; Wed, 25 Jul 2018 13:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeGH48QdioWv for ; Wed, 25 Jul 2018 13:54:11 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93819130E9C for ; Wed, 25 Jul 2018 13:54:11 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id n84-v6so16346037oib.9 for ; Wed, 25 Jul 2018 13:54:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=x692GY9XSk/DyBbcv/K+Tugfv4HS69sewn7QfoxFQno=; b=Ur0kSgLOkgrP9SC3HoqFbeIslm206sOxb25HRDzgzEcs5bjsG3Lkda8qUv5j4QH7+I R8aKbqdSm+TPhnne/FxRTG2yyAYly06wZRiXlWvQWnG2n3aTfjiUY4qVp7u489ZVtWdg pnC2weBwrgEkDvt6OlCYj/W7ZYKdRLW4JqIdbQmIzlAd8GCmVbppIMK0HWSKC2IACiNh ZzDnpjKIV8UtK8JmfoSIB9gi0pqMK1HMHCJXuefGN7tkya1EpMixqaPR6/eWiAtVxmsj ReyLYRgpFQKskO/rqHdW+UllVscH17VXEEhsmf1PEjiCHrp0q9G/Srdy7tnjBc7htZW2 EiAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=x692GY9XSk/DyBbcv/K+Tugfv4HS69sewn7QfoxFQno=; b=VsKKLjJT/d2t3ps7O1Q2ZMZYS18mKZ2sN+7zatvHW83gVem53wQREq/SFqlDblImX2 E2l0+47Ncr5SFZA7G64CxiBm86acpnOY/A8gvRsqd9SwamFxTNm8k1SaDO5z5j1/1SDM woymeJj+kZrgqhAlgA4xKFSmMwTbozrInNiVYBqmeP/sDUEBqvGmqkmc7CtHpEXHRwqa WKjw1vUqnHuwlQTxsS5ipGGiBqwDELORmyoDDZIhyiYhau3lTtIhFb8ZXNwqprn/mF3x LEUUuiqNwIcGMblEISFl62OyyDz6QPZK6nt+QsvazNi7W4OPBM1l5JmSCbo2cZ/YzBAw WbwA== X-Gm-Message-State: AOUpUlH78y61YWnwoJOcpRe6WKQSOWddydsHZUDesFKwdjuoHXgVVoQn RlCjA+CSm0hBem3eHDKqx/UJ8Csn8Ncf2Iyd0XDk/N/+Nzc= X-Google-Smtp-Source: AAOMgpevE/gX8PeW6sZ3+jMJfGBe8CIkFvxPo7Zi53fzOI4MoTxzt6jqDj4CfsKmxrj98kOLlgKOkWnS/UrJ6/Sjdn4= X-Received: by 2002:aca:b355:: with SMTP id c82-v6mr5378353oif.9.1532552050570; Wed, 25 Jul 2018 13:54:10 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:2646:0:0:0:0:0 with HTTP; Wed, 25 Jul 2018 13:53:50 -0700 (PDT) In-Reply-To: <5b55a0f8.1c69fb81.123a9.53ea@mx.google.com> References: <20180723000558.CD758B80F99@rfc-editor.org> <5b5539e6.1c69fb81.b4b6d.5477@mx.google.com> <5b55a0f8.1c69fb81.123a9.53ea@mx.google.com> From: Seth Blank Date: Wed, 25 Jul 2018 13:53:50 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009311490571d91460" Archived-At: Subject: Re: [dmarc-ietf] Comments on certain drafts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 20:54:22 -0000 --0000000000009311490571d91460 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 23, 2018 at 2:33 AM, Peter Occil wrote: > draft-ietf-dmarc-arc-protocol > > > > The production =E2=80=9Carc-info=E2=80=9D includes a semicolon after =E2= =80=9Cinstance=E2=80=9D, which in > turn has a semicolon at the end. However, a great number of > Arc-Authentication-Results header fields I=E2=80=99ve seen in practice in= clude only > one semicolon between the instance and the =E2=80=9Cauthres-payload=E2=80= =9D; for example: > =E2=80=9Ci=3D1; mx.example.com; =E2=80=A6=E2=80=9D. > Great catch, thank you. Fixed. --0000000000009311490571d91460 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Jul 23, 2018 at 2:33 AM, Peter Occil <poccil14@gmail.com> wrote:

draft-ietf-dmarc-arc-protocol

=C2=A0

The productio= n =E2=80=9Carc-info=E2=80=9D includes a semicolon after =E2=80=9Cinstance= =E2=80=9D, which in turn has a semicolon at the end.=C2=A0 However, a great= number of Arc-Authentication-Results header fields I=E2=80=99ve seen in pr= actice include only one semicolon between the instance and the =E2=80=9Caut= hres-payload=E2=80=9D; for example: =E2=80=9Ci=3D1; mx.example.com; =E2=80=A6=E2=80=9D.


Great catch, thank you. Fixed.=C2= =A0
--0000000000009311490571d91460-- From nobody Wed Jul 25 13:54:49 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF9F130EC6 for ; Wed, 25 Jul 2018 13:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MxHBf2f_VWcg for ; Wed, 25 Jul 2018 13:54:43 -0700 (PDT) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 017AD130E9C for ; Wed, 25 Jul 2018 13:54:42 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id l16-v6so6348538lfc.13 for ; Wed, 25 Jul 2018 13:54:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=///v8Jsn5jGBKtFk4aL80rfuyBglYE+H7i2ITc0BJN8=; b=ucprG8DpLOF30GLJO8EcsBAVz6R1+jM6Ya2eKNFjMl8C+fUFSr46/w7dQeq0Mv/pHq Z8AFgu8CFi/reOHyuPx3ItcQYBT49c25OcV+KFiuI4lmM2EzSWjZBJFoVv6ryJWioUD9 3De5PgacHFuCQ+1DMUZchHRSE/PkSKi0Gjf6yGQSpT85tBK1JtTIpAupKZBeQXTyBb7g nKEGZBgn5mt7qmYR3zUZ4FBSxwbrGuE2moiCMitVDY1n+Zddhlq2gv6oT0iYk8qpEIj+ TGuRmi3UwyL4cYJW/O75sSuKHSIULCXYKbzMXRXP3k05ry0+/9IqNdA3H1YvuBynJRyY M9pQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=///v8Jsn5jGBKtFk4aL80rfuyBglYE+H7i2ITc0BJN8=; b=BcvzSu1Afts3L85YowFKJ+OLfTcSkja0S7UsxUmzdp9mICxmGfRS/rXAknH9G0VCKr KZrTWztqTiabFEUGR0Uwy9scWZFuB24rZ8e5uVKkZKBUEPJAcLfcqhypG54kge8go/Mq C1bzMStQkDQlYChR1Yr92Q/ckyDJPt8m/bvpVlS+lvIYLiSXTj8wFBfm4DZczkMHqjVm q7+8SQqObTCbpJ9Ql/7jvcM/jlWeW31u4909mpKeW37YqeczEPJfu7HADUHD9Pwelt2s 3Lwnags/lAaF8TNSU+OiyWM9wE+3oavrdKmLl1YaEd046Qn1/gcKNgfXHqal8s3BpH51 BNIw== X-Gm-Message-State: AOUpUlGCwcb/9QE8UsaFIAQmgHwmUkk7h6sW6BderKsSmXwpyRQmLo5b f+ZTFUnqD92xuAYjEtwRDT3s09EHRuPuRl0itWs6Og== X-Google-Smtp-Source: AAOMgpd0UyGUzLyl7tk3n3MJD4i6nSdNr/oSi9RnRuoz5eIqHL25Cr9Cgs+1AWraMWxe7hgDSX9KzKdUwF/BBNPpLqA= X-Received: by 2002:a19:e1cc:: with SMTP id l73-v6mr14414662lfk.102.1532552081131; Wed, 25 Jul 2018 13:54:41 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:3a13:0:0:0:0:0 with HTTP; Wed, 25 Jul 2018 13:54:40 -0700 (PDT) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Wed, 25 Jul 2018 13:54:40 -0700 Message-ID: To: John R Levine Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000654d3c0571d9162b" Archived-At: Subject: Re: [dmarc-ietf] Sort of erratum on RFC 7601 for 7601bis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 20:54:47 -0000 --000000000000654d3c0571d9162b Content-Type: text/plain; charset="UTF-8" Applied for RFC7601bis. I'll post a new version when WGLC ends. On Sun, Jul 22, 2018 at 7:07 PM, John R Levine wrote: > An erratum on RFC7601 just appeared that reports a bug in the ABNF for the > resinfo rule. I think the purported bug is not a bug but his suggested > rewrite to the ABNF is cleaner than what's there now. > > https://www.rfc-editor.org/errata/eid5435 > > Regards, > John Levine, johnl@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/listinfo/dmarc > --000000000000654d3c0571d9162b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Applied for RFC7601bis.=C2=A0 I'll post a new version = when WGLC ends.

On Sun, Jul 22, 2018 at 7:07 PM, John R Levine &l= t;johnl@taugh.com&= gt; wrote:
An erratum on RFC7601 j= ust appeared that reports a bug in the ABNF for the resinfo rule.=C2=A0 I t= hink the purported bug is not a bug but his suggested rewrite to the ABNF i= s cleaner than what's there now.

https://www.rfc-editor.org/errata/eid5435

Regards,
John Levine, johnl@tau= gh.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/listinfo/dmarc

--000000000000654d3c0571d9162b-- From nobody Wed Jul 25 14:12:49 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B559F130EC9 for ; Wed, 25 Jul 2018 14:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPEgDGJQWJG4 for ; Wed, 25 Jul 2018 14:12:45 -0700 (PDT) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DBF7130D7A for ; Wed, 25 Jul 2018 14:12:45 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id l16-v6so6379376lfc.13 for ; Wed, 25 Jul 2018 14:12:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=o1kvg0hrz6EIV6DR7vozklngYbn+tEugMU66Tx+wo3c=; b=XsJ7VN6u7G2CaKCuE8qvW1OYjSt5hJfwZmRkVVfCA8IIPOD3HHTF1PX6/m2STwlbZP jcsFjK7UjevBWDnQMVxjCkNMH9CRt2Y4AiwQPObb+zHqS/yW4zpy0F6XxpkfrD6kN+yO 5KCutGJ8NYQ6eswyyS1IqywR7Y5tSPQ+QYtrJW+mutVEUDtzwk/5wXEvV+IcffMwlR1V v1CM+vq4VGvbPhus6HbWoXXsK8VuugVPOo5PGBRzJPD1J6sqDCU22F6Czw3h6m4uqKV/ A1fB+JEdr7co2gCrmq0bQLLjMH5DTij1FWtmIDCNpDIrAlZUANFBIV/sg8v26UMr5Gn2 yFFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=o1kvg0hrz6EIV6DR7vozklngYbn+tEugMU66Tx+wo3c=; b=PS7afj0OK1Jk1LCVeJuQgQ7mTmhq7JAm+twHJs2JinzZqz+GAN2NB44VAzDFkPh9Fo mvF0m8GSNKmEuSN7F6RdwjaBMItkrf+B3tErbKSRBEy1XUYlrVH+8YFUTlRsGf9s6He8 aJ+bXyN4JVlf+L4lCnH3+OaxtBmryr/zdie9B2uWsJcvajjPb0QiNMAEeQjYNqfon4rP 5xaHGktRTAGB0d6Ni/GXNz/4GBbTRVFgbza+ZNtQzBCQuHjpc4gjtF0EY+677kNBOAdo XHsrq/NPJuQ3h9WAZC9taMTfA3VFQJQxfCrrwTjSiEymwQT2TZzKS0mT3Tj/HONPw1Jy XBvA== X-Gm-Message-State: AOUpUlGtVD6CQDJssYtXPQ8vX8zSgblJ+H+3qsfE4EuyUhkbZckuAIlA phTKSCzr7TeD5ThHE+tl2pWVGM6YuwzJDbuhFY81ZJFB X-Google-Smtp-Source: AAOMgpcawuZZxly3Lg31D2rcUJ7mIOn2XMmm5MgwupTB/z81B4X9tL1MuewG8baQfvLFijhTbjwuDk/NsRdfE4mJLCU= X-Received: by 2002:a19:6801:: with SMTP id d1-v6mr14083883lfc.8.1532553163434; Wed, 25 Jul 2018 14:12:43 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:3a13:0:0:0:0:0 with HTTP; Wed, 25 Jul 2018 14:12:42 -0700 (PDT) From: "Murray S. Kucherawy" Date: Wed, 25 Jul 2018 14:12:42 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000e7eee30571d95658" Archived-At: Subject: [dmarc-ietf] OpenARC and draft-ietf-dmarc-arc-protocol-16 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 21:12:48 -0000 --000000000000e7eee30571d95658 Content-Type: text/plain; charset="UTF-8" I've pushed a new release of OpenARC that's based on the normative stuff in -16: https://github.com/trusteddomainproject/OpenARC/releases/tag/v1.0.0.Beta0 It's missing API documentation, but I plan to provide a full set of that before v1.0.0 goes out. The documentation for the filter itself should be complete, however. If anyone is looking to do interop testing to confirm stuff that's in the spec, let me know and I can provide whatever support is needed. -MSK --000000000000e7eee30571d95658 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've pushed a new release of OpenARC that's based = on the normative stuff in -16:

= It's missing API documentation, but I plan to provide a full set of tha= t before v1.0.0 goes out.=C2=A0 The documentation for the filter itself sho= uld be complete, however.

If anyone is looking to do interop testing= to confirm stuff that's in the spec, let me know and I can provide wha= tever support is needed.

-MSK
--000000000000e7eee30571d95658-- From nobody Wed Jul 25 14:34:30 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 583F31277C8 for ; Wed, 25 Jul 2018 14:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtM_wXSir459 for ; Wed, 25 Jul 2018 14:34:25 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C14612777C for ; Wed, 25 Jul 2018 14:34:25 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id y207-v6so16509723oie.13 for ; Wed, 25 Jul 2018 14:34:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=qQuINTFCGWK/qYWp788cQAl5Lbv33kkgvm0+s53QirY=; b=lcm43fabB2NaYdN0eRVFAtZIZ7DyAM6eoo+hWEpUUvFrCLKPTpty1LxVQSYfzgz4du uXxbE0hCIQGTjTmI6iyEJ77yquP/xxfkaqbh7d1a7kzAI0Dd45WF77gL8TV3yLCbQLke I1gAhyKhAtvKrMBWJqJLV4SKiYg/Q5QLa8e666AXLw1kZxE7Kw6ELVlss93cCuWrSMo3 TaqMQySVZwAQS0kKIPtW344bX68cnRDnRQRN+8nXg66qZULgmBPp0ymvEnC8Ne9KzQiR P8XSH//8DJXyfxVhg4g4N5st9Co/D18ABXkiIO/vY70exQMKt0uf/iDwT2vKUxLbgHda /bnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=qQuINTFCGWK/qYWp788cQAl5Lbv33kkgvm0+s53QirY=; b=N3sTGkM+6x/inm/OplMalhjS7PvYuM4KSKwO5ABC9BThXr9YXQdI+iNFNzksvQ6Zjs bUB6rlwbHSGACxs+1Tog9BGOs6Q/RTsu4MdaYwagDbs90K3Nneo+VX8E+A2hDI78yQp3 rzdgQvzXEWhu4kuWbzuKfRw0XcZj5HxX49GFAtfO8USHugGqqGbgvGtxUOv1K/uGfCW8 H9mPhkPujppQB+sBpQKOVkp9nydQdbA2aXEov0bv0kQg+pjfgFOwz313LAwaG7bndgEm DVDfzA/zU9/DoTtRDAUn07osqD960XRdELLKVyuis4r+k2/JRiJC9fkWDrKKYQdJRCrg MQtg== X-Gm-Message-State: AOUpUlFvBz+Y3xmpxxfP5HQHSzH+xl1rpHmZN1jpYPU6phmHUSOHEIL8 lbhTgoQWIqRyYPb7gIrXAJyvZgyi9PgpQT4NaIgTOjPBiQ/PsA== X-Google-Smtp-Source: AAOMgpfsnnsOapGYHP72NbhPxKufXSWoVPnru7IDdEMyJFOo6pRs4c9gbksWohFTnkZnbSIEdWko9i1wkX7dNrggWbs= X-Received: by 2002:aca:d088:: with SMTP id j8-v6mr5343917oiy.276.1532554464206; Wed, 25 Jul 2018 14:34:24 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:2646:0:0:0:0:0 with HTTP; Wed, 25 Jul 2018 14:34:03 -0700 (PDT) From: Seth Blank Date: Wed, 25 Jul 2018 14:34:03 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000070476e0571d9a441" Archived-At: Subject: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 21:34:29 -0000 --00000000000070476e0571d9a441 Content-Type: text/plain; charset="UTF-8" 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 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 definition of invalid). We then decided to abandon the cv=invalid path and only have cv=fail. Somehow, in the current doc this advice for invalid chains now applies to all chain failures. Section 5.1.2's title even mentions it is for the invalid case, but the text as written applies to all failed chains. Without the ARC Seal 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. 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. I believe the proper text for this section (replacing the first paragraph for 5.1.2 in its entirety) should be: In the event that it is not possible to generate a deterministic list of previous ARC Sets to sign (such as when the chain undergoing validation is structurally invalid), the signature scope of the AS header field b= value MUST only include the latest ARC Set headers as if this newest ARC Set was the only set present. --00000000000070476e0571d9a441 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
https://tools.ietf.org/html/draft-ietf-dmarc-a= rc-protocol-16#section-5.1.2

Originally, even in= the event of a chain validation failure, the Sealer's ARC-Seal would s= ign all ARC header fields on the message.

When we = introduced the concept of cv=3Dinvalid last year, the advice was to only si= gn your own ARC Set, because there was no deterministic way to know which h= eader fields to sign when those ARC header fields were not properly intact = (the definition of invalid). We then decided to abandon the cv=3Dinvalid pa= th and only have cv=3Dfail.

Somehow, in the curren= t doc this advice for invalid chains now applies to all chain failures. Sec= tion 5.1.2's title even mentions it is for the invalid case, but the te= xt as written applies to all failed chains.

Withou= t the ARC Seal 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 la= test signature.

The proper guidance should be that= the ARC-Seal MUST sign the ARC Chain in its entirety, unless that is struc= turally impossible, in which case it should only sign itself.

I believe the proper text for this section (replacing the f= irst paragraph for 5.1.2 in its entirety) should be:

=C2=A0 =C2=A0In the event that it is not possible to generate a determin= istic list of previous
=C2=A0 =C2=A0ARC Sets to sign (such as whe= n the chain undergoing validation
=C2=A0 =C2=A0is structurally in= valid), the signature scope of the AS header field b=3D
=C2= =A0 =C2=A0value MUST only include the latest ARC Set headers as if this new= est ARC
=C2=A0 =C2=A0Set was the only set present.
--00000000000070476e0571d9a441-- From nobody Wed Jul 25 14:46:28 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98FFD12F1A6 for ; Wed, 25 Jul 2018 14:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=uniregistry.link Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MOnsTWZB9M9 for ; Wed, 25 Jul 2018 14:46:26 -0700 (PDT) Received: from a.mx.uniregistry.net (a.mx.uniregistry.net [64.96.34.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32F371277C8 for ; Wed, 25 Jul 2018 14:46:26 -0700 (PDT) Abuse: Forward to abuse@uniregistry.com with full headers X-Virus-Scanned: Content filter at a.mx.uniregistry.net Powered-By: https://www.uniregistry.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uniregistry.link; s=bravo; t=1532555185; bh=dY2M5vvArNIXZ4bnykSw7wNur5h0zY2WHjXDQ7urc2k=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=GbRTiQsN98VPBUrHPT1k3zYLRlp/t5Cl0MGVm2KFVNpKcTUJlhVu98RW1vzy2r+NA 6jQFCy0OurnrDFeQoWNKvr8uyh2o3mgmtvf5pE6CpIH9RBldMsLqNHn8mz+00gfEPO UGWMq/BfsuTXPI5RHX4sp1MnYyZs/bkxTQ1dFeJRAqsyk/1pF5WMtRrYxjuk3g/ykj B89oNQkzYEl/RXjgVprq6/as83ebXthQCunPAtCY+OQSicEKBLvAu8gD7xGMvkXREh eKNeakj8qmdmwXIQK3HG9jGUB1CYnQnVBiqLEzVKl69+pgmri/cS9wlJqCPg3NKfLG fFnwqWD3dMe8Q== Received: from [64.96.164.206] ([64.96.166.230]) (authenticated bits=0) by a.mx.uniregistry.net (8.15.2/8.15.2/Debian-8) with ESMTPSA id w6PLkP4s001730 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 25 Jul 2018 21:46:25 GMT From: "Luis =?utf-8?q?Mu=C3=B1oz?=" To: "Seth Blank" Cc: "IETF DMARC WG" Date: Wed, 25 Jul 2018 14:46:24 -0700 X-Mailer: MailMate (1.11.3r5509) Message-ID: <33404ED3-6683-4802-8223-78AFBACA7805@uniregistry.link> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown Archived-At: Subject: Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 21:46:28 -0000 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 above were taken. -lem From nobody Wed Jul 25 14:47:09 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D63B12F1A6 for ; Wed, 25 Jul 2018 14:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TXX755LLkmn for ; Wed, 25 Jul 2018 14:47:05 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82B651277C8 for ; Wed, 25 Jul 2018 14:47:05 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id s198-v6so16584418oih.11 for ; Wed, 25 Jul 2018 14:47:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=n7X5CQF22913m9ovhLGUfZaUTyvJBdR3trS3AHAFBXY=; b=M/MtsBqPk+C3MFO8O3mFoT4k9tQi+6ckEu8j3jETwwXfelC9BnLbsZ0jCdgHue/W+e IRRzAy9v8QJPqWPpanVXfD7tgQfoTQlgXmD+KlQD6ZR0iali8nYYAbrHJszO2Cb+IAbW RQUBZsfb9hQzOZoMrQmKzYGyafc0EDPLrhu1QUMZQYx/+wuzmLTRRqrJjEqDeSXfZlN3 hKuY3GcUo50iWhoTGZGHyBVARIAJm6KcGAbuxdXOKd8lG5bTl5qpqcWabR146s2z7IiX 3hsY9TtxdFZ9DxtsQ9BH4iCC3neoclfWAya5N1+gP7keVP5E919l7+Z1kI/fTXGZzff6 7qyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=n7X5CQF22913m9ovhLGUfZaUTyvJBdR3trS3AHAFBXY=; b=k5odu6vnmYTMnXT1D3b8WA7YjPu6GgZsDlLx42aeO0hTMvKA2scEu+eLv0Ifc8qkJy uJFiN/hD78cQVlnTQCTrDm1jo8m58zIa90yEi5Fn4L6qbEvGWlolDWKoyRhVLRdaFl/c iWSQ+z5np9JzKM6ZkPXxHWjEcU/dAMPrEm0CWsFDFUst7juUUtKCfXWUui38ssKls6yE Bl9JxjjWvdN/JpLPpylhDUiAgVRrvLVpgf0ZV+RU7s84808sD+jmKhZaIHHEr7rFCQ/p nx0GObMqg2q6AUbKNbSYjw2MVtWmvUWkhnYBq/fCsDpHoL0++HjNO1UIEuU8qgGj/nH7 5Vqg== X-Gm-Message-State: AOUpUlFf2Yv7cam3B4yWUUxzgQZ0r545FFe3qISHX/GYsCfvuUeWHEUe IjvlMFSuZ2h0rCN+4bDODL89YlQ9it9sdqb8wjJ/bO9g7OGPBQ== X-Google-Smtp-Source: AAOMgpdLx+mrkf/mfHOwgM2dXOxnyGCt7ZhaSQskwjiOjd8cx64vKc+amE5MZTS5DzBqkqda4ZKCJQdhJiJuZG2ANgs= X-Received: by 2002:aca:b355:: with SMTP id c82-v6mr5563723oif.9.1532555224561; Wed, 25 Jul 2018 14:47:04 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:2646:0:0:0:0:0 with HTTP; Wed, 25 Jul 2018 14:46:44 -0700 (PDT) From: Seth Blank Date: Wed, 25 Jul 2018 14:46:44 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000c24fa50571d9d186" Archived-At: Subject: [dmarc-ietf] WGLC ARC-16 section 5.2.2 should be stricken X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 21:47:08 -0000 --000000000000c24fa50571d9d186 Content-Type: text/plain; charset="UTF-8" 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 document evaluations with comments on the full text. At IETF99 and on the list, there was a conversation around handling tempfails, where the consensus was that we couldn't handle them. That resulted in the "all failures are permanent" section of the document. However, other text for handling tempfails showed up, was discussed, and then removed ( https://mailarchive.ietf.org/arch/msg/dmarc/DmRu-_P-ZtfSjA1k6KUe-Zk0ACY). --000000000000c24fa50571d9d186 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
https://tools.ietf.org/html/draft-ietf-dmarc-a= rc-protocol-16#section-5.2.2

I am confused as to= where this section comes from. It was never discussed on list, and I belie= ve it should be stricken. https://mailarchive.ietf.org/arch/browse/dmarc/?q=3D5.= 7.7 has no results except for Dave Crocker's document evaluations w= ith comments on the full text.

At IETF99 and on th= e list, there was a conversation around handling tempfails, where the conse= nsus was that we couldn't handle them. That resulted in the "all f= ailures are permanent" section of the document. However, other text fo= r handling tempfails showed up, was discussed, and then removed (h= ttps://mailarchive.ietf.org/arch/msg/dmarc/DmRu-_P-ZtfSjA1k6KUe-Zk0ACY)= .
--000000000000c24fa50571d9d186-- From nobody Wed Jul 25 14:50:07 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFE21277C8 for ; Wed, 25 Jul 2018 14:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsPFU-mlnl_U for ; Wed, 25 Jul 2018 14:50:03 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 765EB12F1A6 for ; Wed, 25 Jul 2018 14:50:03 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id s198-v6so16595954oih.11 for ; Wed, 25 Jul 2018 14:50:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uZPWTKPf/HbF2o6Syfcz9Gpx4jX8+MH7Bt/0fsGnsCo=; b=gxKGE9aIbaqz/JgR7Z+egJM8ymyXhHy4jrHFmRPVPleBM5NdnfR2OryKpUiasWCyxR yPNLNFVXHYENtqY2MZr9YJNJQKq8ZhZgzVfBQclWA33ma5i86z9cVo/jh6Mu0lqhvUFp ai6t7qVNp/2De7pupMwNKjaqy2J3X6TkmwgMN6KqSW5znLmLc4t2J2Gv5e8wT/lPZgcv nbQFL6St39Poids/2DwvG5IDMQK/7alLKJDTRyEdCXn3O6IVxw6zoAPptdcjDeGguMoB q8LmNosfb2f743Fj7P5Brk5+QZYslR3Q0xyjqDMPUApZM4/FI65W7tGRp8eYjlOL/4iZ TuDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uZPWTKPf/HbF2o6Syfcz9Gpx4jX8+MH7Bt/0fsGnsCo=; b=ADFdoSYhOgFS9/YRFCbgkqvskn85daR22JvXV3NM7lyLNPh5S1zvNLz8rtMmzN+fdx gNjBSTJnRAYlCtV8TNPnNem8XNH9aodZzSQEdJP2XEnCni6uEKSlKuIIbePYnEeEa5qF UTC9/97123KiN82qgAFitVtsgW6frPB9B997145q3IXQiK1e7mqZY9OV0K28rpw3TS9m NvwpK+hF9Y1/HOvtJ+littcIBDz9+hgKVCcm+ScJPa+sfvozLtjpu1VXMxVKuSjN59WG uFmVgRfIGJjcmL4wWrfmFc9IlJj3Ftjz06PCUuSYI2JFN0yNxuNlf9sce+A19SKK8viA 6qrA== X-Gm-Message-State: AOUpUlEexhgogO6HiTzPAxsJqJ6G53ZKZgGAlFsozsXy92NQe7i3AwIJ DNmn/A2RF9M83gdFIvBuwvx9ecHsN/iPDgH2RTe8ATgZ20U= X-Google-Smtp-Source: AAOMgpcWlXRT4SOKiGLZ5zO0bsqsSI+xiEzvVbb0u7MK+3lvXRPSZcmZP2pMy6BO3arzsY88BN3a/GsC8p6l8NT1hNk= X-Received: by 2002:aca:cdc2:: with SMTP id d185-v6mr5598181oig.350.1532555402836; Wed, 25 Jul 2018 14:50:02 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:2646:0:0:0:0:0 with HTTP; Wed, 25 Jul 2018 14:49:42 -0700 (PDT) In-Reply-To: <33404ED3-6683-4802-8223-78AFBACA7805@uniregistry.link> References: <33404ED3-6683-4802-8223-78AFBACA7805@uniregistry.link> From: Seth Blank Date: Wed, 25 Jul 2018 14:49:42 -0700 Message-ID: To: =?UTF-8?Q?Luis_Mu=C3=B1oz?= Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000006297ec0571d9dc56" Archived-At: Subject: Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 21:50:06 -0000 --0000000000006297ec0571d9dc56 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 25, 2018 at 2:46 PM, Luis Mu=C3=B1oz wro= te: > 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=3Dinvalid. However the working group had strong consensus not to go down that path. This could be another valuable output of the experiment, if the invalid case does require a separate chain validation status. --0000000000006297ec0571d9dc56 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 25, 2018 at 2:46 PM, Luis Mu=C3=B1oz <lem@uniregistry.link= > 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=3Di= nvalid. However the working group had strong consensus not to go down that = path.

This could be another valuable output of the= experiment, if the invalid case does require a separate chain validation s= tatus.
--0000000000006297ec0571d9dc56-- From nobody Wed Jul 25 15:06:13 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 698A3130DF0 for ; Wed, 25 Jul 2018 15:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBOacCFE7S2D for ; Wed, 25 Jul 2018 15:06:09 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52D7712F1A6 for ; Wed, 25 Jul 2018 15:06:09 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id s198-v6so16663417oih.11 for ; Wed, 25 Jul 2018 15:06:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=FjK2Lf4/QRH0wr+gs9jDGAlUhbxmXQleOTjZb0gkAAg=; b=HmmS5fdUGXEuU0DBIJ78UrZhWyJn7fD/K8I+DebVp861AFc11bXO+Bt0PE8vYg8dY9 gYgVjJpkDNp1exATX98/x3USpmtIYWQUFAm3CiZMpIvnNFenOQDKRgpQQABTkXvQccmv Fg/VcX7RZmEt8dpoZFYELWaEcR+PpCCDihvr32i2OYwj6OKTtz3iqvCLNWdZcOer3CkR +M8QnxTZ4pr5HQz6fqBnfkQo3al+lq62ZFXyhYBKeE8Q/eLA4L0MStWLKN8vHav625vW YFoFVOnkldBUdDUzoFu7v7AM6NwpQuDkePbO9tk+VUu+IrQrneaXpm46JH6HglpImslf Bl0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=FjK2Lf4/QRH0wr+gs9jDGAlUhbxmXQleOTjZb0gkAAg=; b=rDm/F1bepeAiYrgq4ACHE5ZJkV1BEf+9JoQsSr7hKp/kvfV2LSbstTwidby0dA1ooc ihy6IQowxh4ixcLpyPVm39QNwWSlAc60bNwSo8Y6YOPBSA+x9UIhrRKxIPd8NbdimbJ+ rbU2QmjNN2BHvWaLF8e8nWrtHMMOnx7x15Gd35cNfQdjup4KFDF0VXsYDwblJWTIJXEF R0JND0YN6F8eh7MQEF8EsVnO4UVbj0KInW1Djtb8WgQj0S2Aqv09Sm4YyT2rX42Gwq/R EKkNGOJE53IorQBSuFvQr8O94c2BqhDZ9ccIm9DATOVWLA7p9f2zk6I/1AOb0jbo0c4b Ol5g== X-Gm-Message-State: AOUpUlFQuMEnd5ziUjy/v+QeZATEC6WC85bT9yot/mzYztbTJzHkw9ux laIjbvz+5hwaeUEucQ3tzQWcvl2/uO4whxiGawHVpc+2EYtf4w== X-Google-Smtp-Source: AAOMgpfg1D2nrw9SCSPensNoKIbDQB0m71c3ZqkqLv6U+aIlia1l4NaIAO1xbYsLgTpNTouk7vtYk9eSHQ1M5rIhFMA= X-Received: by 2002:aca:3d05:: with SMTP id k5-v6mr4919843oia.86.1532556367953; Wed, 25 Jul 2018 15:06:07 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:2646:0:0:0:0:0 with HTTP; Wed, 25 Jul 2018 15:05:47 -0700 (PDT) From: Seth Blank Date: Wed, 25 Jul 2018 15:05:47 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000e91c220571da15ef" Archived-At: Subject: [dmarc-ietf] WGLC ARC-16 minor change to Section 7.2.2 for DMARC Reporting X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 22:06:12 -0000 --000000000000e91c220571da15ef Content-Type: text/plain; charset="UTF-8" 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 it, the ams[2] portions should be removed. --000000000000e91c220571da15ef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

The exam= ple comment

=C2=A0 =C2=A0 =C2=A0 <comment&= gt;arc=3Dpass ams[2].d=3Dd2.example ams[2].s=3Ds1
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 as[2].d=3Dd2.example as[2].s=3Ds2 as[1].d=3Dd1.example
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 as[1].s=3Ds3 client-ip[1]=3D10.10.10.13<= /comment>

Doesn't match the descripti= ve text before it. To fix it, the ams[2] portions should be removed.
<= /div> --000000000000e91c220571da15ef-- From nobody Wed Jul 25 15:39:16 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 437A9130E02 for ; Wed, 25 Jul 2018 15:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0lpAtpCa-PQ for ; Wed, 25 Jul 2018 15:39:12 -0700 (PDT) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CD9E124C04 for ; Wed, 25 Jul 2018 15:39:12 -0700 (PDT) Received: by mail-yb0-x235.google.com with SMTP id s1-v6so3638693ybk.3 for ; Wed, 25 Jul 2018 15:39:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:mime-version:to:from:subject:date:importance:in-reply-to :references; bh=h5RRW6aKJmg7EEA5c/zDgxQZHFVr+susGgsP02Oue0I=; b=ZXQMebUaTC7kRfxiOb7nQmGQaomjVeyGDEPKzvtxwhy7BXHmqkTkN1bXv2MZTyWZF8 G5Q3CE+LOphUbjTIAJlewiJexpY5LhwA8sgi3hHJ0KVbA4f6/KPwue6nXvHbf+X2VP1p whU+rl6XutWxypOdppJgUHD/lOLcBa/KaLfAIm4UBj+YQeYi87iKvbOn6QaQAEaWpMnv HGHx4TsfljKAs1jA0u/5dITaeSiEYRLAFIsZTlbTFKiSPE9ciUodE08B1AabhajRy15a 0bpGTXB98ofLiqPZkTU7nBcDoDWJuMRxznAiaQ3PXg60eLNvDeLCJtV3NcKp9CQsTxjQ Oeaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version:to:from:subject:date :importance:in-reply-to:references; bh=h5RRW6aKJmg7EEA5c/zDgxQZHFVr+susGgsP02Oue0I=; b=QamZbvd0u8oFUc4udNFcOEBl7RmSdYZm0ibbOnnri2znuCyEBCp3HAQMNwQB9jvlW7 RHatw2IpZgLmPIhSQl3BvakDjZg8kwX2WuXG0yP1/SPTdOkiVbr47Lv4KMsymehqjoFG //dgTxeKLjHUQXgpQ0BjCMcwPoFgQeqlP0Ze+TBh7oMqGyL1aw/XQ0qoJQHHEDlmXaIn Ce9PuU0RzcNTbIOp/kfkYpvJln2r9jA2JBmpqONf2K9PuG3E7TLVFgekg+4rZPMK0mP+ +odRCbTWuTmauw2iXv7Ai/h8ldGrtfKQDokZ/5v8fX8KFrNspdd8Bu/uiQ7qPGeC5lFr a1Jw== X-Gm-Message-State: AOUpUlGTagDHmgGgtYQ7D1XFiMhgB++YMkgmCS7lYpDQSnh+yfgLOJYM XEF+gOZ05p3AZOIJ7kO0Vlx9Itvo X-Google-Smtp-Source: AAOMgpf5OfNE3Y1jTHgc6VrnPnxIbBqf9CQIKGM3XUQZOSPSx7pr2wD5ANHiuf6UeqqLgnQHEV2RjQ== X-Received: by 2002:a25:80c6:: with SMTP id c6-v6mr12909771ybm.4.1532558351283; Wed, 25 Jul 2018 15:39:11 -0700 (PDT) Received: from ?IPv6:2601:192:4e00:596:4df2:750b:2643:3b97? ([2601:192:4e00:596:4df2:750b:2643:3b97]) by smtp.gmail.com with ESMTPSA id q127-v6sm15679219ywq.83.2018.07.25.15.39.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Jul 2018 15:39:10 -0700 (PDT) Message-ID: <5b58fc0e.1c69fb81.35d42.9db7@mx.google.com> MIME-Version: 1.0 To: "dmarc@ietf.org" From: Peter Occil Date: Wed, 25 Jul 2018 18:39:11 -0400 Importance: normal X-Priority: 3 In-Reply-To: <5b571366.1c69fb81.96f7c.11c7@mx.google.com> References: <20180723000558.CD758B80F99@rfc-editor.org> <87lga1pdg2.fsf@hobgoblin.ariadne.com> <5b571366.1c69fb81.96f7c.11c7@mx.google.com> Content-Type: multipart/alternative; boundary="_EF4D575F-4E3E-41F3-87A5-37B536B034EA_" Archived-At: Subject: Re: [dmarc-ietf] [art] [Technical Errata Reported] RFC7601 (5435) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 22:39:14 -0000 --_EF4D575F-4E3E-41F3-87A5-37B536B034EA_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Please take note: I have withdrawn this erratum. This is because there wou= ld be optional CFWS (rather than required CFWS) between propspecs, which is= actually erroneous. --Peter From: Peter Occil Sent: Tuesday, July 24, 2018 7:54 AM To: Dale R. Worley; RFC Errata System Cc: ben@nostrum.com; adam@nostrum.com; aamelnikov@fastmail.fm; art@ietf.org= ; superuser@gmail.com; rfc-editor@rfc-editor.org Subject: RE: [art] [Technical Errata Reported] RFC7601 (5435) On further thought, it is indeed incorrect.=C2=A0 Therefore, the errata sub= mission is withdrawn. --Peter From: Dale R. Worley Sent: Monday, July 23, 2018 10:36 PM To: RFC Errata System Cc: poccil14@gmail.com; ben@nostrum.com; adam@nostrum.com; aamelnikov@fastm= ail.fm; art@ietf.org; superuser@gmail.com; rfc-editor@rfc-editor.org Subject: Re: [art] [Technical Errata Reported] RFC7601 (5435) I think that the erratum is, strictly speaking, incorrect.=C2=A0 I've not worked through examples in detail, but you can see that each propspec contains exactly one "=3D" (other than in certain quoted contexts), which makes it unlikely that two successive propspecs could be parsed as a single propspec.=C2=A0 If there really is an ambiguity, the way to demonstrate it is to provide an example. --_EF4D575F-4E3E-41F3-87A5-37B536B034EA_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

Please take note: I have withdrawn t= his erratum.=C2=A0 This is because there would be optional CFWS (rather tha= n required CFWS) between propspecs, which is actually erroneous.

 

--Peter

 

 

From: Peter = Occil
Sent: Tuesday, July 24, 2018 7:54 AM
To: Dale R. Worley; RFC Errata System
Cc: ben@nostrum.com; adam@nostrum.com; aamelniko= v@fastmail.fm; art@ietf.org; superuser@gmail.com; rfc-editor@rfc-editor.org
Subject: RE: [art] [Technical Errata Reported] RFC7601 (5435)

 

On further thought, it = is indeed incorrect.  Therefore, the errata submission is withdrawn.

 

--Peter

 

 

From: Dale R. Worley
Sent: = Monday, July 23, 2018 10:36 PM
To: RFC Errata System
Cc: poccil14@gmail.com; be= n@nostrum.com; adam@nostrum.com= ; aamelnikov@fastmail.fm; art@ietf.org; superuser@gmail.com; rfc-editor@rfc-editor.org
Subject: Re: [art] [Technical= Errata Reported] RFC7601 (5435)

<= o:p> 

I think that the erratum is, stric= tly speaking, incorrect.  I've not

= worked through examples in detail, but you can see that each propspec<= /o:p>

contains exactly one "=3D" (other t= han in certain quoted contexts), which

m= akes it unlikely that two successive propspecs could be parsed as a

single propspec.  If there really is an am= biguity, the way to

demonstrate it is to= provide an example.

 

 

= --_EF4D575F-4E3E-41F3-87A5-37B536B034EA_-- From nobody Wed Jul 25 21:40:06 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4759F130E05 for ; Wed, 25 Jul 2018 21:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=PAQHOx/+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Y2H7MW1G Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3Zuk_6aTG1S for ; Wed, 25 Jul 2018 21:40:02 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2DEB130F4C for ; Wed, 25 Jul 2018 21:40:02 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id DFF96381; Thu, 26 Jul 2018 00:40:01 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute6.internal (MEProxy); Thu, 26 Jul 2018 00:40:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=++kSKqRyZFr3DubfXHGTKXWvpiFhK2VYeq3pZUA2N FQ=; b=PAQHOx/+zcrKLmG2jvfw5zs0rsCdNxnAlNSq6dGsayUUP8skZZwKsv/jG FsHq0fhq+nCAk30JgR0zVETDKlkrf9n0Mt2ex404VJ8QW3tQmCiTrAOJJ9/0ZfVS IRcpROtw1asHXwRrkHvrVk9w0a63792Afs3revVdy3J/bv4lPB1d6aP4+CzHpww3 clgYhInMg1IVUdisC+ca201MW/hEjGgrCgLPLOq8vf7q+10tmx9NyEv+ec1Lf/+j kjTG7KsUgQ5g+czs+g7QT9melal2EX2zuPkAJZzcbd1WM43q6ALfxMD/bgyKZr39 7mUZrgF8KSRtMix5HtUiQ8b/f8Z+A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=++kSKqRyZFr3DubfXHGTKXWvpiFhK2VYeq3pZUA2N FQ=; b=Y2H7MW1GBmbFSdbn853+q5rmoOZ8UO/43S5KW8dwfWjrPNc6rgKxxWT+G k6LxkCbaKtTbAeKiXWAUYgH6FobPYKcwe0CbvNUJ/+4TMBJG5eBkLggtaVKz96PC ufnAsrexZOMkdgPCGP93+hFJOTqRsu0G5vxlNQI251SyKwOizVLhHEK/GZxieCPy yf+eS5LtVxpaSmAr6k2zzGR9ZYK6BAGBD6mNPRURWVFkDskd2JNd9yAuyLWFm0cz FiVrhGUFVuj8B2KG3sU1hJGQ/LQmF2GwrnNite1FXS7dCCYcuA2fKaMTRxWz87gj 3YwKBjdeMAJ4VxR4m2BqEntQSUSSA== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 384DAEB49; Thu, 26 Jul 2018 00:40:01 -0400 (EDT) Message-Id: <736d061b-df76-4fd6-9231-3457d0f7dd39@sloti22d1t06> User-Agent: Cyrus-JMAP/3.1.5-95-gd9f57c1-fmnext-20180726v2 x-jmap-identity-id: 56629417 In-Reply-To: References: <1532472947.3343083.1451792120.35CD7BCD@webmail.messagingengine.com> Date: Thu, 26 Jul 2018 00:40:00 -0400 From: Bron Gondwana To: Murray S. Kucherawy Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary=5e0a14e22cc940ee8c46a0f388d5e1ec Archived-At: Subject: Re: [dmarc-ietf] Approval of draft-ietf-dmarc-arc-protocol-16 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 04:40:04 -0000 --5e0a14e22cc940ee8c46a0f388d5e1ec Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thu, Jul 26, 2018, at 04:57, Murray S. Kucherawy wrote: > On Tue, Jul 24, 2018 at 3:55 PM, Bron Gondwana wrote: >> __ >> This isn't a detailed review, because I haven't had time to do it, bu= t I've been following the process and I'm happy that ARC-16 is ready as = an experimental standard. >=20 > What's an "experimental standard"? I'm sure I meant to say "experimental specification". Bron.=C2=A0=20 -- =C2=A0 Bron Gondwana, CEO, FastMail Pty Ltd =C2=A0 brong@fastmailteam.com --5e0a14e22cc940ee8c46a0f388d5e1ec Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Thu, Jul 26, 2018, at 04:57, Murray S. Kucherawy wrote:=
On Tue, Jul 24, 2018 at 3:55 PM, B= ron Gondwana <brong@fastmailteam.com> wrote:

This isn't a detailed review, because I = haven't had time to do it, but I've been following the process and I'm h= appy that ARC-16 is ready as an experimental standard.

What's = an "experimental standard"?

I'm sure I meant to say "experimental specification".
<= div style=3D"font-family:Arial;">
Bron. 

<= div id=3D"sig56629417">
--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--5e0a14e22cc940ee8c46a0f388d5e1ec-- From nobody Wed Jul 25 23:28:22 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAEAA130DFC for ; Wed, 25 Jul 2018 23:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=andreasschulze.de header.b=75EdO1jk; dkim=pass (2048-bit key) header.d=andreasschulze.de header.b=lrz1nHDr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5j6agKAb18te for ; Wed, 25 Jul 2018 23:28:17 -0700 (PDT) Received: from mta.somaf.de (mta.somaf.de [IPv6:2001:470:77b3:103::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 656BE130DC2 for ; Wed, 25 Jul 2018 23:28:17 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=andreasschulze.de; i=@andreasschulze.de; q=dns/txt; s=ed25519; t=1532586492; h=date : message-id : from : to : subject : in-reply-to : content-type : mime-version : date : from : subject; bh=2ExCytaoDP25DuejMQ0PzIB9pgoun2yXR6q/8FNyBrs=; b=75EdO1jklIBi6Cw0WuY9WbJc3Z0QSm9dsw7IcBqmslU5cA+Fla1sQHIP m5dv5ErG31Uowt85QGB5GeezvdQhCg== Date: Thu, 26 Jul 2018 08:28:02 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andreasschulze.de; s=20180722-E324; t=1532586492; x=1537586492; bh=2ExCytaoDP25DuejMQ0PzIB9pgoun2yXR6q/8FNyBrs=; h=Date:Message-ID:From:To:Subject:In-Reply-To:Content-Type:from: reply-to:subject:date:to:cc:content-type:message-id; b=lrz1nHDr6q62BSqOg5qWmsThjvJ99DDoQDIDNtauv+hUS8pnk7p+Hk+odAs7zd1Jz lGJ2XBCKGiMgVoCdohW1mYBYIREiMrO2rhy/7MCbLUaQMjrwDQ7n+D+XneHWVpLAo7 TRPQK7ga72k/OCIJVLUTmxKOM9TsJnBAR82VxsQQxAx42TMQofG0VPv7yZqzj0YAqj u/CPFXj+PSPc94FP9jkYvg76rCaUypbbaEYCkoai9RNIUnh+HAnjjFkgVZHQkqch6t lQiFnqqw++dXRaETcsUpfbkpxyBp/1CYqMr1XxlbaoupZik0SxM83sPiDmZhS0fkDq ROZwqIKT7dH+Q== Message-ID: <20180726082802.Horde.fcqA7SQnLck7sYhCeUH0Fhk@andreasschulze.de> From: "A. Schulze" To: dmarc@ietf.org In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Archived-At: Subject: Re: [dmarc-ietf] OpenARC and draft-ietf-dmarc-arc-protocol-16 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 06:28:21 -0000 Murray S. Kucherawy: > I've pushed a new release of OpenARC that's based on the normative stuff in > -16: > > https://github.com/trusteddomainproject/OpenARC/releases/tag/v1.0.0.Beta0 > > It's missing API documentation, but I plan to provide a full set of that > before v1.0.0 goes out. The documentation for the filter itself should be > complete, however. > > If anyone is looking to do interop testing to confirm stuff that's in the > spec, let me know and I can provide whatever support is needed. I'll build and deploy that version on openarg.org next days. Andreas From nobody Thu Jul 26 14:47:53 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2DC6130F13 for ; Thu, 26 Jul 2018 14:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=andreasschulze.de header.b=+BTh9OYc; dkim=pass (2048-bit key) header.d=andreasschulze.de header.b=MGpJHg9G Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sq9LKuM9XJ5Y for ; Thu, 26 Jul 2018 14:47:48 -0700 (PDT) Received: from mta.somaf.de (mta.somaf.de [IPv6:2001:470:77b3:103::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D94E130E23 for ; Thu, 26 Jul 2018 14:47:48 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=andreasschulze.de; i=@andreasschulze.de; q=dns/txt; s=ed25519; t=1532641665; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding : subject : from : date; bh=JMARasvaDA7N6DLsfRukO08QgoCM/NtgQsBtrvH5m2M=; b=+BTh9OYcReleelzq8cppXuBX2eMHNbfO7w7e8FqDdFRyha6t0LTiYFkF gsur6UuxC2lE1k4hl1cifQwLwYPmCA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andreasschulze.de; s=20180722-E324; t=1532641665; x=1537641665; bh=JMARasvaDA7N6DLsfRukO08QgoCM/NtgQsBtrvH5m2M=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To: Content-Type:from:reply-to:subject:date:to:cc:content-type: message-id; b=MGpJHg9GXEoHI8qp/BVDFTMoOEjJ1jzeEEZaeCjUd9owRrlyKNxmZ0XslWIXrf6Zp /kZ3eaJX6PUMjnsC59ou+nTRT0jaV5pDfhn7g3ajKjkXVJH7wCwOF/s0yREfkB8f9R 2sThpifRrxJ5qIoqDpNMzXZBqfM/RFU1RD/Fbcs4aqRa35ueWakI9dDKR+ytrs9edR xKQtEzJJbDagXLpqIM+Q8lXTFliMvy9nsFAPOt95eRGBSuU229aFMaOs5zRoW0r83/ aX0Wm4C3Ep9deiykFP9WM4OAvRYsXwakfqPdnsyMnxC5XFCpkkPDCLfDlm0j4cqOKb 0yjs6yCGImKgg== To: dmarc@ietf.org References: <20180726082802.Horde.fcqA7SQnLck7sYhCeUH0Fhk@andreasschulze.de> From: "A. Schulze" Message-ID: <8fbcef71-ceb0-13b0-e8d4-950f0a589f45@andreasschulze.de> Date: Thu, 26 Jul 2018 23:47:38 +0200 MIME-Version: 1.0 In-Reply-To: <20180726082802.Horde.fcqA7SQnLck7sYhCeUH0Fhk@andreasschulze.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] OpenARC and draft-ietf-dmarc-arc-protocol-16 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 21:47:52 -0000 Am 26.07.2018 um 08:28 schrieb A. Schulze: > > Murray S. Kucherawy: > >> I've pushed a new release of OpenARC that's based on the normative stuff in >> -16: >> >> https://github.com/trusteddomainproject/OpenARC/releases/tag/v1.0.0.Beta0 openarc.org was updated to run the new version. see https://openarc.org/testing binary packages are available for some Linux distribuition: https://build.opensuse.org/package/show/home:andreasschulze/openarc (except Debian 9 I couldn't say not more then "it builds") Andreas From nobody Thu Jul 26 16:36:43 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 168D2131275 for ; Thu, 26 Jul 2018 16:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-kdLc1F5TsO for ; Thu, 26 Jul 2018 16:36:38 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD9D3131269 for ; Thu, 26 Jul 2018 16:36:38 -0700 (PDT) Received: (qmail 27166 invoked from network); 26 Jul 2018 23:36:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=6a1b.5b5a5b05.k1807; bh=fxLndv7zBi9IQ9uZO+GUpvjX59oNwYd3zwDIuUZonvs=; b=vviAJ6f46XWIVHnXCHDq++yyAeoNTRiLkA0TmdCFOzUbthotck7KYcrqJOU0nABGJza0UjEL2NhqbSEEPv0gW0XF0TphhAvU/NhgxlTh6xsiBfCBtrkuhN0aomOnyqYiPg6/dbv3JrPF4ijwYo2KnIXBTi/dkB69Jciq+LDWAULGphoWhMWdAlbGH/IzZn7VBR1VxpP70fsIL4AaCMK+A4gWDIh6D+Zz/KmhoCWrIt4mWOM5JRZCVOUhQtiCtpfA Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 26 Jul 2018 23:36:37 -0000 Date: 26 Jul 2018 19:36:36 -0400 Message-ID: From: "John R. Levine" To: "Seth Blank" Cc: "IETF DMARC WG" In-Reply-To: References: User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] WGLC ARC-16 section 5.2.2 should be stricken X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 23:36:42 -0000 I agree, this is out of place. Whether you reject at SMTP time is a much broader topic than ARC failures. On Wed, 25 Jul 2018, Seth Blank wrote: > 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 document evaluations with comments on the full > text. > > At IETF99 and on the list, there was a conversation around handling > tempfails, where the consensus was that we couldn't handle them. That > resulted in the "all failures are permanent" section of the document. > However, other text for handling tempfails showed up, was discussed, and > then removed ( > https://mailarchive.ietf.org/arch/msg/dmarc/DmRu-_P-ZtfSjA1k6KUe-Zk0ACY). > Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Fri Jul 27 06:52:14 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A06B4130E5A for ; Fri, 27 Jul 2018 06:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyWt7jqw60Ck for ; Fri, 27 Jul 2018 06:52:10 -0700 (PDT) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0ECA126CC7 for ; Fri, 27 Jul 2018 06:52:09 -0700 (PDT) Received: by mail-ed1-x532.google.com with SMTP id o8-v6so3970710edt.13 for ; Fri, 27 Jul 2018 06:52:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=C1zNs54ATWAKX1gvRwCJaqPCiktXFNl+FjrxD57w+0U=; b=IREcCH+c17dFApb1T4tAJwVcdqNweSDnmwEkAGpozFz11BDV0cmsicGr3qmXo03atO GoLujHCJO52zVAJ+xIXp4EIEqgKK2mtsuoHWpgkSmH5+Y8zKjYkkdVCcNhmqucmAHrS7 RwApkE4d4PXVBTr2ht5Ibk/aFnG0MrvHqpUoA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=C1zNs54ATWAKX1gvRwCJaqPCiktXFNl+FjrxD57w+0U=; b=Ek4ZquBlEAIjD5c3+iK0VaBfEIvZbyV2xm4drb/4gDFz5CPJqdHkUCW0TcwGwC2qHM eb9zM/OGTmzsGAp60Rj4kBF65JGfEqkq2VvNgxqcgQ9/wmjBSUSw97rF0hfbGrii6Ece iWgvzAJmSUuePM1gio38hWkRatf8YfgHqPU4S0DkbrUzaq2wlO4sGf+i3mTJxuSQdVXe m8989g1WBZHqmyPXT3XV1bz6CRdzzUkByabOnXhWQBtd7dq4pFAZ/Y8yLNFg6+YaPdfa JCurd+aCOCeY+qaB77JRQGulEc/vL1uBAWAs0I6N/iuaStAukVaUbpvgxNNlDn1r+kwU pwvA== X-Gm-Message-State: AOUpUlFrzrgT8dd5fLK7a/G0ohEW2LJPExoF0dQq4TMpc3Ylk7o3iUp7 LmbLxSQQafQsGCh2Tt95kZ6uaXwHD2ynVII8YSwY2A== X-Google-Smtp-Source: AAOMgpcve5E5j5I+dP3bMAjgD73Te8knZVHLwYyMnWZIP34/06TcWJ/F4aO2ifoDG1VJK3A7PuqjYKm97E/R/62P2w8= X-Received: by 2002:a50:81c6:: with SMTP id 64-v6mr7722424ede.89.1532699528163; Fri, 27 Jul 2018 06:52:08 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 2002:aa7:da87:0:0:0:0:0 with HTTP; Fri, 27 Jul 2018 06:52:07 -0700 (PDT) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Fri, 27 Jul 2018 06:52:07 -0700 X-Google-Sender-Auth: FcdU8Ote8cYo5e5y5V1C7aOpMHE Message-ID: To: "John R. Levine" Cc: Seth Blank , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000ec82740571fb6a5c" Archived-At: Subject: Re: [dmarc-ietf] WGLC ARC-16 section 5.2.2 should be stricken X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 13:52:13 -0000 --000000000000ec82740571fb6a5c Content-Type: text/plain; charset="UTF-8" This is not a matter of *whether* you reject during the SMTP interchange as how to do it in a meaningful way *if* you do so. The discussion about signaling that the domain authentication failure led to the rejection is the point of this section. --Kurt On Thu, Jul 26, 2018 at 4:36 PM, John R. Levine wrote: > I agree, this is out of place. Whether you reject at SMTP time is a much > broader topic than ARC failures. > > On Wed, 25 Jul 2018, Seth Blank wrote: > > 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 document evaluations with comments on the full >> text. >> >> At IETF99 and on the list, there was a conversation around handling >> tempfails, where the consensus was that we couldn't handle them. That >> resulted in the "all failures are permanent" section of the document. >> However, other text for handling tempfails showed up, was discussed, and >> then removed ( >> https://mailarchive.ietf.org/arch/msg/dmarc/DmRu-_P-ZtfSjA1k6KUe-Zk0ACY). >> >> > Regards, > John Levine, johnl@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 > --000000000000ec82740571fb6a5c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is not a matter of *whether* you reject during the SM= TP interchange as how to do it in a meaningful way *if* you do so. The disc= ussion about signaling that the domain authentication failure led to the re= jection is the point of this section.

--Kurt

On Thu, Jul 26, 2018 at 4= :36 PM, John R. Levine <johnl@iecc.com> wrote:
I agree, this is out of place.=C2=A0 Whether you reject a= t SMTP time is a much broader topic than ARC failures.

On Wed, 25 Jul 2018, Seth Blank wrote:

https://tools.ietf.org/htm= l/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/br= owse/dmarc/?q=3D5.7.7 has no results
except for Dave Crocker's document evaluations with comments on the ful= l
text.

At IETF99 and on the list, there was a conversation around handling
tempfails, where the consensus was that we couldn't handle them. That resulted in the "all failures are permanent" section of the docum= ent.
However, other text for handling tempfails showed up, was discussed, and then removed (
https://mailarchive.ietf.org/= arch/msg/dmarc/DmRu-_P-ZtfSjA1k6KUe-Zk0ACY).


 Regards,
John Levine, johnl@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

--000000000000ec82740571fb6a5c-- From nobody Fri Jul 27 07:03:24 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2617B127598 for ; Fri, 27 Jul 2018 07:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbp1lECHhwf2 for ; Fri, 27 Jul 2018 07:03:20 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4425126CC7 for ; Fri, 27 Jul 2018 07:03:19 -0700 (PDT) Received: (qmail 45512 invoked from network); 27 Jul 2018 14:03:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=b1c3.5b5b2625.k1807; bh=sdq3dGhp0S1Vqp1IRhyV5ueupK4MwXklgWjRZWKAbb4=; b=U1QJm3Vx5kNrkV2VOvR618ZOydQa4CsNvWvnTgTlicxLr3jg3EVA6lWyWH/Gj9s+rbrCS3mKztD2+kHUWwWCjSGBE/0rJh+GsPIMTQatjiK7v7oazi58r8J4ae8KyA7C4TlDkhjvrc7hN/oU47tPUtvOVURs5otbh8d1BHDIEbD2zhJxONSAn2pxJVafNETa51CSmd4HYKv/no39PMRqaSnOH28mw78CNj5u3DiFr13I72WRG3xPYALgteNsD493 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 27 Jul 2018 14:03:17 -0000 Date: 27 Jul 2018 10:03:16 -0400 Message-ID: From: "John R. Levine" To: "Kurt Andersen (b)" Cc: "IETF DMARC WG" In-Reply-To: References: User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] WGLC ARC-16 section 5.2.2 should be stricken X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 14:03:22 -0000 On Fri, 27 Jul 2018, Kurt Andersen (b) wrote: > This is not a matter of *whether* you reject during the SMTP interchange as > how to do it in a meaningful way *if* you do so. The discussion about > signaling that the domain authentication failure led to the rejection is > the point of this section. Ah. I still think it should go, but if you really want to do that, invent a new enhanced status code. They're cheap. 5.7.7 isn't right, it's more like corrupt S/MIME bodies. R's, John > > --Kurt > > On Thu, Jul 26, 2018 at 4:36 PM, John R. Levine wrote: > >> I agree, this is out of place. Whether you reject at SMTP time is a much >> broader topic than ARC failures. >> >> On Wed, 25 Jul 2018, Seth Blank wrote: >> >> 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 document evaluations with comments on the full >>> text. >>> >>> At IETF99 and on the list, there was a conversation around handling >>> tempfails, where the consensus was that we couldn't handle them. That >>> resulted in the "all failures are permanent" section of the document. >>> However, other text for handling tempfails showed up, was discussed, and >>> then removed ( >>> https://mailarchive.ietf.org/arch/msg/dmarc/DmRu-_P-ZtfSjA1k6KUe-Zk0ACY). >>> >>> >> Regards, >> John Levine, johnl@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 >> > Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Fri Jul 27 08:02:05 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2D3130F25 for ; Fri, 27 Jul 2018 08:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wordtothewise.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-zgUje9jVFn for ; Fri, 27 Jul 2018 08:02:02 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id CEC7F130E25 for ; Fri, 27 Jul 2018 08:02:01 -0700 (PDT) Received: from [192.168.80.243] (unknown [204.11.227.194]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 3A3E19F13D; Fri, 27 Jul 2018 08:02:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1532703720; bh=37uWegH1a8YSfbyY1YcPkJfnqRFeHZ2XbdwF+Mzs02I=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=hFlpd2lj/CB3zaHXKFEuaqH+8zkNO/ReUUIRMEhUJ5nmc2z8OcaieIEkJPCYtqW4I D7Zo0aDcu3auotxystxYFukEK+xvOCfjhS/R175IIHuoLPmGjG5TEKSEETLK/IjLGa cCXSHKtsJPiFL5R3BlWI3/qd2EjjgiA35e0X0EkQ= From: Laura Atkins Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_7A51EE1B-E346-4238-AF7B-7DBA0FF84532" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 27 Jul 2018 08:01:56 -0700 In-Reply-To: Cc: "Kurt Andersen (b)" To: IETF DMARC WG References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dmarc-ietf] WGLC ARC-16 section 5.2.2 should be stricken X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 15:02:04 -0000 --Apple-Mail=_7A51EE1B-E346-4238-AF7B-7DBA0FF84532 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 27, 2018, at 7:03 AM, John R. Levine wrote: >=20 > On Fri, 27 Jul 2018, Kurt Andersen (b) wrote: >=20 >> This is not a matter of *whether* you reject during the SMTP = interchange as >> how to do it in a meaningful way *if* you do so. The discussion about >> signaling that the domain authentication failure led to the rejection = is >> the point of this section. >=20 > Ah. I still think it should go, but if you really want to do that, = invent a new enhanced status code. They're cheap. 5.7.7 isn't right, = it's more like corrupt S/MIME bodies. The enhanced status codes are often what ESPs use to make determinations = about what to do with future email to that address. Different folks = using the same code to mean different make interoperability challenging = for bulk senders. If you do want an enhanced status code, pick one = that=E2=80=99s not currently being used for something else. Or one = that=E2=80=99s rarely used. Continuing to muddy the tar pit doesn=E2=80=99= t help anyone.=20 IOW, +1 to John=E2=80=99s =E2=80=9Cinvent a new one=E2=80=9D=20 laura=20 --=20 Having an Email Crisis? We can help! 800 823-9674=20 Laura Atkins Word to the Wise laura@wordtothewise.com (650) 437-0741 =09 Email Delivery Blog: https://wordtothewise.com/blog=09 --Apple-Mail=_7A51EE1B-E346-4238-AF7B-7DBA0FF84532 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jul 27, 2018, at 7:03 AM, John R. Levine <johnl@iecc.com> = wrote:

On Fri, 27 Jul 2018, Kurt = Andersen (b) wrote:

This is not a matter of = *whether* you reject during the SMTP interchange as
how to = do it in a meaningful way *if* you do so. The discussion about
signaling that the domain authentication failure led to the = rejection is
the point of this section.

Ah.  I still think it should go, but = if you really want to do that, invent a new enhanced status code. =  They're cheap.  5.7.7 isn't right, it's more like corrupt = S/MIME bodies.

The = enhanced status codes are often what ESPs use to make determinations = about what to do with future email to that address. Different folks = using the same code to mean different make interoperability challenging = for bulk senders. If you do want an enhanced status code, pick one = that=E2=80=99s not currently being used for something else. Or one = that=E2=80=99s rarely used. Continuing to muddy the tar pit doesn=E2=80=99= t help anyone. 

IOW, +1 to = John=E2=80=99s =E2=80=9Cinvent a new one=E2=80=9D 

laura 

-- 
Having an Email Crisis? =  We can help! 800 823-9674 

Laura Atkins
Word = to the Wise
laura@wordtothewise.com
(650) = 437-0741 =

Email Delivery Blog: https://wordtothewise.com/blog =







= --Apple-Mail=_7A51EE1B-E346-4238-AF7B-7DBA0FF84532-- From nobody Fri Jul 27 08:17:11 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BFFF130FB8 for ; Fri, 27 Jul 2018 08:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3N_iBjiqiFeU for ; Fri, 27 Jul 2018 08:16:59 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07D26130F8E for ; Fri, 27 Jul 2018 08:16:58 -0700 (PDT) Received: (qmail 75863 invoked from network); 27 Jul 2018 15:16:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=12854.5b5b3768.k1807; bh=hd6xeeNr4Z8Ic7bflQthgujNcN3wIVwOmDycrmIVdTs=; b=IfOhPlWZJkraSLMnBAutCRD5QLiznOl4anPkZdUjl6JyJxY/NYEvGF/mhN2Wpk3Jv9uKiaho2A2ldp7T9FVebVvjhzLk+NbGs9Nw8QrCj3SfZ033Rgg2GtvaH1lMOoaszQyuCkYeoowdC8t4IVVLO67Q+k15CjU67pviA+B5zf5LznlSfWVGHz0dsB3xtbiWYfX6272KGSnlqfKIKJ9uIORRkGWG2y8HLsa5N+7KXSdymOC+NlENKys/rprvM97r Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 27 Jul 2018 15:16:56 -0000 Date: 27 Jul 2018 11:16:56 -0400 Message-ID: From: "John R. Levine" To: "IETF DMARC WG" User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [dmarc-ietf] Lots of pending errata for RFC 7489 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 15:17:08 -0000 There's a bunch of errata from the past year that are neither verified nor rejected. Most of them look correct, suggest they all be hold for update. Erratum 5229: adds some misssing default values to the report XML scheme. Looks correct. Erratum 5365: report filename .gz should be .xml.gz. Correct. Erratum 5370: same as 5365. Erratum 5371: missing reference for GZIP. Correct. Erratum 5220: wants to add text about organizational TLDs. Reject, there's nothing special about them. Erratum 5221: XML regular expression for IPv6 doesn't cover compressed addresses. Correct, but suggested 38 line replacement is a bit much. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Fri Jul 27 08:25:09 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6610130FA6 for ; Fri, 27 Jul 2018 08:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxo5vE2IU1Jm for ; Fri, 27 Jul 2018 08:24:56 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C37DC130F75 for ; Fri, 27 Jul 2018 08:24:55 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id p10-v6so4764454ljg.2 for ; Fri, 27 Jul 2018 08:24:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WQfiAmaFDD7SEXiCQ/SqbPfgb1qqkU2iMW4vSnBRXCM=; b=awXO2fElCT4zwd4H3vMY2Ux6HtRRYyu7wbXvWkBAek//tFDFyLiu9L70mXDPqXL00J TZBK48cIag9t9EG+Md13ziXcGoPwsIreSkRuqHCuFAEtZ2FLxKvp2GeyBmFQ9QFOXgiz F8zjFBVM1lIJzllg6zt4u3n2Kp6EC3UfgN0qBLfM2MM9bhOjxEnDzQFUWFIv5c04s+Eo UpaSeGWe/BCkhSTcFsRzCWLmXPA9VYhhalBDL7MYsk6vs4jsGERWkDSyDRDFUPP9wxk+ 9yGwUp3bp3D7C34NYeNjtrj6/wAMOzduE/8FziRf2l5EsQadlCgI8ibCI6SDYEotSrh7 TQKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WQfiAmaFDD7SEXiCQ/SqbPfgb1qqkU2iMW4vSnBRXCM=; b=CstFXHCZTNMXDfWpMklb05rc2dvsWjPE8/L0ADS2wbjMKw+mW3XHJQwUQT2BHP7EIY LCEu0l2UV1bCkqeR+4FYblHD84YFquZroTLmKADn5XCvLhOuKm5lLuPcotpSJh0WLWjF UzHlH9lkEqCA5WCcttdPOgj3V952YGbIiLX4luR0cItIHWKYnYI3pLF48ByFzuSu6iaO q6p+R5dqQEtQIBaR36uUgQW93++HYFoJjRRrvmWT9I4u8K3zzU/LD+21ORFR4nhJSpI6 ALTXgA2uc8kECNfpVOhQsEg+1t6w4HSqWy/MXRStWW/4tRpL8nDnOjUqDGWjHebfHPG0 YQIA== X-Gm-Message-State: AOUpUlFAq5JwJO1NNyRXHYESF1HLrIv9aL/oP6AfitdTFV+6uzT7wLEU HTeMOqqwQvDenPkHVhFy+EyH1gZg7qW6z+cVnzvh1Q== X-Google-Smtp-Source: AAOMgpf4mwEj9N+o42z7g1HsLp7Dvi/TdQcR0vmwAICaSfsN0OZ9zLjZO8qb7pRrVYc1oj2cZctansbQXMaQhKjfxeQ= X-Received: by 2002:a2e:259:: with SMTP id 86-v6mr5457398ljc.107.1532705093946; Fri, 27 Jul 2018 08:24:53 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:3a13:0:0:0:0:0 with HTTP; Fri, 27 Jul 2018 08:24:53 -0700 (PDT) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Fri, 27 Jul 2018 08:24:53 -0700 Message-ID: To: Seth Blank Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000ab90f00571fcb66f" Archived-At: Subject: Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 15:24:59 -0000 --000000000000ab90f00571fcb66f Content-Type: text/plain; charset="UTF-8" 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 definition of invalid). We then decided to abandon the > cv=invalid path and only have cv=fail. > > Somehow, in the current doc this advice for invalid chains now applies to > all chain failures. Section 5.1.2's title even mentions it is for the > invalid case, but the text as written applies to all failed chains. > > Without the ARC Seal 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. > > 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. > > I believe the proper text for this section (replacing the first paragraph > for 5.1.2 in its entirety) should be: > > In the event that it is not possible to generate a deterministic list > of previous > ARC Sets to sign (such as when the chain undergoing validation > is structurally invalid), the signature scope of the AS header field b= > value MUST only include the latest ARC Set headers as if this newest ARC > Set was the only set present. > I think it's weird that the body of content that gets hashed by the sealer in this case varies from what would normally happen. A verifier might have to try two different verification algorithms if, for example, it doesn't determine that the chain is structurally invalid. If I receive a chain that was apparently valid at the last sealer and determine that it is no longer so, could we simply decline to re-seal it at all? -MSK --000000000000ab90f00571fcb66f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 25, 2018 at 2:34 PM, Seth Blank <seth@sethbl= ank.com> wrote:
When we introdu= ced the concept of cv=3Dinvalid last year, the advice was to only sign your= own ARC Set, because there was no deterministic way to know which header f= ields to sign when those ARC header fields were not properly intact (the de= finition of invalid). We then decided to abandon the cv=3Dinvalid path and = only have cv=3Dfail.

Somehow, in the current doc this ad= vice for invalid chains now applies to all chain failures. Section 5.1.2= 9;s title even mentions it is for the invalid case, but the text as written= applies to all failed chains.

Without the ARC Sea= l 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 signatur= e.

The proper guidance should be that the ARC-Seal= MUST sign the ARC Chain in its entirety, unless that is structurally impos= sible, in which case it should only sign itself.

I believe the proper text for this section (replacing the first paragrap= h for 5.1.2 in its entirety) should be:

=C2=A0 =C2= =A0In the event that it is not possible to generate a deterministic list of= previous
=C2=A0 =C2=A0ARC Sets to sign (such as when the chain u= ndergoing validation
=C2=A0 =C2=A0is structurally invalid), the s= ignature scope of the AS header field b=3D
=C2=A0 =C2=A0valu= e MUST only include the latest ARC Set headers as if this newest ARC
<= div>=C2=A0 =C2=A0Set was the only set present.

I think it's weird that the body of content that = gets hashed by the sealer in this case varies from what would normally happ= en.=C2=A0 A verifier might have to try two different verification algorithm= s if, for example, it doesn't determine that the chain is structurally = invalid.

If I receive a chain that was apparently valid a= t the last sealer and determine that it is no longer so, could we simply de= cline to re-seal it at all?

-MSK
--000000000000ab90f00571fcb66f-- From nobody Fri Jul 27 08:35:28 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C83E1130F8D for ; Fri, 27 Jul 2018 08:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uWuEEG8jBE6 for ; Fri, 27 Jul 2018 08:35:24 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC216130E74 for ; Fri, 27 Jul 2018 08:35:23 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id k12-v6so9765504oiw.8 for ; Fri, 27 Jul 2018 08:35:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0N4UiLVNuTXeqHzmtZg0dVPO0ElxZvBm+KwSg5gDxHo=; b=iqjuI8/tujO4IQyggDe4czJ35tnEUHRtFvA4WKMdWCZ4flMOX8d65hnpKO1IgBcqOr ysmewjy0lkMV7TFEHQOl7t21Zc6n34iTAHHYiclfJv84Z7hdGZnID8ikciYKyiic6Wwp vhXQV8NiDHvH2jJ29OXyILpIVWkSXARiLuAewZVKaGjCKrctdohUjjUC07l5EL3QNVco 7oT4FBrURcACOoKig7TtVwA6SINJOxpV/wRC8bTpoyMp9zAXDAwQDnwuJoO81HLirLqF ZCTXvNZaznUDNoPLa3+uO4dngIUdLPhYUBA3Zpaib6vGln8zY8huMaukHJ/d6d+p93wd WcLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0N4UiLVNuTXeqHzmtZg0dVPO0ElxZvBm+KwSg5gDxHo=; b=js4RsTqkoUbUyl1hxjFKhW1deNU3FOm+QNiUXZUlASzYeY/ZG6T8Ma0wjEljgoINEV zK0LWAE+/uOTYVDW9UGJSsi4dmj+xpBZ+qX8q5681Cm0YhHJkHTuRbWW7olVUyypL2mh /+RovtHLQ++9TvZH4CK4Kh2pippbkagNxblTghfwGd/WgB1ufrxb4OlUmuUUifNYXY5d 91bE9+mTkFcB9w9iccyFwKmf9HCMmfoCx0xN/iLBPqwbpB+5m2IttVfD04ZVo/Mj7Iht yOtF3DOsf45FGCstL5TyEfxk4go8LoqIftyPsaLyYLzR7nnxQ3VKl96fWjzGsdm222XI vYHQ== X-Gm-Message-State: AOUpUlGYzFGKZ724909p7C7MlkBErCr4H4HElvnUrmPwDq5KoRHSjwa5 EM2ExlxHpPLvLUNMbeMjWx7ZZHCF8MO2DZIJnPzIFA== X-Google-Smtp-Source: AAOMgpf0hWhxjzX2Bk73KtI2l8Bddd6qVv/fPO8Z+aIqRTnryQ4rfeu/FUki2AeTRqJ3PQEyGHQj70zDlOFmySjJABI= X-Received: by 2002:aca:d9c5:: with SMTP id q188-v6mr6579560oig.239.1532705723036; Fri, 27 Jul 2018 08:35:23 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Seth Blank Date: Fri, 27 Jul 2018 08:35:11 -0700 Message-ID: To: "Murray S. Kucherawy" Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000002acc310571fcdc33" Archived-At: Subject: Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 15:35:27 -0000 --0000000000002acc310571fcdc33 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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= r > in this case varies from what would normally happen. A verifier might ha= ve > to try two different verification algorithms if, for example, it doesn't > determine that the chain is structurally invalid. > > If I receive a chain that was apparently valid at the last sealer and > determine that it is no longer so, could we simply decline to re-seal it = at > all? > > -MSK > The verification algorithm is straightforward. If you receive a chain that ends with cv=3Dfail stop your evaluation, you=E2=80=99re done. There=E2=80= =99s no separate validation path here. Additionally, I worry about the security implications of passing along a known bad chain without terminating it. Right now, worst case, one intermediary needs to evaluate and terminate a maliciously formed chain. If it=E2=80=99s simply not Sealed, then everyone in the path must perform the evaluation. I don=E2=80=99t know what new vectors this opens up, but I coul= d foresee some cascading issues. --0000000000002acc310571fcdc33 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Fri, Jul 27, 2018 a= t 08:24 Murray S. Kucherawy <supe= ruser@gmail.com> wrote:
=C2=A0covering the ARC header = fields in the failing chain, all the data in the failed chain can be modifi= ed as it is not covered under the latest signature.

I think it's weird that the body of = content that gets hashed by the sealer in this case varies from what would = normally happen.=C2=A0 A verifier might have to try two different verificat= ion algorithms if, for example, it doesn't determine that the chain is = structurally invalid.

If I receive a chain that was appar= ently valid at the last sealer and determine that it is no longer so, could= we simply decline to re-seal it at all?

=
-MSK
The verification algorithm is straightforward. If you receive a chain = that ends with cv=3Dfail stop your evaluation, you=E2=80=99re done. There= =E2=80=99s no separate validation path here.

Additionally, I worry about the security implications = of passing along a known bad chain without terminating it. Right now, worst= case, one intermediary needs to evaluate and terminate a maliciously forme= d chain. If it=E2=80=99s simply not Sealed, then everyone in the path must = perform the evaluation. I don=E2=80=99t know what new vectors this opens up= , but I could foresee some cascading issues.
--0000000000002acc310571fcdc33-- From nobody Fri Jul 27 10:20:10 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5547130FA2 for ; Fri, 27 Jul 2018 10:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqkjjV_60nFV for ; Fri, 27 Jul 2018 10:20:07 -0700 (PDT) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1400130F9F for ; Fri, 27 Jul 2018 10:20:06 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id f135-v6so4016126lfg.10 for ; Fri, 27 Jul 2018 10:20:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ofJhQ0e6jMK/nVS5prjeDHi9zdaSHXZuUKMixSAv5Do=; b=lOMuBrZpmjwRe55BpILlSblLrV46uinzx9gSq9zdmVtfaX4XuS6eIlV3NskLbNs0YN DuFh84WVxk4j7SByivWuzQyKHxDsOKDz1x5GyCs5c35ZuueHPdddZrD9jxlTjuhT2aMa yACUGovl5SHVAt9KkKV9uSHU6rU65BrGR8dRc9XpazmiwLT0WzEIgFzAThh2XPa74xu9 V/joXPTAUwR/VkiU126HPitPMa3k5D0M0whEpCLf0AnSxMOC42hi+iNAsKK8MVV4ZGwi Iwxl/gqpNG1acABp+JHRhhKwJnhqj9E8BDAOI0fkGTNb2XGz4j6yB6L3jOyfGP3yJV4G Sxjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ofJhQ0e6jMK/nVS5prjeDHi9zdaSHXZuUKMixSAv5Do=; b=OLt/2ZzbQE3QGZfNzKFGi/qSaem+DHZZgPcrj1Oeh8X7mnZ3cMBERoTaizGqfQVSTc S5AO7b0Ui3bKHDbdSZ16gXqHs/Wg6GpXS8tcOHrsU0DRNXuTymz/Hh1Cw5nz34Wc+awl ipKv/V9cUxVbDLgCPGiJjuybQTzCTHur82HvTxBns8OdIaEFRm5ViNFo6E9bnxJhoPlL nD9Hu52AkOHzBet574H6tWQ1lJ14OuMP12u4iwOFbm4/1I0oknjfPbGXrw5t8T3rpW3b RbdYZJQDmCsmiCkOaZgpzUysaGAW3HQV2bTkj7Xo8z0UgBILcklBZEtZCWbV7p7VxdOa /8VQ== X-Gm-Message-State: AOUpUlElVW+1AC2s7/A/FbxIXSLdXsKgezzBBi5t8ItuiPainkWJ3pcs 3FIQ/GcN6evyaI8wjm8YUBLLtXV4p1HuFT+ODjE= X-Google-Smtp-Source: AAOMgpcVixWygeK0FbNw7/8j3gsO6WdEk3f4EkMwVZRQ5c0BLB/zB8KHm8dnKjxdTrButQWz2jZbfvUZ0a//lklMK2o= X-Received: by 2002:a19:dd5c:: with SMTP id u89-v6mr4471399lfg.83.1532712004791; Fri, 27 Jul 2018 10:20:04 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:3a13:0:0:0:0:0 with HTTP; Fri, 27 Jul 2018 10:20:04 -0700 (PDT) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Fri, 27 Jul 2018 10:20:04 -0700 Message-ID: To: "John R. Levine" Cc: "Kurt Andersen (b)" , IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000096b17b0571fe5218" Archived-At: Subject: Re: [dmarc-ietf] WGLC ARC-16 section 5.2.2 should be stricken X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 17:20:09 -0000 --00000000000096b17b0571fe5218 Content-Type: text/plain; charset="UTF-8" On Fri, Jul 27, 2018 at 7:03 AM, John R. Levine wrote: > > Ah. I still think it should go, but if you really want to do that, invent > a new enhanced status code. They're cheap. 5.7.7 isn't right, it's more > like corrupt S/MIME bodies. > > I did a bunch of these (for DKIM and SPF at least) in RFC7372. You could clone the template from there. -MSK --00000000000096b17b0571fe5218 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jul 27, 2018 at 7:03 AM, John R. Levine <johnl@iecc= .com> wrote:

 Ah.=C2=A0 I still think it should go, but if you really want to do that, in= vent a new enhanced status code.=C2=A0 They're cheap.=C2=A0 5.7.7 isn&#= 39;t right, it's more like corrupt S/MIME bodies.


I did a bunch of these (for DKIM and S= PF at least) in RFC7372.=C2=A0 You could clone the template from there.

-MSK
--00000000000096b17b0571fe5218-- From nobody Fri Jul 27 10:21:15 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B270F130FF7 for ; Fri, 27 Jul 2018 10:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9K6FS-dNDs7 for ; Fri, 27 Jul 2018 10:21:07 -0700 (PDT) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05DC1131006 for ; Fri, 27 Jul 2018 10:21:07 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id u202-v6so4015034lff.9 for ; Fri, 27 Jul 2018 10:21:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wR1DBpsYKKqy7RarmFQeu6JaviypIKYn3WqQlHHLJAI=; b=kNGoMbUxEK3sSVYKXOjTG84D+QkPlkdEtekpIkQqUhKT5Jn6UTI8GWUUxUIkfE9jcl 2KXf8kpfDjdLH1KLUs8wzUG0KMvsYb3b/IKncoxyxWWn9w1qKoVvpPE1FuJV82v7g+Q2 /K5p14Fi1g526ywosth9vcAHEK3xXwskOmaJOhlVR3l0yq2M+o8FMZhT2pKucV6i667Y F2HjGqMI3eryC8Zbmmep3UpgHFN0IExPavQ6STzu6PI+fCOnwWUDa7NyEU2eco5Y8Ujo FKWv8GB9hjWgIjAKBZGCglFMURvx9uF7+9o6a5ukASVB4sDzexriYroS4QCXcTe1aQqm viZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wR1DBpsYKKqy7RarmFQeu6JaviypIKYn3WqQlHHLJAI=; b=gW0W4jBOk6/O+b0u27KVIZFuO0bP3qFGOe6qByIbiHvLwhpquup33GJimyrCIpCatD BOxxM88PMZvz3vzEkbP6Yqwco+JQA38JYxF6pNw3+lsV6XcVylG8mdJhQfN9pCieH4ks n/KfaLgDgJAcsBhlD5omRwDmbdEUr2Ctc+Ga7H55xs1lbtCQhhpDqsplgspoeidmbnwB 5fMaEEfctr5/suLHPHYM/fDRWMLU3PT8S8ChATtc09UD+9nq9/OPxFf3i3boIXu/oZbl JQRdUUBZmPSTgTaAlWhqIGgLeppwDO1+OR10Twr6ZXkfxcXCDFYSwr9JVB66IOVGMAdS NR7g== X-Gm-Message-State: AOUpUlHgtSl7lj3V2COgk0GTkvu+Dv0MHW17J4shITW4gF3h7mNkrfBK jlKg74kmiQPZ4Ce/1lIZ24ZJltxMkRXrTshAogFg7Q== X-Google-Smtp-Source: AAOMgpdfMopeBUhzGSs0sVyGAsDsnK2tkgYRZOjtLm7IT9Ulpz1TPYNWvPIY592HhIrOcLW9IU3RkoMYg6megsLqFEs= X-Received: by 2002:a19:73c9:: with SMTP id h70-v6mr4810130lfk.61.1532712065207; Fri, 27 Jul 2018 10:21:05 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:3a13:0:0:0:0:0 with HTTP; Fri, 27 Jul 2018 10:21:04 -0700 (PDT) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Fri, 27 Jul 2018 10:21:04 -0700 Message-ID: To: Seth Blank Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000030920b0571fe5620" Archived-At: Subject: Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 17:21:11 -0000 --00000000000030920b0571fe5620 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jul 27, 2018 at 8:35 AM, Seth Blank wrote: > The verification algorithm is straightforward. If you receive a chain tha= t > ends with cv=3Dfail stop your evaluation, you=E2=80=99re done. There=E2= =80=99s no separate > validation path here. > Then why bother signing anything when you affix "cv=3Dfail"? -MSK --00000000000030920b0571fe5620 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jul 27, 2018 at 8:35 AM, Seth Blank <seth@sethbl= ank.com> wrote:
The verificati= on algorithm is straightforward. If you receive a chain that ends with cv= =3Dfail stop your evaluation, you=E2=80=99re done. There=E2=80=99s no separ= ate validation path here.

Then why bo= ther signing anything when you affix "cv=3Dfail"?

=
-MSK
--00000000000030920b0571fe5620-- From nobody Fri Jul 27 10:25:05 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B419130FFC for ; Fri, 27 Jul 2018 10:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=NLbf8Hv0; dkim=pass (1536-bit key) header.d=taugh.com header.b=hRlKSqLr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l_UvmeeXnnMH for ; Fri, 27 Jul 2018 10:25:01 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4E37130FA2 for ; Fri, 27 Jul 2018 10:25:00 -0700 (PDT) Received: (qmail 24297 invoked from network); 27 Jul 2018 17:24:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding; s=5ee6.5b5b556b.k1807; bh=oPK5g+qqX7UJAD6ypcK2FwLtu8QIg5r3bH9H7F+q8+8=; b=NLbf8Hv0/I5qRrvFoll8yzN7XKvkAru7zZrEyRDamJo8l/kAXb5OMhn6p8Sf16dJkgvaNmx7HozLSN5IrOKN3j57QfkDrHsz1z/zSbdBZqXfHaje+4NaqOl0Kv+zyqPHkQDJ/wDN+Lu007T3vKEgb8bU5dgfiGfW/ECi1RXxrpP9dJFoSuIe4mfaOfm8m/W0Q1DNTv34WuxCHpHAbpNEmrwr5WVx88LLdHVeErZsE3DelE9gKn9C3GCR/NaZ3C1E DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding; s=5ee6.5b5b556b.k1807; bh=oPK5g+qqX7UJAD6ypcK2FwLtu8QIg5r3bH9H7F+q8+8=; b=hRlKSqLr359bETevh4TA+5YZAf0sFVJTKHhd/WLj+O1CU+57zdFsi/MRARBntYpQGsF6aXRMp5uxOBidHs6OWh2nMRYexdtx9fsLKGPNs5BioPhuCgWm/W2su4uU8KuhntJmvHAF6Uj2UqGOHYDvwGVMeZetwzr28IYAA4Oi1IBiJMJfkuI5+wsA7yw2EkYEVJl9jw7VBsVG4LNcepShd4Cx3eeSVoBT9QHI1Iqf5Me3y2Qq9pSfyWZUDJU4yAxK Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 27 Jul 2018 17:24:59 -0000 Received: by ary.qy (Postfix, from userid 501) id DABC22002E2E0E; Fri, 27 Jul 2018 13:24:58 -0400 (EDT) Date: 27 Jul 2018 13:24:58 -0400 Message-Id: <20180727172458.DABC22002E2E0E@ary.qy> From: "John Levine" To: dmarc@ietf.org Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: [dmarc-ietf] ARC-16 signature domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 17:25:03 -0000 The ARC draft clearly says that every ARC header can be signed by whatever domain you want. I understand what that means technically, but I don't understand the semantics of an ARC set where the AMS and AS are signed by different domains. R's, John From nobody Fri Jul 27 10:29:53 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4CC130FA2 for ; Fri, 27 Jul 2018 10:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQE2owlBFZVY for ; Fri, 27 Jul 2018 10:29:47 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC228130E8C for ; Fri, 27 Jul 2018 10:29:47 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id k81-v6so10395141oib.4 for ; Fri, 27 Jul 2018 10:29:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=W0nS4Ky8O+mgDTBVrxoCih6JLa4m/pH3boA+QPy0Ghg=; b=Cqgj/P4nKg/6MpGnNuAWA1JMdQpXcf/sRvV9kTYWVPJ6PW85KZ+ZAvLHKHSdhQPerz sT5XrCw4RN1YuvLGT0FoxnSrulICR/g9TXvFFecvVb79xVsPU+VZcerRGC855ZahrjM3 pzBguQ5JVEBMzToI5H0pyZO8gY6xJx8ojcQsMo65XBSr6IRWm9FSuV+uJyeB0/hov14T WdMlZ6X2JwAzIVQmMyT65kV1up/6Cvz9PMf+5ed4sIz4ICLFVzSL04kQoZYzIdQIvJsx hBv/hg4OLMhpobaiDDFMjgMawu0jxPEzPlAbZlyFf4ymxHTzTZ0B8erCaxpCyujbZ4Mv DMMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=W0nS4Ky8O+mgDTBVrxoCih6JLa4m/pH3boA+QPy0Ghg=; b=Npqx1BjSgrfBnP5X6wOjdrGv15sQs4opWBDIMvH+YrJnu3JXD0uxzr0xJZ9iqLrFKR Ii4iuzgJwJt9YXbDp/me07dILM5zLJ8hKpMpgMpvndl/pkeu92JItRFb5aevMHA0pAQm a2GEIavxue82GaqOWL6PM0nN0Ic2+XGRhdWjltx0wNeh0hQdsJ1J3V8wPwWhdcbJTvd7 ML66ParaI+bl/NO+4TREnFioA6ckzcu5Yg8Rt3qGWkRAE4QfX8DTL1eTwDOM5DVQJzZ2 kplM390kycbnfoj3zHGjZi5Sk2+M5xv9jQrvMkO9FUI+tRmBLVkXyT0DWUyLxzLi5SMW 78uw== X-Gm-Message-State: AOUpUlG7KapRMNZKc3RO/rRJsDmHf0txg6tcNOmEBXNiSLrlbZKz4QAv zJh3Ghn5iJvem9aKh69mKuR0ndpA/wRTW8fJazRTPz9q X-Google-Smtp-Source: AAOMgpdefok3LyrxBOEMtfzdmmlirmtMlqDeVNdOg9pMd8iHx/YYik/pDMbK5yFnV2UiHFyLlGF6/v9fiAIF4TycQME= X-Received: by 2002:aca:3d05:: with SMTP id k5-v6mr6843806oia.86.1532712586540; Fri, 27 Jul 2018 10:29:46 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:2646:0:0:0:0:0 with HTTP; Fri, 27 Jul 2018 10:29:26 -0700 (PDT) In-Reply-To: References: From: Seth Blank Date: Fri, 27 Jul 2018 10:29:26 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000004391820571fe75ee" Archived-At: Subject: Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 17:29:51 -0000 --0000000000004391820571fe75ee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=3Dfail stop your evaluation, you=E2=80=99re done. Ther= e=E2=80=99s no >> separate validation path here. >> > > Then why bother signing anything when you affix "cv=3Dfail"? > Because adding your ARC Seal over the chain guarantees that the receiver has a complete list of everyone who modified the message up until the failure. Without this signature any failures cannot be localized, and any ARC data in a failed chain could not be trusted. This data is crucial for analysis, understanding the experiment, and reporting back accurate and untampered information. --0000000000004391820571fe75ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Jul 27, 2018 at 10:21 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:
On Fri, Jul 27, 2018 at 8:35 AM, Seth Blank <seth@sethblank.com>= ; wrote:
The verificatio= n algorithm is straightforward. If you receive a chain that ends with cv=3D= fail stop your evaluation, you=E2=80=99re done. There=E2=80=99s no separate= validation path here.

Then wh= y bother signing anything when you affix "cv=3Dfail"?
=

Because adding your ARC Seal o= ver the chain guarantees that the receiver has a complete list of everyone = who modified the message up until the failure. Without this signature any f= ailures cannot be localized, and any ARC data in a failed chain could not b= e trusted. This data is crucial for analysis, understanding the experiment,= and reporting back accurate and untampered information.=C2=A0
<= /div>
--0000000000004391820571fe75ee-- From nobody Fri Jul 27 10:37:06 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF596130FF7 for ; Fri, 27 Jul 2018 10:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q795_WP5IdsO for ; Fri, 27 Jul 2018 10:37:02 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6F49130E0C for ; Fri, 27 Jul 2018 10:37:02 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id k12-v6so10434358oiw.8 for ; Fri, 27 Jul 2018 10:37:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=e3Bc2ptEPYJcL2QfMn9b+h/64oaKNY07U5+YL8AyHnc=; b=f0cV/Tt50B7713GtanZ5QN/9rEqXRv2n6YuaQMiWH7kURWIhRuR62fMA2m5PBdyaeK CcDgiawBxMIAGJ6blFGLGUxYEIhfY1zyPA71O2kx0oeCHNZq6N2RGe8MRbSlEYWVzAfc 88tfc+x0w8+SVgz5XMZZBn0nmqvFeOaAlvrvRUEiIEEGYRPyHf9uJpHBdOKL7QJiX4jD V9pIGIjI293dU1wakJ14MJIT6LPmBKx+eP9tM6nafscCHxrHzp9A/sNBnaQWUmGIHAqX emC8TsgSFd8cRSznAzIej70dKEWBesb0yk9Cq2PVDZZIzM7rrv5RqYUcfgVDYCCZvhv1 CaTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=e3Bc2ptEPYJcL2QfMn9b+h/64oaKNY07U5+YL8AyHnc=; b=a/h1t9kqKu4fF6nzNBbYKNRbiix0wurMRoiQDucIkBWO2Ab8kQv6PNnwbTp4gbJpDy /YsIfiC+6qTiF9qjs63zDnzzJ4pWL3ojn/B7oZVFvYFRnRcO2SFf6QhYCgYBfX8nEOly t9CKJyEH9h2vvCkcF/77lhRtXZNoP0exEiwzzkChDe4ygE8MhXw6O5m/kjSKzAnkIhYR NUBeAauCP9CxYfi3FxBrNxAJLjhwQAMf8TQTxkbHxIFF/tJkxQ/di4N4D5sE9N0yMO8i a6kLtISGsSEAgiMQMI7VFlo+P0XAM5MUalmyQrNOkyF80HoGNdutK4e3mifvL2gfIxyG A81g== X-Gm-Message-State: AOUpUlFVEWnj1RKpg7sF9G7XmkK6v+rdfEQYYcXg4fyZUddeGkVZzTa7 8Vqcg34wCZClfUrQ7fa2pResPIsC2D8A9YfV+QJuNm2m X-Google-Smtp-Source: AAOMgpeO/XkDlHVHTPN29wMHIplyAz0Ol87utYjPxtGdFHzb3qi6IeByOg2c/cYG13+To7zJBp1O7AzUBqjYrWyPbxQ= X-Received: by 2002:aca:b355:: with SMTP id c82-v6mr7931281oif.9.1532713021653; Fri, 27 Jul 2018 10:37:01 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:2646:0:0:0:0:0 with HTTP; Fri, 27 Jul 2018 10:36:41 -0700 (PDT) In-Reply-To: <20180727172458.DABC22002E2E0E@ary.qy> References: <20180727172458.DABC22002E2E0E@ary.qy> From: Seth Blank Date: Fri, 27 Jul 2018 10:36:41 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000032ef280571fe8fb1" Archived-At: Subject: Re: [dmarc-ietf] ARC-16 signature domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 17:37:05 -0000 --00000000000032ef280571fe8fb1 Content-Type: text/plain; charset="UTF-8" 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 domains could make sense, such as the AS being signed by an organization, and the AMS by the service within that organization that performed the modification. For instance, AS d=example.com, AMS d=examplelists.com. This seems to be something that will become clear with data: does everyone sign with the same domains? Are there clear use cases where people want to use different domains? Since there was no technical reason to go either way, and requiring alignment gave no benefit but added additional normative language to the text, we decided to hold off and instead call out a recommendation to keep them the same ("a receiver might treat a different domain between AS/AMS as suspicious") in the usage guide until real world observations changed said guidance. On Fri, Jul 27, 2018 at 10:24 AM, John Levine wrote: > The ARC draft clearly says that every ARC header can be signed by > whatever domain you want. > > I understand what that means technically, but I don't understand the > semantics of an ARC set where the AMS and AS are signed by different > domains. > > R's, > John > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --00000000000032ef280571fe8fb1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This was just discussed in a thread with Jim Fenton last w= eek (although from the DNS angle).

The tl;dr is that we = don't believe they'll ever be different, but there's no technic= al reason to require d=3D/s=3D alignment between AS/AMS for the same i=3D.<= /div>

We can foresee places where separate signing domai= ns could make sense, such as the AS being signed by an organization, and th= e AMS by the service within that organization that performed the modificati= on. For instance, AS d=3Dexample.com, AM= S d=3Dexamplelists.com.
<= br>
This seems to be something that will become clear with data: = does everyone sign with the same domains? Are there clear use cases where p= eople want to use different domains?

Since there w= as no technical reason to go either way, and requiring alignment gave no be= nefit but added additional normative language to the text, we decided to ho= ld off and instead call out a recommendation to keep them the same ("a= receiver might treat a different domain between AS/AMS as suspicious"= ) in the usage guide until real world observations changed said guidance.

On Fri,= Jul 27, 2018 at 10:24 AM, John Levine <johnl@taugh.com> wrote= :
The ARC draft clearly says that every A= RC header can be signed by
whatever domain you want.

I understand what that means technically, but I don't understand the semantics of an ARC set where the AMS and AS are signed by different
domains.

R's,
John

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

--00000000000032ef280571fe8fb1-- From nobody Fri Jul 27 10:39:28 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D005130DF6 for ; Fri, 27 Jul 2018 10:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mh1Udjl8ViUD for ; Fri, 27 Jul 2018 10:39:24 -0700 (PDT) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08F6D130E0C for ; Fri, 27 Jul 2018 10:39:24 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id u14-v6so4054252lfu.0 for ; Fri, 27 Jul 2018 10:39:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=15UZNkC9SsNuzVQa6IvWieZu8q8jlRuDS85IVd9KmkE=; b=QAXwFyW+GhcS57ZKYS8HNFrZEDtCJCCrb1Rp8YK2pFWaPKpWcA1W9441+NkQMvKkz/ 4SKDW7/js0zMOPamumSvWS3s4/lhIh4GfV00KxqCSD0aaIiLNqCGhIJJvOo/CYTCRwbh HfBOMICa5Pkg9O+TDsLwjs1pKZizujvTpzOx1IzCg05X3IhvGI7H94dz6t4PUfJqLhZh ukaXmrkkwTVquhBgM8W0p762uEBWxykSmEo+sVwVFGiI/wMgM+USj8zDcTj4QdFPdgrS lXP7mHbYV5x5/V3CQwEA8uJj9wndrTh/KbC2lxd+rNwziqbnIBhpteeoDP+8RcG967ic SlIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=15UZNkC9SsNuzVQa6IvWieZu8q8jlRuDS85IVd9KmkE=; b=eCMWu36FYaiTO7N9NcSi9G6q8fkb2v2SYYpUyio8lAQsMlzChepCGCv0xoS7i7JCOz EidxR9mkoZqPA8P9BQKYjD0BTy/VckBxZijdcVm2Lu02NmqQK3jlgpLjz9/zqkvRMphE eHD7VP2y2sQ5PbTbdTRbDjzCtpHhKSiTzjmu7JJuJjiMMUxzeDTwruOywA32Bu60f9T+ hhT0qOOtYGDL4tBYWGKAzZPTdehBEKU4WXSLQmAtMck2NIBOb/1MObBKuttJOQG9VZj7 ZYda52fjajE6tU+PrhBLZEPyFScUXZaFsIt8r2a10tnSwk8fvkXFZk0/skdyTxtgbqV9 AhIg== X-Gm-Message-State: AOUpUlHdEf+5/h5tbGul5KyB/lSgJezM5DEr9RPZxIs+Qxa9jeDNW0T1 TFyZBtZeP3VwZdftsOUf98VCK6dboL+elNZd2eVrxA== X-Google-Smtp-Source: AAOMgpckDMWzcYCbbDBhQc7uJB1iwbowqorzp4tcYcvDWooNfXnN3b7Ftv7ipeAkU9kB5FOFhsQu6+7DAtRl2xKKPWg= X-Received: by 2002:a19:dd5c:: with SMTP id u89-v6mr4504786lfg.83.1532713162186; Fri, 27 Jul 2018 10:39:22 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:3a13:0:0:0:0:0 with HTTP; Fri, 27 Jul 2018 10:39:21 -0700 (PDT) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Fri, 27 Jul 2018 10:39:21 -0700 Message-ID: To: Seth Blank Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000009326bd0571fe976d" Archived-At: Subject: Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 17:39:26 -0000 --0000000000009326bd0571fe976d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=3Dfail stop your evaluation, you=E2=80=99re done. The= re=E2=80=99s no >>> separate validation path here. >>> >> >> Then why bother signing anything when you affix "cv=3Dfail"? >> > > Because adding your ARC Seal over the chain guarantees that the receiver > has a complete list of everyone who modified the message up until the > failure. Without this signature any failures cannot be localized, and any > ARC data in a failed chain could not be trusted. This data is crucial for > analysis, understanding the experiment, and reporting back accurate and > untampered information. > But (and I think this proves my point) I don't know if "cv=3Dfail" refers t= o 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=3Dfail". I remain confused. -MSK --0000000000009326bd0571fe976d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jul 27, 2018 at 10:29 AM, Seth Blank <seth@sethb= lank.com> wrote:
On Fri, Jul 27, 20= 18 at 10:21 AM, Murray S. Kucherawy <superuser@gmail.com> = wrote:
On Fri, Jul= 27, 2018 at 8:35 AM, Seth Blank <seth@sethblank.com> wrote= :
The verification algorithm is= straightforward. If you receive a chain that ends with cv=3Dfail stop your= evaluation, you=E2=80=99re done. There=E2=80=99s no separate validation pa= th here.

Then why bother signi= ng anything when you affix "cv=3Dfail"?

Because adding your ARC Seal over the= chain guarantees that the receiver has a complete list of everyone who mod= ified the message up until the failure. Without this signature any failures= cannot be localized, and any ARC data in a failed chain could not be trust= ed. This data is crucial for analysis, understanding the experiment, and re= porting back accurate and untampered information.

But (and I think this proves my point) = I don't know if "cv=3Dfail" refers to an invalid chain or a f= ailed chain.=C2=A0 I have to run the verification to figure that out.=C2=A0= But you're saying you just stop when you see "cv=3Dfail".

I remain confused.

-MSK
=
--0000000000009326bd0571fe976d-- From nobody Fri Jul 27 10:40:37 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 142AF130DF6 for ; Fri, 27 Jul 2018 10:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZSeD7d6NXn0 for ; Fri, 27 Jul 2018 10:40:34 -0700 (PDT) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE76C130E0E for ; Fri, 27 Jul 2018 10:40:33 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id j143-v6so4049456lfj.12 for ; Fri, 27 Jul 2018 10:40:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rkXqsRR2/0x8+BeyL7s/Qbmx+nsxQb0rHEjF/oU3dWs=; b=rPtCuyNW9IkXicYYq5ntHNfTECBaWrCFg67nOfiA03YWXyDIVArZ32T7evlZ+xGigd yoIrbd1y8WXb/VYiIKbd6qsCXyZKEFZ4ssy2goGiJG62W7OKidy7d8ZDo8WwOKSUfZ95 U5wdrm11W5+/OnV/JMaIKQmKEmzTIDUSmJSHWAYddwwlSt0Hue+ijXiuba4nyoSgLnVA MquKDDpJbWcJ3NGXFhtR18KO9zzKvDI3BX+tmbFQtkRIFBBPEm+ZQpT25ZvBWUQZrtFJ OlT/eRBFe7Bo31sTEZINVVF9XNTlMZQcxjux5Z9Gr46iW1SJVDxJVABfK/mqD4ex+NvI 4JKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rkXqsRR2/0x8+BeyL7s/Qbmx+nsxQb0rHEjF/oU3dWs=; b=ZOpfjFV6/QcsKiRFjEdiQc3s+3g/sZ0aeI7haSeTLO2q7VAZdM6/1Cyb2G/viTEdQY iYQ7dBvubLxPzDl/0Rcr5QBTWf0mY4B9sBGSrAOKngFzIFf+6Q7336p4op1YrHNGXlmE HXUPkyqVYguiEax0HzkRiwdVNmVbWy5/MZmj35CjEuECbxRcRMMCR5LFHlrhn2OtyA30 7qOE8kcvOAGssvESiY9CSolmPuLNwFleFWU7ZkiQnEDO3s+AT6NaMFg62ZsFi8WrLJcg 9Doi/2TYJQ9ZCK5VJAqqjPr2aHuJd2GUWAF9MwuBX1hvefmRVgiC0/DAtJd2QhzT18BF Ea3w== X-Gm-Message-State: AOUpUlGAbTW/1jrLcwqmkz6hlK/oI+1QkPGNcMzHFFBchcL/Dz6WzwzD 5fpGYYLpiXcY4BA4dxd2GAwmzk1MFnyuFmOOorac/g== X-Google-Smtp-Source: AAOMgpfzwr8IeuZz5+qlRqZZb6qLWYM5cWpfER7YrQMq+WeEfZCj4yIt18jkTzDIuLzHGvR3xM7pev4Ddwm58QUfyVs= X-Received: by 2002:a19:6801:: with SMTP id d1-v6mr4725747lfc.8.1532713232081; Fri, 27 Jul 2018 10:40:32 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:3a13:0:0:0:0:0 with HTTP; Fri, 27 Jul 2018 10:40:31 -0700 (PDT) In-Reply-To: <20180727172458.DABC22002E2E0E@ary.qy> References: <20180727172458.DABC22002E2E0E@ary.qy> From: "Murray S. Kucherawy" Date: Fri, 27 Jul 2018 10:40:31 -0700 Message-ID: To: John Levine Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000bdc9560571fe9b9d" Archived-At: Subject: Re: [dmarc-ietf] ARC-16 signature domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 17:40:36 -0000 --000000000000bdc9560571fe9b9d Content-Type: text/plain; charset="UTF-8" On Fri, Jul 27, 2018 at 10:24 AM, John Levine wrote: > The ARC draft clearly says that every ARC header can be signed by > whatever domain you want. > > I understand what that means technically, but I don't understand the > semantics of an ARC set where the AMS and AS are signed by different > domains. > Are you saying we should proscribe it, because its semantics are unclear? -MSK --000000000000bdc9560571fe9b9d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jul 27, 2018 at 10:24 AM, John Levine <johnl@taugh.= com> wrote:
The ARC draft clearly says that ever= y ARC header can be signed by
whatever domain you want.

I understand what that means technically, but I don't understand the semantics of an ARC set where the AMS and AS are signed by different
domains.

Are you saying we should prosc= ribe it, because its semantics are unclear?

-MSK
--000000000000bdc9560571fe9b9d-- From nobody Fri Jul 27 10:41:15 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D50D130FF7 for ; Fri, 27 Jul 2018 10:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=bsWaIJRB; dkim=pass (2048-bit key) header.d=kitterman.com header.b=skVtIhcx Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bruxqiaybaMY for ; Fri, 27 Jul 2018 10:41:11 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5491A130DF6 for ; Fri, 27 Jul 2018 10:41:11 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1532713269; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=DfmXy7jNSSxKz3N1KgR1C1JA44ueIGzFSIotKh37o0k=; b=bsWaIJRBluLs7BXRp/jhScG4kskqGw+cZ1tcnjr0jpFTdUV+0kXQQPQa WoN1UlLeaI1rWhqP667KcEfQKarLCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1532713269; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=DfmXy7jNSSxKz3N1KgR1C1JA44ueIGzFSIotKh37o0k=; b=skVtIhcx6v1Eevsiw0FavcnqtAyXGYEyhF5Leivq6g6Pm0Fq/uLQ1QGb mvd7XSeSgs2HhewdccrsMAtOaSn83nb4OliyQ83vg+zWn/Cya1ld1z97VQ +tMYoq79iEvPD0MYBL+O+hCX8Tjgp2rEWFu690sEownFwtwx6VWQHloY3k MsO3td27N/JM9sJIPvZGopUFFdjbvksb+byvgropuzc7Cbxhg1ekQ97AJM X+MVU+b3sKAQuivNVLlu16EoII832Kp6Bd3+vinD1PN6+JQOe6sanN4Fa8 EwHH+Lw/EXVX2AfOfQWgX+5+oDNOwziDsiNvgyOSXVgppr3URuBIeg== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 23CF0C40257 for ; Fri, 27 Jul 2018 12:41:09 -0500 (CDT) From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 27 Jul 2018 13:41:10 -0400 Message-ID: <3653158.NzzCYWEyKs@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-147-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] WGLC ARC-16 section 5.2.2 should be stricken X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 17:41:13 -0000 On Friday, July 27, 2018 10:20:04 AM Murray S. Kucherawy wrote: > On Fri, Jul 27, 2018 at 7:03 AM, John R. Levine wrote: > > Ah. I still think it should go, but if you really want to do that, invent > > a new enhanced status code. They're cheap. 5.7.7 isn't right, it's more > > like corrupt S/MIME bodies. > > I did a bunch of these (for DKIM and SPF at least) in RFC7372. You could > clone the template from there. 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. Scott K From nobody Fri Jul 27 10:44:18 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FEC8130FFF for ; Fri, 27 Jul 2018 10:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRzGyVUJv7Mg for ; Fri, 27 Jul 2018 10:44:14 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE05F130E6B for ; Fri, 27 Jul 2018 10:44:14 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id y207-v6so10472199oie.13 for ; Fri, 27 Jul 2018 10:44:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=jke71iWwWdmOIE3B5dDZXkAsNB7ubUFFjnbfGEfBhlY=; b=q8hrFyP4jIyz47B4wv46/SsLIdlWwg/1liV8gxlIpjVDsZPFtHHF8pQuM9X4ecZUMO lw/NCa+5EJDZ5vAyUGp3sRouk92ms5wxHLqvOH/5kYpcyRVjbMX60BVQJPFUKKWTTA+3 mumOywREVcW6CnZS16W3hG8HviBwFGJ+JdxD/lWhNqggtx8c1YG+J6Yj0fLe1a4hbDtg tzMhFAbGQOApPcmhp7gTzIrMZjbXtLTcMzt9vI26qCNGLty/5hMw8cPRpiaOjdOHhdnE BL0RDIqHDGXPgTM+LzTf7JDKd/1FLngxZJzvuPtQtRKJUjxH5HiCzsJAxK8W3TFwTigM 0ROQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=jke71iWwWdmOIE3B5dDZXkAsNB7ubUFFjnbfGEfBhlY=; b=gPujU3YBuJOdDd1/P4lCfRUpur3UO4GqUssVJxPt3z30gTo1X+D0dU2GzDHJcf0H4p 2mzVF4Fh2LdTtnNKBbW6DkxORZ4xCemcCYzLOBPY+ea+G+nDeI22ti6/QGwA8alxTW4N hCvX0w/H+XZBbtd/PByNBNvL/VYvPgbtfAohtZNHQHKBdKEpng+T0udj2nVGO6PmtpgN 7gf/RDqatgsbqsFD+tIH1QVzngK8yf0MzW/Vk2awP5esjhj4w1Y0I5xI0JIV9c95jbkt RwGWulHFuS90TzEoX6Ve/jY9cMWDzqVEoWycK/LPXgaAR3Nce0ltWUSc4hDruA51DfFU ergA== X-Gm-Message-State: AOUpUlF3xMk4wtTOSE1W//oCqFB5/pKPcyf9lIErJMtVdnIzxYBI7Bu+ OljSdknCCxEhaxVGvhvuduYQLICPygW0w8RuQHbSpwy5Ofg= X-Google-Smtp-Source: AAOMgpcDAdDEK3zpF6AI23lvXMuKBFZscKiJObNgKl2b1lzA++P9VeMHqN3M5PWDX819naiLyD0C5Hk9C0bQ093q9YU= X-Received: by 2002:aca:b355:: with SMTP id c82-v6mr7957243oif.9.1532713453799; Fri, 27 Jul 2018 10:44:13 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:2646:0:0:0:0:0 with HTTP; Fri, 27 Jul 2018 10:43:53 -0700 (PDT) In-Reply-To: <3653158.NzzCYWEyKs@kitterma-e6430> References: <3653158.NzzCYWEyKs@kitterma-e6430> From: Seth Blank Date: Fri, 27 Jul 2018 10:43:53 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000f4d86b0571fea82b" Archived-At: Subject: Re: [dmarc-ietf] WGLC ARC-16 section 5.2.2 should be stricken X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 17:44:17 -0000 --000000000000f4d86b0571fea82b Content-Type: text/plain; charset="UTF-8" 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 could put simple text around if an error code is appropriate or not, and if so if a new one is needed. --000000000000f4d86b0571fea82b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Jul 27, 2018 at 10:41 AM, Scott Kitterman <sklist@kitterman.com= > wrote:
And if you don't w= ant to make a new one, 5.7.26 (Multiple authentication
checks failed) seems at least not wrong.=C2=A0 To get to this point DKIM, D= MARC,
and ARC have failed.

Is this better m= oved into Experimental Considerations?

We could put simple text around if an error code is appropriate= or not, and if so if a new one is needed.=C2=A0
--000000000000f4d86b0571fea82b-- From nobody Fri Jul 27 10:54:31 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6734F131050 for ; Fri, 27 Jul 2018 10:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ggwHZLSO0YI for ; Fri, 27 Jul 2018 10:54:26 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C315D130F41 for ; Fri, 27 Jul 2018 10:54:26 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id l10-v6so10542403oii.0 for ; Fri, 27 Jul 2018 10:54:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=ZGFgg+G0zwGoq4R2493HJdTtiB4G9BWVnPEQ/sOs4w4=; b=K7mjA5HSVBLvVfR5GANxfBkjgOmOVRqphXS90ALSXvfLq1lFLg+5lZCQMdNrRLhbec e4r59avncV+IkOMkvQZCpnCw8x734RdaE4YmGeuQznU/2rk/ZjDwArQ+yXs1xW40Xdmp GjTdCso3+IdyoszkjLlixiDZX2UqBLYyCw3oLFiewKbKL9QMqjIBXMBm2JlJOQBGALyU TntVMEYpvQ638zt/02FgCFbR9sX6YeW4g+88jSzEsccJgstnmTEntrIerYFr3DIKr4Oi 5O5cl8YAaH2QWjHFqP6YHLHCyNDltpF3LiF+p+9UwzJ6GMh8VfUju/0XTmUijHOIJWRo qQZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=ZGFgg+G0zwGoq4R2493HJdTtiB4G9BWVnPEQ/sOs4w4=; b=Q5Hzja7I2UqdPGFU2RwGnL5UKC2+Wv2OyD8/7XBt5EV0CTs5V/VCkVv4ogCE6+m/mm 0gSnsH5cuUgqtq+/rWw/iwc2pCofqy+RjK19s9J4d/f8AI4OsiotEOmHYN7vMYBRccaJ Bnj61rO/Z3WJnDHfoq621w9MNilNvmYjnRyP2ob8Q2W8U8EktBlf8hLMu2mJszzWaxM8 CDt67Kh3mljm5DSQKcxhe8zj3FvGmtrnwa1SHaojVf8pbER/Emj96SWVzaf/tn9iBnYx li7HRPTkz3fkI7McZmxP3sN+fjPyE2zJfkqv2WPuGBAqdYt/hEfsNv+XyhCa+2eQ0mxU 2n5w== X-Gm-Message-State: AOUpUlGMt8n5ZZmskHiQgq6FMH5Fpby80DY4/oNm9kJluQdQwE0Yp6wK VNpzpGXUtIXb9vv3GvJkgTDKeB0+aJFmSUbe9tNK+z+D68g= X-Google-Smtp-Source: AAOMgpeoLedbn4jNxv0Tx7RSOlaj5+wTt1CbtNrK53EXwyC27ZmqWHjr8HdkWXF87r46BrFR594btyA56yyHnZt1bY4= X-Received: by 2002:aca:b355:: with SMTP id c82-v6mr7993446oif.9.1532714065694; Fri, 27 Jul 2018 10:54:25 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:2646:0:0:0:0:0 with HTTP; Fri, 27 Jul 2018 10:54:05 -0700 (PDT) In-Reply-To: References: From: Seth Blank Date: Fri, 27 Jul 2018 10:54:05 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000006d9d4e0571fecdef" Archived-At: Subject: Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 17:54:30 -0000 --0000000000006d9d4e0571fecdef Content-Type: text/plain; charset="UTF-8" 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 remain confused. > I don't understand what you're exploring. The algorithm in https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-16#section-5.2 is clear and the separate paths you're describing don't factor it. On validation, you grab the highest instanced ARC set (step 1), and then start a process to set the chain validation status of the inbound ARC Chain. If the highest instanced ARC Set has cv=fail in it, you're done (step 2). No cryptographic checks have even been performed at this point, because in either scenario the chain is dead. If the AS validates and you have cv=fail, then the chain state is fail. If the AS does not validate, then the chain state is fail. Crypto isn't checked until step 3, and we never get there. If you're doing analysis and want to understand what caused the chain to fail, you're now outside of validation and outside of matters that affect interoperability. Or am I still misunderstanding what you're getting at? --0000000000006d9d4e0571fecdef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Jul 27, 2018 at 10:39 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:
But = (and I think this proves my point) I don't know if "cv=3Dfail"= ; refers to an invalid chain or a failed chain.=C2=A0 I have to run the ver= ification to figure that out.=C2=A0 But you're saying you just stop whe= n you see "cv=3Dfail".

I remain confused= .


On validation, you grab the highest instanced ARC set (ste= p 1), and then start a process to set the chain validation status of the in= bound ARC Chain.

If the highest instanced ARC Set = has cv=3Dfail in it, you're done (step 2). No cryptographic checks have= even been performed at this point, because in either scenario the chain is= dead. If the AS validates and you have cv=3Dfail, then the chain state is = fail. If the AS does not validate, then the chain state is fail.
=
Crypto isn't checked until step 3, and we never get ther= e. If you're doing analysis and want to understand what caused the chai= n to fail, you're now outside of validation and outside of matters that= affect interoperability.

Or am I still misunderst= anding what you're getting at?
--0000000000006d9d4e0571fecdef-- From nobody Fri Jul 27 11:15:55 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2934130EA2 for ; Fri, 27 Jul 2018 11:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=jtDo1T8i; dkim=pass (1536-bit key) header.d=taugh.com header.b=NC05GL+w Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtKSXhom4wVL for ; Fri, 27 Jul 2018 11:15:52 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDEE1130E64 for ; Fri, 27 Jul 2018 11:15:51 -0700 (PDT) Received: (qmail 45007 invoked from network); 27 Jul 2018 18:15:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=afcd.5b5b6153.k1807; bh=YclT+4KfcHvx+mUKUfgwJcyyYyXEw6xM1J8eNDFrpGw=; b=jtDo1T8imyTYq/lcI6TJBejFjivjJT/6C4GB3gx8yUSqsoltzH1BXQay535+bpPKa8wy2FGmuLSUXRSQvUJJdmCcHvQJrlyBVu0TSM8zKfqsI5Y2OKZAmLbS2ZKFRclaNo/g3kguBTkuPK4s4GMlotVm1ng7mIAbJwE81gyLzlDxOEJvrWLcWjgM0UjBu6AAkA3o7ugoX+zl2KuvQGKLy/p5kXRfRq378m2xHK+9quS/jm+Wq8snjI0oKoSXNOYR DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=afcd.5b5b6153.k1807; bh=YclT+4KfcHvx+mUKUfgwJcyyYyXEw6xM1J8eNDFrpGw=; b=NC05GL+w5VVKdhv+HdCduRZxCeIRDpAViwnOVe7gNsPlgZjc6ZjTuV6D4lbpFqit41qQR6SxT0Au0NsTA3R4JoLnPlOQ11GQNKXzvtCVB8B7mM5x2FJdROwq4twdbNSalMi/ZvZxQmZTZVcRrrn2Xl+G5Eie3X6q8ZYaKqZ3XmN0Ju1XFmkNMXWD7y2bcGzoxW57Ym/GQXeCKiqAMNuwP2iP+SIJvon4S5jGG6CeZBqPAiHJGU0rmoO1MxdQ++QS Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 27 Jul 2018 18:15:47 -0000 Date: 27 Jul 2018 14:15:47 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" Cc: "IETF DMARC WG" In-Reply-To: References: <20180727172458.DABC22002E2E0E@ary.qy> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] ARC-16 signature domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 18:15:54 -0000 > On Fri, Jul 27, 2018 at 10:24 AM, John Levine wrote: > >> The ARC draft clearly says that every ARC header can be signed by >> whatever domain you want. > Are you saying we should proscribe it, because its semantics are unclear? I'd say that all signatures in a seal SHOULD have the same domain, to make them easier to evaluate. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Fri Jul 27 11:24:01 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 797DB130E94 for ; Fri, 27 Jul 2018 11:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivcde83dOMn2 for ; Fri, 27 Jul 2018 11:23:57 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BADAE130E89 for ; Fri, 27 Jul 2018 11:23:57 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id 13-v6so10686477ois.1 for ; Fri, 27 Jul 2018 11:23:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=gUfaWes20ajKAuW3XlDlaXy4SMjvl2aNs9SPEs+G9W8=; b=M44s3AsgHC9vFXC0jb5Si+01cKssvM8vIFso02c95i+osUjmuVRNqpeg++5CS5xaO9 x9d1IGpAzASzRanIQAaWbGcKlO6qjxHTTynJ2J1O8pKD4PMpqMLRGBXmKJ1YYyNEalCt Wk6vJKxfSPPx2BE4jBPreEtjuYNH6Q18IQhGd5JOwsTOn6ficHioIMjPBZD1B8BTZ28H CNnhReTjJvRwEFGrX6Vsd66yXWJjGoaglBv4v+0gGPwdmJAw+Yc1YrMG+tGaYoU6Fu7V ZoRwdaGX8h1pdLJuyfMCv0RFQKeIKO7QfWjuqCR57MaTl5ezM/KrtLC789FSfmiAFsYp /gYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=gUfaWes20ajKAuW3XlDlaXy4SMjvl2aNs9SPEs+G9W8=; b=KFlNZdSRjH9k81S9cXyh0VF7i0B4COEkmprNgrxUoZS+vZZ1kIcXW4+YaTM+evurg6 ALcK1F3tJI11+QcNFDSa5Iwt4+TlQdtL9irfuJx86Vju9dl67xMc/jgGt3ZjEVJUxSuo n7AosRke/lMiOR1RFvTOxzn9SmtLox1q1s81Ig78Dk6niH0lY8V7Jk4jqt2IKLUa3yq/ pR9937EQBhEh3TzM0sqt8UKmRaXKUQh1z7tF683t5Pkaa7RQjqb2QZwoRllya07CLWpz sWh3H1SFNLFdVlk/e/JSH4eVe1AnSWA8ptXv7crMeGg9RhXYHyZvQu3Nii0/Mluf1InS wzfg== X-Gm-Message-State: AOUpUlGkhVztYtDDfgwKSX3M8jifJM5QomAvYNcChqBnISZtlPRn7Ej2 b7Lg1gN5fgHfTTDR7NeoAX3SB+XsD7O/NHg6/l+3Y6gZ X-Google-Smtp-Source: AAOMgpeFxzsCmPkXiCbf7NBpYhY6u0/6g8nOhYGOvePMwmuUV3J0PXb/SRO2drJ66eMmVmoEJeGTc0J9rmSYKvWwXEs= X-Received: by 2002:aca:bd8b:: with SMTP id n133-v6mr7841345oif.108.1532715836541; Fri, 27 Jul 2018 11:23:56 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:2646:0:0:0:0:0 with HTTP; Fri, 27 Jul 2018 11:23:36 -0700 (PDT) In-Reply-To: References: <20180727172458.DABC22002E2E0E@ary.qy> From: Seth Blank Date: Fri, 27 Jul 2018 11:23:36 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000faa4550571ff36be" Archived-At: Subject: Re: [dmarc-ietf] ARC-16 signature domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 18:24:00 -0000 --000000000000faa4550571ff36be Content-Type: text/plain; charset="UTF-8" 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 affect interoperability, b) it would be yet another requirement in an already complex standard, and c) there are reasons this flexibility could be valuable. --000000000000faa4550571ff36be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Jul 27, 2018 at 11:15 AM, John R Levine <johnl@taugh.com> wrote:
I'd say that all signatures in a seal SHOULD have the same domain, to m= ake them easier to evaluate.

So the Usa= ge Guide will (does?) say that. Earlier consensus was to keep that out of t= he normative document because a) it doesn't affect interoperability, b)= it would be yet another requirement in an already complex standard, and c)= there are reasons this flexibility could be valuable.


--000000000000faa4550571ff36be-- From nobody Fri Jul 27 14:25:36 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1EFC130E45 for ; Fri, 27 Jul 2018 14:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sh-1L4YHWznH for ; Fri, 27 Jul 2018 14:25:32 -0700 (PDT) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D25F12DD85 for ; Fri, 27 Jul 2018 14:25:32 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id b22-v6so4429169lfa.3 for ; Fri, 27 Jul 2018 14:25:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mRfECG7gwQWIjQcTKEFxu/hfQ2rpyuGOHYgcwn9DrqE=; b=BrHAHR0BM1Hm0p2MkmiDAJvG1z5UTKALQRlQDYHd6tyClq3na6648Zth1H/ggC8SO/ WnZ5dBPToJGYFqt5Dy8NX40LQBG8S383gffQR+3kpfBXhhvIhSW6naU4kcCC7XQPIgI5 lE7V/bwb/IsgFy4rdKoVf903DNfgwO/57GjnQQnrYTcCOQku6ZUtxSXU+FCxJ0RXw9IF SnetWrjx2u4J6ms/azKfxEoY3iBaftWe+cDDs+bXP7IJR6akix96C9Gqzxui0bb4GqL4 bUJuG3Gb6Mrmmr3+QGXZit3DYb3SG63wqxCDJPImjS/4f6+lIYyjfZryuiaWpQUzzIM0 kKAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mRfECG7gwQWIjQcTKEFxu/hfQ2rpyuGOHYgcwn9DrqE=; b=YCfrpJVXDR8fqZ4vJTg0Swc48ymSjdeO/gX+dIrJYX0Bi028hOm1MAhkT331aafbwW 4wQK5byQMbvueWtdmxEINaZP9BwJhEOKIzHOWLjYyrsQg/gYHOoTaOsQGC736XbWLDwq 0c1miFmzjlcY4X9404OlSRYcpBTckPYJHmJ+Im3UbDblZFoj2UkEw3SooBR3FH0sEU4P ua4vlcT4hN8EJDZS9lrCAitUdMXBZ0UJ9QUqM70Tv48P846Nkd/OpSqFBf4uUeXYD83m 7FblS0ZWTCzvJMbTUbn3W/6IufEm4TDoRfaU6VraTs9DW4h+aVKtgWdWDTaD8xkWzEOY GcIw== X-Gm-Message-State: AOUpUlH5V4jUK+95YjUbSvpH5w+UqUIvyReScxzWe4EeM2jYFWFkqe3q zdoLCoac55a6RtX2ho3hiUjCptD5wpz6/8D8lYakWQ== X-Google-Smtp-Source: AAOMgpf6O5UACQ8caQRHOA7Jf53VwFuGmzMsooZmUbrfQpVq6/UMm43R/BvCiIc5CwZ+vX+P7e+nFficmaoAlC4L3g0= X-Received: by 2002:a19:e1cc:: with SMTP id l73-v6mr5225904lfk.102.1532726730385; Fri, 27 Jul 2018 14:25:30 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:3a13:0:0:0:0:0 with HTTP; Fri, 27 Jul 2018 14:25:29 -0700 (PDT) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Fri, 27 Jul 2018 14:25:29 -0700 Message-ID: To: Seth Blank Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000004d6e76057201c009" Archived-At: Subject: Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 21:25:35 -0000 --0000000000004d6e76057201c009 Content-Type: text/plain; charset="UTF-8" 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 you're saying you just stop when you see "cv=fail". >> >> I remain confused.. >> > > I don't understand what you're exploring. The algorithm in > https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-16#section-5.2 > is clear and the separate paths you're describing don't factor it. > > On validation, you grab the highest instanced ARC set (step 1), and then > start a process to set the chain validation status of the inbound ARC Chain. > > If the highest instanced ARC Set has cv=fail in it, you're done (step 2). > No cryptographic checks have even been performed at this point, because in > either scenario the chain is dead. If the AS validates and you have > cv=fail, then the chain state is fail. If the AS does not validate, then > the chain state is fail. > > Crypto isn't checked until step 3, and we never get there. If you're doing > analysis and want to understand what caused the chain to fail, you're now > outside of validation and outside of matters that affect interoperability. > And therefore, if I'm a sealer and I've decided I'm going to mark the chain failed, why wouldn't I just do "cv=fail" with a bogus or empty signature? The verifier isn't going to use whatever signature I've put there anyway; as you point out, the verifier sees "cv=fail" and stops. And if that's all correct, then I don't understand why we're talking about what exactly you seal if you're the one attaching "cv=fail", because it's moot. -MSK --0000000000004d6e76057201c009 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jul 27, 2018 at 10:54 AM, Seth Blank <seth@sethb= lank.com> wrote:
On Fri, Jul 27, 20= 18 at 10:39 AM, Murray S. Kucherawy <superuser@gmail.com> = wrote:
But (and I think this proves my point) I don't know if "cv= =3Dfail" refers to an invalid chain or a failed chain.=C2=A0 I have to= run the verification to figure that out.=C2=A0 But you're saying you j= ust stop when you see "cv=3Dfail".

I remain confused..

I don't understand what you're exploring. The algorithm in=C2=A0= https://tools.ietf.org/html/draft-ietf-dma= rc-arc-protocol-16#section-5.2 is clear and the separate paths you= 're describing don't factor it.

On validation, you grab the highes= t instanced ARC set (step 1), and then start a process to set the chain val= idation status of the inbound ARC Chain.

If the hi= ghest instanced ARC Set has cv=3Dfail in it, you're done (step 2). No c= ryptographic checks have even been performed at this point, because in eith= er scenario the chain is dead. If the AS validates and you have cv=3Dfail, = then the chain state is fail. If the AS does not validate, then the chain s= tate is fail.

Crypto isn't checked until step = 3, and we never get there. If you're doing analysis and want to underst= and what caused the chain to fail, you're now outside of validation and= outside of matters that affect interoperability.

And therefore, if I'm a sealer and I= 've decided I'm going to mark the chain failed, why wouldn't I = just do "cv=3Dfail" with a bogus or empty signature?=C2=A0 The ve= rifier isn't going to use whatever signature I've put there anyway;= as you point out, the verifier sees "cv=3Dfail" and stops.
And if that's all correct, then I don't understand why= we're talking about what exactly you seal if you're the one attach= ing "cv=3Dfail", because it's moot.

<= div>-MSK
--0000000000004d6e76057201c009-- From nobody Fri Jul 27 14:40:28 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D641130E52 for ; Fri, 27 Jul 2018 14:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=xOeDP8NH; dkim=pass (1536-bit key) header.d=taugh.com header.b=d0nfbNwR Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FN7cZAkG2F0G for ; Fri, 27 Jul 2018 14:40:24 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5D1E130E3F for ; Fri, 27 Jul 2018 14:40:23 -0700 (PDT) Received: (qmail 29544 invoked from network); 27 Jul 2018 21:40:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=7366.5b5b9146.k1807; bh=Wrd/fNOGruWsrHr+jOeNHsArMK8tnVr13SoXU041cDg=; b=xOeDP8NHmNhWasU4ZhybU+8qU1lPVW65ePvlEwRilmBky7FYzEqh55Qu3Rw9MWU5P6hcknm0j6Is3c5U93ZtYyXRd+iLG2qw6QNjZIc7PkhvVqJ3tdt0R5J/wSRmjtZIe+12p4ceoWXMg94ajuaCXJEDRO4MmW+8rofO/LQg20A5y7dOe9HwiiSVdaxE7uUOVngMmLFcpkGKW/qnUGKxqdv19T5Da28wyAUBpn8ymOEePxk5A81S7AwKHzoep0su DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=7366.5b5b9146.k1807; bh=Wrd/fNOGruWsrHr+jOeNHsArMK8tnVr13SoXU041cDg=; b=d0nfbNwRB34rgYzQOu390Jycy6D8waxk1WZEbic3gLEYKWrR87oyjZGXjV1YUZsjF7JIAjMk4NC5vF7/NV2ux6wxMXNqy9qvkF/KQvkooMhVVDuWUwicJxHBVcqB+5eYhnmTIAXYtXBKQYV/ehw1Hp1IQmq4085hebxYVgyoAdjmqZRuHnVTMJV0WZuQQlBjh8k4ZwnqAcLlvMsAclvIm7mMb/KeJp+by3F3jTdp7gfoQvyL+/44NtCho2i30M+D Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 27 Jul 2018 21:40:22 -0000 Received: by ary.qy (Postfix, from userid 501) id 767092002E465B; Fri, 27 Jul 2018 17:40:22 -0400 (EDT) Date: 27 Jul 2018 17:40:22 -0400 Message-Id: <20180727214022.767092002E465B@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: seth@sethblank.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] ARC-16 signature domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 21:40:26 -0000 In article you write: >-=-=-=-=-=- > >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 affect >interoperability, b) it would be yet another requirement in an already >complex standard, and c) there are reasons this flexibility could be >valuable. OK, that makes sense. It is an experiment, after all. R's, John From nobody Fri Jul 27 14:41:30 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44462130E52 for ; Fri, 27 Jul 2018 14:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=u3vSIeiq; dkim=pass (1536-bit key) header.d=taugh.com header.b=p/6GqtGB Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUE7J_rzyySZ for ; Fri, 27 Jul 2018 14:41:25 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F285130E3F for ; Fri, 27 Jul 2018 14:41:25 -0700 (PDT) Received: (qmail 29825 invoked from network); 27 Jul 2018 21:41:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=747f.5b5b9184.k1807; bh=gPUKttpOLfz20x7VOV+vG01tGxBEE1z/uS7XtPfb8qs=; b=u3vSIeiqLDEePdOwGJ6f6Yn2hXfkVPcC1KRk57WS54v8IgEEYgOI7rHi4XTYD2Gv1p0l22ploRp1E2EAdSMN1RKVfx/D9dDEsfio8AuwYb9c0VK5Kj5hTinIXakIJ/yeDZaj8oMF6cvrh4aBARGXwZcbmAwUBYe0pKgI89Eeo+JvxdC2GUOgXTopu7SSETd2x3gUmrziMatkNkCempBG8BhTADHT+edtrrxvbjc06AmVOysnN3bPmTNWb6RzWMJo DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=747f.5b5b9184.k1807; bh=gPUKttpOLfz20x7VOV+vG01tGxBEE1z/uS7XtPfb8qs=; b=p/6GqtGBmYlqMdV6OvNNbc2yteoxBz3E6l2o4CTqnP+3QMigRqm41zPGjHCSqShPmZAt+qsY0d0Whv+dNTfDZEvBCx2U0+xppErqvagBSO0oa5grpi8QITgmsd6eTX4vbJtRL9usxEuYJXYHqMqiYx6rHOmlnkkZemLEXi9uTzw4kMGhfYJIug66eRgfYenKe4Chk15JwU+Nupv5GhVYIhX51JzamMmjlWm3KfePl7JYZcnZQqBcEREkiu/rlomw Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 27 Jul 2018 21:41:24 -0000 Received: by ary.qy (Postfix, from userid 501) id 2CB782002E4689; Fri, 27 Jul 2018 17:41:23 -0400 (EDT) Date: 27 Jul 2018 17:41:23 -0400 Message-Id: <20180727214124.2CB782002E4689@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: seth@sethblank.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] WGLC ARC-16 section 5.2.2 should be stricken X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 21:41:28 -0000 In article you write: >-=-=-=-=-=- > >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 could put simple text around if an error code is appropriate or not, and >if so if a new one is needed. Just add the error code. It's really not a big deal. R's, John From nobody Fri Jul 27 19:39:17 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE974130E32 for ; Fri, 27 Jul 2018 19:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=Ow7dOIah; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ilGCrRUc Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdF9YoB9SC6f for ; Fri, 27 Jul 2018 19:39:13 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC48D12F1A5 for ; Fri, 27 Jul 2018 19:39:13 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id E5BA071D for ; Fri, 27 Jul 2018 22:39:12 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Fri, 27 Jul 2018 22:39:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=mV/1NV5EIRLceyUUc RfDGIr0xK7PHbsgsLPntTiuuu0=; b=Ow7dOIahqsyBkdXTQ58uDhPmixk5Dc651 6R48+dx6PPpD0baSV99fpisKE4ziFlAAuK7Pk/omPskhfXB9dszcy9v5Mdpmhlqw +oRHnSs6AxT4kGXx/hJg6Kxcn8WmCvCJQXRN+HMxswKk0oDHblplkgUgWGj5iwgI LTF/8ps4Z921GIWCi16sTY/ZpAAAXdP/PuRV/XEX+QA/gjb/zMBvP5zMTyaRQ0Xi 4L5JYM/CiJ13l0TgCZZsQtxDdfVLmBtRgdaXPkpSa85xVf0I1aAp4NnnDlTyyBtN 2XPnuvDhLzjVJDkvhfFN1Lxjg/UfFc4pxcJFdVTywcUohhV3z7LzA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=mV/1NV 5EIRLceyUUcRfDGIr0xK7PHbsgsLPntTiuuu0=; b=ilGCrRUcxCPz9feg7qR88h RnjOJGK5YGkH30uQkctTtVzkwPAbZMWlARRmv+Xe0knwCTwruWjIPIyIegf/C+Hi 8vnyjdGPi/1vm8zaFRzJCcaxetfDrU9b+MZoetxWfVFhLsGY3/sLQgen5jhHxLXR zNPLQKSsN5uwJQZdcDLy4JuLcGJTbD2DNbKaqK3l/lvK9SQDc9Qx23vULnoCUaz6 +5nSExnY6iic9e7ZQWSfhl94WUnyRceppQsreWrf36/5bSb4tdwDcr81Xw7XbNHJ dEVCdCwGsfu7bE3qOlGZlQbnXflJ8bi0fs61bFEk1Frmc3Raj1qvSMryJFCLmx9A == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 024B8621CB; Fri, 27 Jul 2018 22:39:11 -0400 (EDT) Message-Id: <1532745551.208119.1455489824.75DFC005@webmail.messagingengine.com> From: Bron Gondwana To: dmarc@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15327455512081192" X-Mailer: MessagingEngine.com Webmail Interface - ajax-0843ff3e In-Reply-To: References: Date: Sat, 28 Jul 2018 12:39:11 +1000 Archived-At: Subject: Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2018 02:39:16 -0000 This is a multi-part message in MIME format. --_----------=_15327455512081192 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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:>>=20 >>> The verification algorithm is straightforward. If you receive a >>> chain that ends with cv=3Dfail stop your evaluation, you=E2=80=99re don= e. >>> There=E2=80=99s no separate validation path here.>>=20 >>=20 >> Then why bother signing anything when you affix "cv=3Dfail"? >=20 > Because adding your ARC Seal over the chain guarantees that the > receiver has a complete list of everyone who modified the message up > until the failure. No, this is wrong. I have detailed why this is wrong many times. A single cv=3Dfail means that there's no proof that the entire previous chain isn't just a valid set of ARC headers picked up from somewhere else with the serial numbers filed off and the entire message replaced with something else. 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 Authentication-Results, any earlier ARC and DKIM headers have no provable causal relationship with the rest of the message you received. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_15327455512081192 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
On Sat, Jul 28, 2018, at 03:29, Set= h Blank wrote:
On Fri, Jul 27, 2018 at 10:21 AM= , Murray S. Kucherawy <superuser@gmail.com> wrote:
On Fri, Jul 27, 2018 = at 8:35 AM, Seth Blank <seth@sethblank.com> wrote:
=
The verification algorithm is straightforward. If you receive a cha= in that ends with cv=3Dfail stop your evaluation, you=E2=80=99re done. Ther= e=E2=80=99s no separate validation path here.


Then why bother signing anything when you affix "cv=3Dfail"?

Because adding your ARC Seal over the chain guarantees that the receiv= er has a complete list of everyone who modified the message up until the fa= ilure.

No, this is wrong.  I have detailed = why this is wrong many times.  A single cv=3Dfail means that there's n= o proof that the entire previous chain isn't just a valid set of ARC header= s picked up from somewhere else with the serial numbers filed off and the e= ntire message replaced with something else.

The only thing your ARC Seal will validat= e is your own ARC-Authentication-Results header - which isn't nothing (it c= ould contain the IP address that you received this message from) - but if S= PF / DKIM and ARC are all fails in your Authentication-Results, any earlier= ARC and DKIM headers have no provable causal relationship with the rest of= the message you received.

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_15327455512081192-- From nobody Sat Jul 28 18:12:50 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8FF1131185 for ; Sat, 28 Jul 2018 18:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEtoBm6Dyh2J for ; Sat, 28 Jul 2018 18:12:45 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8F60130EA7 for ; Sat, 28 Jul 2018 18:12:44 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id k12-v6so15453136oiw.8 for ; Sat, 28 Jul 2018 18:12:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=032SZd9s02ZQCUQf8tx8FABAsSIRv9YP0nKh9DIwGUE=; b=xBN3zsOiiaOsHXFmdMSDiABgpaQQ1PhcwHWc7ntqOy3wrEgjAqQA50P8BnyP3a2Ams uNzCxphTXjBdwbt4gW4rpq1nXDG8P2hBr/XA1p8ejmCoUzXDGsyk22GiLxy8fF+MPFMa U+9IK8n1atioTYMYLtyarB2173R5Ow33ZU30PaXcKMHhJOlH0frbUNrhodrQukjVeyPx Gn42ZVPESQhDkZM4JXhNAZsyzNoykG/QjWcg8hyyThk63ifKHsgkXh/bxlEPD16uHxBt w3TXATGiHRXz+7sF+g5rCSve3mkKbDYbcUZHIFBqsMVX8H6l71vEP0FEaZ5VRbXYbavl nXNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=032SZd9s02ZQCUQf8tx8FABAsSIRv9YP0nKh9DIwGUE=; b=PeEZNN2xLb5ilFMSoatExNmOGhoO1OhzzbQGsinHLuu13XEVycAAUim9S835iB8CtJ R1AscLYSiPiSr40gHo39tcNluAb4afK5bz8ujV51cMAr9NjQMvBWTWK4u0eF/cCklsRn 4lCI/rYBDBSKJKLBZt+Zc4OsKoHZSakLH5je7fHmQ6Ea7Mbn6yTl6LTc5ciodavRtiUY qNi4QtmG9Rfuk1h7URejoZjo6IjyMV08g4RBwZmiqLa/AxN6fSJrqPzC2XGq7YIq6ZcF qV8IUW3VfaFFWg/vRbsK0hGbZj1PF1y/IF+eVd3RfLUYluw+KnNINak0CrvC0jitheQD elxQ== X-Gm-Message-State: AOUpUlGGeMZIKsmrGLY7n72sM08TRpuA//SGR/vIQllE9lLEZTLGk1tk +2uhfuaGn+a+MkFptqfQDsAlrI0CTQMx5qsV7JsuDN5TXfM= X-Google-Smtp-Source: AAOMgpeUfEVBvbkl3r0+JTBs5424274q4tCEBUj+TGWGKJ3vb7EzDJA47vT9QU7Uja68tyRlzVb+z2Ud2tGUDZ+mmCI= X-Received: by 2002:aca:cf0e:: with SMTP id f14-v6mr13343266oig.356.1532826763683; Sat, 28 Jul 2018 18:12:43 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:2646:0:0:0:0:0 with HTTP; Sat, 28 Jul 2018 18:12:23 -0700 (PDT) In-Reply-To: <1532745551.208119.1455489824.75DFC005@webmail.messagingengine.com> References: <1532745551.208119.1455489824.75DFC005@webmail.messagingengine.com> From: Seth Blank Date: Sat, 28 Jul 2018 18:12:23 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000c080610572190a6a" Archived-At: Subject: Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2018 01:12:48 -0000 --000000000000c080610572190a6a Content-Type: text/plain; charset="UTF-8" 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 Authentication-Results, any earlier ARC and DKIM > headers have no provable causal relationship with the rest of the message > you received. > A structurally valid ARC Chain (all ARC Sets have one each of the ARC header fields, the ARC Sets instance numbers are 1..N inclusive, and each AS covers all ARC Set header fields on the message 1..its own instance number) where all AS's validate says a very specific thing about that ARC Chain: that no one has modified *THE ARC HEADER FIELDS* that are part of the Chain. This also means that from the first ARC Set at i=1 through the last passing ARC Set, you have a guaranteed list of all domains who have modified the message (yes, some may have Sealed without modifying) and the corresponding ARC-Authentication-Results each saw, which you know have not been modified by someone other than the ADMD which added them. This does not stop someone from taking an intact and passing ARC Chain and adding their own garbage on top. Fundamentally, this is how mail work; mail is spooled and replayed all the time by design. This is an issue with DKIM, and covered in 6376 sections 5.4.1 and 8.6. Since ARC inherits heavily from DKIM, it also inherits these specific replay issues. It was determined that fixing the replay issue was out of scope, except for providing guidance on how to contain impact. Sections 9.4 and 9.5 talk directly to these issues: https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-16#section-9.4 https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-16#section-9.5 Frankly, your concern speaks directly to the issue I raised initially. If cv=fail only signs itself, then there is absolutely no way to localize the issue and determine which Sealer decided to run amok with the Chain. If you see a cv=fail, you have to throw out all the data. At least when Sealing cv=fail, if you Seal greedily, there is in intact chain of Seals which can be used to make important determinations as to the veracity of the header field data and may be able to use that to determine where things may have fallen apart or been replayed. --000000000000c080610572190a6a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Jul 27, 2018 at 7:39 PM, Bron Gondwana <brong@fastmailteam.com> 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 receive= d this message from) - but if SPF / DKIM and ARC are all fails in your Auth= entication-Results, any earlier ARC and DKIM headers have no provable causa= l relationship with the rest of the message you received.
<= /div>


This also means that from the first ARC Set at i=3D1 throu= gh the last passing ARC Set, you have a guaranteed list of all domains who = have modified the message (yes, some may have Sealed without modifying) and= the corresponding ARC-Authentication-Results each saw, which you know have= not been modified by someone other than the ADMD which added them.

This does not= stop someone from taking an intact and passing ARC Chain and adding their = own garbage on top. Fundamentally, this is how mail work; mail is spooled a= nd replayed all the time by design. This is an issue with DKIM, and covered= in 6376 sections 5.4.1 and 8.6. Since ARC inherits heavily from DKIM, it a= lso inherits these specific replay issues. It was determined that fixing th= e replay issue was out of scope, except for providing guidance on how to co= ntain impact. Sections 9.4 and 9.5 talk directly to these issues:

https= ://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-16#section-9.4
=

https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-16#section-9= .5

Frankly, your concern speaks directly to the issue I raised initially.= If cv=3Dfail only signs itself, then there is absolutely no way to localiz= e the issue and determine which Sealer decided to run amok with the Chain. = If you see a cv=3Dfail, you have to throw out all the data. At least when S= ealing cv=3Dfail, if you Seal greedily, there is in intact chain of Seals w= hich can be used to make important determinations as to the veracity of the= header field data and may be able to use that to determine where things ma= y have fallen apart or been replayed.

<= /div>
--000000000000c080610572190a6a-- From nobody Sun Jul 29 11:24:07 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13EDF130ECC for ; Sun, 29 Jul 2018 11:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiVlmmqs62MH for ; Sun, 29 Jul 2018 11:24:02 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C868130DD5 for ; Sun, 29 Jul 2018 11:24:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=gamma; t=1532888639; bh=7QOV9BTHDoN5LkWE4B1ivCgMduuBx60tqMTSWDKeZgY=; l=5699; h=References:From:To:Date:In-Reply-To; b=BXylW22st/Fp0HkSzY+AhWaRfTR8httyuxLkeT8E4qwxglzGYGqvzYi9YKz0lmr8m Xto3ocR2j7dqdVTEApSLQ3oUBsU9yQfF+OEhssQeiN/QjS1BljBETqhOKwRSVtTS49 nlLoypQxsPsXO4kOhVk9j/YWC1Vj0R6ff2Uy21C7jbtq7ogLPDfIo8Fc0ay8D Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Sun, 29 Jul 2018 20:23:59 +0200 id 00000000005DC02A.000000005B5E063F.00007D3F References: From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 To: dmarc@ietf.org, "Murray S. Kucherawy" Message-ID: Date: Sun, 29 Jul 2018 20:23:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] WGLC on draft-ietf-dmarc-rfc7601bis-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2018 18:24:05 -0000 On Sun 15/Jul/2018 20:04:51 +0200 Barry Leiba wrote: > So begins Working Group Last Call (WGLC) on draft-ietf-dmarc-rfc7601bis-02. > > Please review the latest version: > https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/ > .... and send comments to the DMARC working group mailing list by 3 August. *Registries definitions* Did the WG decide whether this document is going to update or obsolete rfc7601? IIRC, the catch was that obsoleting would require registries [re]definition lest leaving pointers to obsolete defining documents. Hm... perhaps it's fine for a deprecated definition to point to an obsolete document... I'm not good at that, I'm asking. Anyway, I'd opt for obsoleting rfc7601 and copying in registry definitions as needed. The result is cleaner that way. In addition, much of the text (including the abstract) would need to be reworded if the doc /updates/ rfc7601. *Domain based* An introductory paragraph sounds outworn, since rfc7281 is not domain-based: This specification is not intended to be restricted to domain-based authentication schemes, but the existing schemes in that family have proven to be a good starting point for implementations. *EAI addresses* +1 for adding "or email addresses" in Section 1.5.2, Internationalized Email, after the words "allow UTF-8 in most places that free-form text ". *Section 1.2. "Trust Boundary"* That section ends with two questionable statements about A-R fields found in an attachment: The details reported by this field cannot be trusted in that case. Thus, this field found within one of those media types is typically ignored. How about generic spam complaints and ARF reports of various kinds? Of course, trust in the report originator may vary, but I wouldn't say the field is typically ignored. *This proposal* The term appears three times (sections 1.5.3. "Security", 7.11. "Reverse Mapping", and Appendix A. "Legacy MUAs"). Won't the approved RFC be promoted to "Internet Standard"? In that case, I'd s/proposal/standard/. *Section 1.6. "Trust Environment"* The first paragraph deserves a reference to Section 5 "Removing Existing Header Fields". *authres-payload* This rule is new. Yet, the corresponding syntax doesn't seem to be changed; it seems to be just a readability improvement. Is that obvious? If not, I'd mention this change/non-change as a first entry in Appendix D, to reassure parsers implementers. Or am I misreading the ABNF? *special-smtp-verb* This rule is redundant and, if we're after readability, can be striked. In fact, both terms it produces fall under the "Keyword" rule. In addition, IANA reports smtp.rcptto as defined by rfc7293, so it can be omitted here. *Keyword enumeration* The note says: "Keyword" is defined in Section 4.1.2 of [SMTP]. When used in "result" above, it is further constrained by the necessity of being enumerated in Section 2.7. I'd replace it with: "Keyword" is defined in Section 4.1.2 of [SMTP]. It is further constrained by the necessity of being registered in the relevant IANA Registry. See Section 6. Simpler and direct, no? *prospec omission* OLD: The "propspec" may be omitted if, for example, the method was unable to extract any properties to do its evaluation yet has a result to report. NEW: The "propspec" may be omitted if the method was unable to extract or unwilling to disclose any properties involved in its evaluation, yet has a result to report. *policy* This ptype can now evolve from catchall to meaningful indicator: OLD: A "ptype" value of "policy" indicates a policy decision about the message not specific to a property of the message that could be extracted. See Section 2.4 for details. NEW: A "ptype" value of "policy" indicates a policy decision about the method. Its presence in a "resinfo" indicates that the algorithmic result of the method might have been overridden because of an internal criterion. Both "property" and "pvalue" concur at hinting what the internal criterion was. See Section 2.4 for details. The above interpretation is based on the example in Section 2.4, The "policy" ptype, which reads: ... dkim=fail policy.dkim-rules=unsigned-subject ... Now I'm not going to question whether policy ptypes should be registered, always or sometimes, but since DKIM is quite liberal about what fields should be signed, ptype/property pairs such as policy.dkim-signed and policy.dkim-unsigned having a pvalue constrained to a (registered) header field name could be more actionable than the above example. It could be changed like so: ... dkim=policy policy.dkim-unsigned=subject ... A consumer of DMARC forensic reports containing such field could extract the field names and sum up how many receivers need which fields to be signed, for postmasters to possibly amend their DKIM configurations. Changing the result to "policy" matches Section 2.7.1. "DKIM and DomainKeys" which sets "policy" as a possible result. To say "dkim=fail" can be easier if the desired effect is to steer a downstream filter. However, the latter is a hack which I wouldn't encourage. Adding an augmenting example might also be useful: ... dkim=pass header.i=@ncas.us-cert.example policy.trust=yes ... (In this case, the result is not overridden.) Both examples are about DKIM. Then, perhaps, the DMARC-styled example in Section 2.7.1 ("For example, an ADMD policy [...] unacceptable even if they verify") can be striked. *Section 2.7. "Defined Methods and Result Values"* s/New methods/Methods/ Best Ale -- From nobody Sun Jul 29 15:59:57 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33522130DFF for ; Sun, 29 Jul 2018 15:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=YQw2sSUm; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=rNyaloze Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFM84aOBLSU2 for ; Sun, 29 Jul 2018 15:59:51 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BCEB130DD8 for ; Sun, 29 Jul 2018 15:59:51 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id AA9F321ADF for ; Sun, 29 Jul 2018 18:59:50 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Sun, 29 Jul 2018 18:59:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=75x98N1pGylhZyYu4 F/FsvU9QBk99rnM8AOJoefkjxM=; b=YQw2sSUmb30QamDZRXMXM9VNx7BM1OuBp Vt0P1R0XdwCyPcylhVJZXvjoHJxCzCOaYFjTopRzKERXq6gL+CKbML/eM37hIjcc KoOKlhmsfMsTWt0QLyfDQYRhQ76xGGlLK9EwoxDV6o+b5u905jfuwMTiYH/BFDns 74FPD6tarU8duYYYWBJxUIH7ma2dmiDHtu+/gsWWq/YVQui1jtUYc9PmWTyLFjrl GGQqFL+TgRmXyD3h4yRPfP+ZHYPNB7SqKfeo+viiGF+nCIvsd/KQVX4HkNWKaNx3 XyXutvfxieRDReFy8Onfrn2+/uPiDcC1HK/2RUxRCXmsMsJuc3x1A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=75x98N 1pGylhZyYu4F/FsvU9QBk99rnM8AOJoefkjxM=; b=rNyaloze+cWjy3Cez+6UTu hwvGNyMduyBbERfzBP/Tt84Q4g9RSe2jFxAchm4dMAbkKETppwHdFqhRXErhbX4o /VwcKKQaa1RBVV76aVeGt0rhGwh6CmqKlqpxhZ8Hlva8SiuRrKqJofDZz1dcZJyR gvzBLFQU8yYCGgWJ55t8Yu5mKgXHmyZN4GXdUH4yim37Dn64xEdBMoD9e0ua8faq deLvje5K+PyISoMVIoKji/KMhYnMz1kSUbwmWfcM4x1dLYingyyn7WFodQeriRNB T+gx4SSW8DwwDjWQJP0AxKuMyofjuqo4uSwHV9jXnvwrOfsX5k29bPRygKIq+JdQ == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id DF37CBA4CF; Sun, 29 Jul 2018 18:59:49 -0400 (EDT) Message-Id: <1532905189.2879805.1456751232.5F2CDCE4@webmail.messagingengine.com> From: Bron Gondwana To: dmarc@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153290518928798050" X-Mailer: MessagingEngine.com Webmail Interface - ajax-0843ff3e Date: Mon, 30 Jul 2018 08:59:49 +1000 In-Reply-To: References: <1532745551.208119.1455489824.75DFC005@webmail.messagingengine.com> Archived-At: Subject: Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2018 22:59:55 -0000 This is a multi-part message in MIME format. --_----------=_153290518928798050 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" 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 message from) - but if SPF / DKIM and ARC are >> all fails in your Authentication-Results, any earlier ARC and DKIM >> headers have no provable causal relationship with the rest of the >> message you received.>> > > A structurally valid ARC Chain (all ARC Sets have one each of the ARC > header fields, the ARC Sets instance numbers are 1..N inclusive, and > each AS covers all ARC Set header fields on the message 1..its own > instance number) where all AS's validate says a very specific thing > about that ARC Chain: that no one has modified *THE ARC HEADER FIELDS* > that are part of the Chain.> > This also means that from the first ARC Set at i=1 through the last > passing ARC Set, you have a guaranteed list of all domains who have > modified the message (yes, some may have Sealed without modifying) > and the corresponding ARC-Authentication-Results each saw, which you > know have not been modified by someone other than the ADMD which > added them. Modified "a message", sure. You have proof that a message followed that path > This does not stop someone from taking an intact and passing ARC Chain > and adding their own garbage on top. Fundamentally, this is how mail > work; mail is spooled and replayed all the time by design. This is an > issue with DKIM, and covered in 6376 sections 5.4.1 and 8.6. Since ARC > inherits heavily from DKIM, it also inherits these specific replay > issues. It was determined that fixing the replay issue was out of > scope, except for providing guidance on how to contain impact. > Sections 9.4 and 9.5 talk directly to these issues:> > https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-16#section-9.4> > https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-16#section-9..5[1]> > Frankly, your concern speaks directly to the issue I raised initially. > If cv=fail only signs itself, then there is absolutely no way to > localize the issue and determine which Sealer decided to run amok with > the Chain. If you see a cv=fail, you have to throw out all the data. > At least when Sealing cv=fail, if you Seal greedily, there is in > intact chain of Seals which can be used to make important > determinations as to the veracity of the header field data and may be > able to use that to determine where things may have fallen apart or > been replayed. 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" analogy, if you have a bag of evidence and it's been unsupervised in the hands of an unknown party, the contents have no evidentiary value any more. There's two types of fail - fail on AMS, which could just be a modification by somebody, and a fail on an AS, which means there's definitely either buggy software or somebody screwing with the chain. But even a single AMS fail means that an unknown intermediary could have changed every single header that's covered by the AMS. There's no way to know what they changed. Ditto the body. It could be a totally different message and there's no way to know because the chain of evidence is broken. So again - all that you can know when you see a broken AMS is that somebody got their hands on a message which had followed the existing chain. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com Links: 1. https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-16#section-9.5 --_----------=_153290518928798050 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Sun, Jul 29, 2018, at 11:12, Seth Blank wrote:
On Fri, Jul 27, 2018 at 7:39 PM, Bron Gondwana <brong@fastmailteam.com> 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 Authentication-Results, any earlier ARC and DKIM headers have no provable causal relationship with the rest of the message you received.


A structurally valid ARC Chain (all ARC Sets have one each of the ARC header fields, the ARC Sets instance numbers are 1..N inclusive, and each AS covers all ARC Set header fields on the message 1..its own instance number) where all AS's validate says a very specific thing about that ARC Chain: that no one has modified *THE ARC HEADER FIELDS* that are part of the Chain.

This also means that from the first ARC Set at i=1 through the last passing ARC Set, you have a guaranteed list of all domains who have modified the message (yes, some may have Sealed without modifying) and the corresponding ARC-Authentication-Results each saw, which you know have not been modified by someone other than the ADMD which added them.

Modified "a message", sure.  You have proof that a message followed that path

This does not stop someone from taking an intact and passing ARC Chain and adding their own garbage on top. Fundamentally, this is how mail work; mail is spooled and replayed all the time by design. This is an issue with DKIM, and covered in 6376 sections 5.4.1 and 8.6. Since ARC inherits heavily from DKIM, it also inherits these specific replay issues. It was determined that fixing the replay issue was out of scope, except for providing guidance on how to contain impact. Sections 9.4 and 9.5 talk directly to these issues:



Frankly, your concern speaks directly to the issue I raised initially. If cv=fail only signs itself, then there is absolutely no way to localize the issue and determine which Sealer decided to run amok with the Chain. If you see a cv=fail, you have to throw out all the data. At least when Sealing cv=fail, if you Seal greedily, there is in intact chain of Seals which can be used to make important determinations as to the veracity of the header field data and may be able to use that to determine where things may have fallen apart or been replayed.

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" analogy, if you have a bag of evidence and it's been unsupervised in the hands of an unknown party, the contents have no evidentiary value any more.

There's two types of fail - fail on AMS, which could just be a modification by somebody, and a fail on an AS, which means there's definitely either buggy software or somebody screwing with the chain.

But even a single AMS fail means that an unknown intermediary could have changed every single header that's covered by the AMS.  There's no way to know what they changed.  Ditto the body.  It could be a totally different message and there's no way to know because the chain of evidence is broken.

So again - all that you can know when you see a broken AMS is that somebody got their hands on a message which had followed the existing chain.

Bron.



--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_153290518928798050-- From nobody Sun Jul 29 16:49:38 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35698130DEA for ; Sun, 29 Jul 2018 16:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=wSWyO3BB; dkim=pass (2048-bit key) header.d=kitterman.com header.b=DufGqqCg Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZf_T2DOjsZQ for ; Sun, 29 Jul 2018 16:49:34 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CD38130DCD for ; Sun, 29 Jul 2018 16:49:34 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1532908171; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=Pw2M9JDBXbzPUPyCJcVIE9MaTL+KgkQKW+nQj7RPAMU=; b=wSWyO3BBNDcA1np4PPK+8QI52/VkfDiAWRDFyPAf7jfnHm+/tVr/8UmH kH8L++eFLX9prHV0CMhaSbQjAcqlDQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1532908171; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=Pw2M9JDBXbzPUPyCJcVIE9MaTL+KgkQKW+nQj7RPAMU=; b=DufGqqCg80G4RlXpQeJg9so/L19Olz4c8AyfbldQGTR+HuqAP77LAIZM Nmm+J939qUIQNdM3V7fXMmf65adMRTzjAYQTtYZ7y995aJ5/0aERfMXTH7 gDb4uIwbm3Cll1/jPBooPs7QHkhp3rPV67/2Wye+qObbqI+8jgfJ6TZd6s DoPRkcm/aq7pAWUZ6El25m+Zx4hW0FS+l0qSADkgf60a1IczQoxM8yYhuN bZTGgnJr+Kw1q6Pg7i4qtslApnaBkSIMNND+0aDtdHKv2sKpR6rTqlx+vu X/t1noqatUDp+8w/SrshEfDkETuyLpeIbbSCO6WuS6sQkTdC1kkaeQ== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 4DA6CC4007A for ; Sun, 29 Jul 2018 18:49:31 -0500 (CDT) From: Scott Kitterman To: dmarc@ietf.org Date: Sun, 29 Jul 2018 19:49:30 -0400 Message-ID: <4878884.yiV4iTtLKX@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-147-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] WGLC on draft-ietf-dmarc-rfc7601bis-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2018 23:49:36 -0000 On Tuesday, July 17, 2018 11:18:00 AM John R Levine wrote: > >> https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-rfc7601bis-02&url1=rf > >> c7601>> > >> 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. As an implementer (who's tried really hard to avoid spending cycles on EAI - sorry), does this translate into "be prepared for UTF-8 in any A-R element that may contain an email address or a domain"? Scott K From nobody Sun Jul 29 17:14:02 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A964B12E039 for ; Sun, 29 Jul 2018 17:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=f6pxnnqm; dkim=pass (1536-bit key) header.d=taugh.com header.b=f4GJU8ku Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mj43EJxTuzwa for ; Sun, 29 Jul 2018 17:13:58 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51C6D12DD85 for ; Sun, 29 Jul 2018 17:13:58 -0700 (PDT) Received: (qmail 11668 invoked from network); 30 Jul 2018 00:13:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=2d91.5b5e5845.k1807; bh=xEzpP15QslrRdJo6XanBjRFS8OI1ao33LPqUhPnzbyI=; b=f6pxnnqmSVl2qTSrGzMkHDPYYv15jDSXAhnb9Zi/PoTIV5gQnJY8ibPpcx0Wn0eOop/FJbrA6w8zDpe6EhJzzaFHNjm1Z71Gc2rql8vL/fZK97GB51DpjOiwOi9vsbKSqVDiCaL+QY2sJo66AhmxPQgLO/1ikEc/lslz3SaN0ENa9Q2jhKx9sERxhytfr8DNd0hI0pRMqOzZf3rX10CRN00Hnz0P1NhZtxrqb3jiFjTdjz2mNO5pTHAiK0Gz6i0L DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=2d91.5b5e5845.k1807; bh=xEzpP15QslrRdJo6XanBjRFS8OI1ao33LPqUhPnzbyI=; b=f4GJU8kuHU9p39LLgo6sW0yCVEfq/r/c+9gZZxq13hjKJzMNFl2qgNSIQKlLkUzeprVTrLOp3/C+lL7/FPJQbXosuTzFLwhRnexwYHDrRv3THxJtZekOTM7bgug2tBuQLVT3sO1jPjZGYLhyPbdtP33u7qJ5Vt7ZJODEACicgWPa8yI+d7TEVvSVIkD4xyYmk0Cyab6ic1XbTbrt7+TbiBln7bMfMTYAKTXZ/DD8k8ByVLrsg69T8YBfjcQfscxx Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 30 Jul 2018 00:13:57 -0000 Received: by ary.qy (Postfix, from userid 501) id 0986820030FC71; Sun, 29 Jul 2018 20:13:56 -0400 (EDT) Date: 29 Jul 2018 20:13:56 -0400 Message-Id: <20180730001357.0986820030FC71@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: sklist@kitterman.com In-Reply-To: <4878884.yiV4iTtLKX@kitterma-e6430> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] WGLC on draft-ietf-dmarc-rfc7601bis-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2018 00:14:00 -0000 In article <4878884.yiV4iTtLKX@kitterma-e6430> you write: >> In authentication service identifiers in EAI-formatted messages, a U-label >> and its equivalent A-label are considered to be the same. > >As an implementer (who's tried really hard to avoid spending cycles on EAI - >sorry), does this translate into "be prepared for UTF-8 in any A-R element >that may contain an email address or a domain"? That's partly it. IDN domain labels can be in two different forms, a UTF-8 U-label or an xn--punycode A-label. It would be a good idea to treat them as equivalent. There are translation libraries, and it's easy to recognize U-labels by checking for the 0x80 bit so this is not a lot of code. Having been writing MTA patches to handle EAI better last week, I say this from experience. R's, John From nobody Sun Jul 29 22:41:12 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3217A130DC4 for ; Sun, 29 Jul 2018 22:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcIwzmZvmgA2 for ; Sun, 29 Jul 2018 22:41:08 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8225412F18C for ; Sun, 29 Jul 2018 22:41:08 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id w16-v6so5734576ljh.12 for ; Sun, 29 Jul 2018 22:41:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qbV9kJsFulhPj2XTj0wjgMGogoxh1HXQhKpCtpSMvwE=; b=gtGNMgX9gOMV04U++tWgqXHmdBo5lF856J8UZ9/FnHdHKPRaLVu97Ai053+bV7rbmY v5nzyP35pfTGXESepeyyQBSRiYM/9SAtwdsWTj2OPfeogZnmcNjlJjBhVcFtyoJ3qxeD WYKNGeuMn7Sq4boUtb/LyjCqSf9wKkMbGePZsovJDYFmM8Nqa6HLCVSgkWZiTH6NCSFW BAilMVNlD6KJioNtWShu5iuPlSo4i7XlR8TpM9wqMImlBrx92ScGJ53Rzq4NE1rHxT9R wBESLH8CtnS8vXlGdIjgVZeKZ4lvwAys6G4X/w6p8X41uK6/0Z6E5h3xlTQSirXOvQLS LDgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qbV9kJsFulhPj2XTj0wjgMGogoxh1HXQhKpCtpSMvwE=; b=QCrk9AxW+k2NkwAKXJtSX0fGaGktTU3hSeL+KaRb6jjGgmS1Bi9yMffuLOsiadivCb emhTbzn9yn8+aTxFq6H9E8/SOYKwKvRkwcJhmenkAZvQOkhsEWNORS/AqBEcYKjXV95R eIB6fM/DLHBvAoAkQmY1xExfCYt2otNJAfyRyE6MnjkztZMXiIgLhU7ic1xaRcjFabcR 9QPg3stpITfxJEQ5h5NYORcrEVg/jenhM9UDBcSgoM+LkUtOlKbkheSEeE9Pp+AmZ1un RJxIns1grFSi5a8IX1L7mmObiR8gD3YiSkHDAGK4RUDOvexWltEsDcSP8ZEXrvC5o1YI pkww== X-Gm-Message-State: AOUpUlGTPuzVXsimb30Yzk/CXEPMydlGy0Wx5W78FoKxLaIuPyb2QCdv aTHTNoEhi12hy67mg4bQcU6t7Ba+2LIqDYtAXtDU0A== X-Google-Smtp-Source: AAOMgperZHMCwZYLcyISxKb+pKyjCVAQrlH7YX0EU3FRBeLZSffN95DlrlJsqoeDPpoOkg89Cw7xEm/MZyJsJ3DWsmo= X-Received: by 2002:a2e:1dc8:: with SMTP id w69-v6mr12386945lje.110.1532929266660; Sun, 29 Jul 2018 22:41:06 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:3a13:0:0:0:0:0 with HTTP; Sun, 29 Jul 2018 22:41:05 -0700 (PDT) In-Reply-To: <20180730001357.0986820030FC71@ary.qy> References: <4878884.yiV4iTtLKX@kitterma-e6430> <20180730001357.0986820030FC71@ary.qy> From: "Murray S. Kucherawy" Date: Sun, 29 Jul 2018 22:41:05 -0700 Message-ID: To: John Levine Cc: IETF DMARC WG , Scott Kitterman Content-Type: multipart/alternative; boundary="00000000000067b8da057230e80b" Archived-At: Subject: Re: [dmarc-ietf] WGLC on draft-ietf-dmarc-rfc7601bis-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2018 05:41:10 -0000 --00000000000067b8da057230e80b Content-Type: text/plain; charset="UTF-8" On Sun, Jul 29, 2018 at 5:13 PM, John Levine wrote: > In article <4878884.yiV4iTtLKX@kitterma-e6430> you write: > >> In authentication service identifiers in EAI-formatted messages, a > U-label > >> and its equivalent A-label are considered to be the same. > > > >As an implementer (who's tried really hard to avoid spending cycles on > EAI - > >sorry), does this translate into "be prepared for UTF-8 in any A-R > element > >that may contain an email address or a domain"? > > That's partly it. IDN domain labels can be in two different forms, a > UTF-8 U-label or an xn--punycode A-label. It would be a good idea to > treat them as equivalent. There are translation libraries, and it's > easy to recognize U-labels by checking for the 0x80 bit so this is not > a lot of code. Having been writing MTA patches to handle EAI better > last week, I say this from experience. > Does that mean the proposed change is appropriate, or the current text is sufficient? -MSK --00000000000067b8da057230e80b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Jul 29, 2018 at 5:13 PM, John Levine <johnl@taugh.c= om> wrote:
In article <48788= 84.yiV4iTtLKX@kitterma-e6430> you write:
>> In authentication service identifiers in EAI-formatted messages, a= U-label
>> and its equivalent A-label are considered to be the same.
>
>As an implementer (who's tried really hard to avoid spending cycles= on EAI -
>sorry), does this translate into "be prepared for UTF-8 in any A-R= element
>that may contain an email address or a domain"?

That's partly it.=C2=A0 IDN domain labels can be in two differen= t forms, a
UTF-8 U-label or an xn--punycode A-label.=C2=A0 It would be a good idea to<= br> treat them as equivalent.=C2=A0 There are translation libraries, and it'= ;s
easy to recognize U-labels by checking for the 0x80 bit so this is not
a lot of code.=C2=A0 Having been writing MTA patches to handle EAI better last week, I say this from experience.

= Does that mean the proposed change is appropriate, or the current text is s= ufficient?

-MSK
--00000000000067b8da057230e80b-- From nobody Sun Jul 29 22:58:38 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF2D130DDB for ; Sun, 29 Jul 2018 22:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAIlAPt4SEQh for ; Sun, 29 Jul 2018 22:58:33 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FA8B130DC5 for ; Sun, 29 Jul 2018 22:58:32 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id 203-v6so9336346ljj.13 for ; Sun, 29 Jul 2018 22:58:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cwNuzEnAVbOHMe/nFSM5rO3FwZXQ+gTzLSujZ4f8Oso=; b=YCW7QigWB+ACQ3ibkG0HdWOcjSOXzlAXSPNMAlxdybU1eWSiEF5eND0Ef3goZW8vpx dHaNA6LJIBpSsa811h6nI18ta2E7q/7xBE+ZVXT7ATU+KnQMmcuBNlEX+jGweMov3GaQ JFNb1KZ1aydI5ip4hTBc66ONTw3YHnJ54ofvfHSCgpsAjmTOqT9kOju0aa2nXCxeNG9J INhMTo9F+dR4tztcHlbgSpFWJadbKBlNMD+5qfFpcP68xFjwp7QGYNK2unf4T/b6mgkB 7S+rpQsazkBkRi/DKiNG8SqbAFPAK5mJDCyQZys/LFlp6PoyaeW78aCQUigJxIr+i9yV LLCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cwNuzEnAVbOHMe/nFSM5rO3FwZXQ+gTzLSujZ4f8Oso=; b=R1WSz554WDSvxQcv4+tWH/yzJ3WMlNhbh5WjFIGUJZWqc6JWIPbNJOdH/sQ6eamBS1 xmbj6qd0/MM5TPHspoPxko8O+83wFEDHxa4/uJvAS6/fkwn84QhM2VAFu78pqfiQEj0k 51DXccCsTTZe2sD1kYKlv8HMktjGJCw9UZcEks+zITivg3MTzy6ozPs7xFfA2p+0Wf3S ajMbssgGFNs8H0GJTfZYtNDwo5hXVsJfXTUvFyXUzPOtPnxvvbT0Rbln/ZykjDNedrS7 792G+uRnbdrPkXeily7cLscN5Irm1l+v52wo/0tDucKMDj/dgXusiyNJWeDClAuT5EMF B9vg== X-Gm-Message-State: AOUpUlEP5i5zulksu8ub3ejclJTfS/1aAwxJMPMPTTBid1Mv4iCLSzXf A1WQ4Y0UmYVbitxZkACTkKqxrOdaINSb5NyZRAoxAQ== X-Google-Smtp-Source: AAOMgpez7TeXmiE6L2hGmzHHpUFIteUaFoGGRYleqDNd6pntkwB1qqtHgJ4VXr5cleHb+9JhaTPTWtpJT4wUDBJQv4w= X-Received: by 2002:a2e:1dc8:: with SMTP id w69-v6mr12439181lje.110.1532930310554; Sun, 29 Jul 2018 22:58:30 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:3a13:0:0:0:0:0 with HTTP; Sun, 29 Jul 2018 22:58:29 -0700 (PDT) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Sun, 29 Jul 2018 22:58:29 -0700 Message-ID: To: Alessandro Vesely Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000a048630572312624" Archived-At: Subject: Re: [dmarc-ietf] WGLC on draft-ietf-dmarc-rfc7601bis-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2018 05:58:36 -0000 --000000000000a048630572312624 Content-Type: text/plain; charset="UTF-8" On Sun, Jul 29, 2018 at 11:23 AM, Alessandro Vesely wrote: > On Sun 15/Jul/2018 20:04:51 +0200 Barry Leiba wrote: > > > So begins Working Group Last Call (WGLC) on draft-ietf-dmarc-rfc7601bis- > 02. > > > > Please review the latest version: > > https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/ > > .... and send comments to the DMARC working group mailing list by 3 > August. > > *Registries definitions* > Did the WG decide whether this document is going to update or obsolete > rfc7601? > IIRC, the catch was that obsoleting would require registries > [re]definition > lest leaving pointers to obsolete defining documents. Hm... perhaps it's > fine > for a deprecated definition to point to an obsolete document... I'm not > good at > that, I'm asking. > I thought it was pretty clear that this is a replacement, which means it obsoletes 7601. > *Domain based* > An introductory paragraph sounds outworn, since rfc7281 is not > domain-based: > > This specification is not intended to be restricted to domain-based > authentication schemes, but the existing schemes in that family have > proven to be a good starting point for implementations. > True, this can be removed. *EAI addresses* > +1 for adding "or email addresses" in Section 1.5.2, Internationalized > Email, > after the words "allow UTF-8 in most places that free-form text ". > Deferring to the follow-up thread on this one. *Section 1.2. "Trust Boundary"* > That section ends with two questionable statements about A-R fields found > in an > attachment: > > The details reported by this field cannot be > trusted in that case. Thus, this field found within one of those > media types is typically ignored. > > How about generic spam complaints and ARF reports of various kinds? Of > course, > trust in the report originator may vary, but I wouldn't say the field is > typically ignored. > Do you have a suggestion for alternative text? *This proposal* > The term appears three times (sections 1.5.3. "Security", 7.11. "Reverse > Mapping", and Appendix A. "Legacy MUAs"). Won't the approved RFC be > promoted > to "Internet Standard"? In that case, I'd s/proposal/standard/. > No, this is not being advanced to Internet Standard by this action. It could be, I suppose, but the WG hasn't discussed that question. I'll change "proposal" to "specification". *Section 1.6. "Trust Environment"* > The first paragraph deserves a reference to Section 5 "Removing Existing > Header > Fields". > I kind of like how the various parts of Section 1 stand alone in terms of laying out the ground work for what follows. I'll change it if there's consensus, however. > *authres-payload* > This rule is new. Yet, the corresponding syntax doesn't seem to be > changed; it > seems to be just a readability improvement. Is that obvious? If not, I'd > mention this change/non-change as a first entry in Appendix D, to reassure > parsers implementers. Or am I misreading the ABNF? > It's meant to create a token that is easier for other documents (e.g., ARC) to import. I'll make an entry for it in Appendix D. > *special-smtp-verb* > This rule is redundant and, if we're after readability, can be striked. In > fact, both terms it produces fall under the "Keyword" rule. In addition, > IANA > reports smtp.rcptto as defined by rfc7293, so it can be omitted here. > It's not redundant. MAILFROM and RCPTTO are not SMTP verbs. *Keyword enumeration* > The note says: > > "Keyword" is defined in Section 4.1.2 of [SMTP]. When used in > "result" above, it is further constrained by the necessity of being > enumerated in Section 2.7. > > I'd replace it with: > > "Keyword" is defined in Section 4.1.2 of [SMTP]. It is further > constrained > by the necessity of being registered in the relevant IANA Registry. See > Section 6. > > Simpler and direct, no? > Not quite, because "Keyword" is used in four places, not just that one, and when used as a "policy", its registration is not required because it only means something locally. But I see what you're getting and I'll fix it up. *prospec omission* > OLD: > > The "propspec" may be omitted if, for example, the method was unable > to extract any properties to do its evaluation yet has a result to > report. > > NEW: > > The "propspec" may be omitted if the method was unable to extract or > unwilling to disclose any properties involved in its evaluation, yet > has a > result to report. > What's an example? *policy* > This ptype can now evolve from catchall to meaningful indicator: > OLD: > > A "ptype" value of "policy" indicates a policy decision about the > message not specific to a property of the message that could be > extracted. See Section 2.4 for details. > > NEW: > > A "ptype" value of "policy" indicates a policy decision about the > method. Its presence in a "resinfo" indicates that the algorithmic > result > of the method might have been overridden because of an internal > criterion. > Both "property" and "pvalue" concur at hinting what the internal > criterion > was. See Section 2.4 for details. > > The above interpretation is based on the example in Section 2.4, The > "policy" > ptype, which reads: > > ... dkim=fail policy.dkim-rules=unsigned-subject ... > I disagree, because I think the existing text still adequately captures this case; there's been a policy decision made that was unrelated to some value found in a header field or tag (i.e., it's not a straight "fail"), but rather some combination of things that violates something the verifying ADMD wants to enforce. > *Section 2.7. "Defined Methods and Result Values"* > s/New methods/Methods/ > Why? It's referring to methods that may come in the future, which I would consider "new". -MSK --000000000000a048630572312624 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Jul 29, 2018 at 11:23 AM, Alessandro Vesely &= lt;vesely@tana.it&g= t; wrote:
On Sun = 15/Jul/2018 20:04:51 +0200 Barry Leiba wrote:

> So begins Working Group Last Call (WGLC) on draft-ietf-dmarc-rfc7601bi= s-02.
>
> Please review the latest version:
> https://datatracker.ietf.org/= doc/draft-ietf-dmarc-rfc7601bis/
> .... and send comments to the DMARC working group mailing list = by 3 August.

*Registries definitions*
Did the WG decide whether this document is going to update or obsolete rfc7= 601?
=C2=A0IIRC, the catch was that obsoleting would require registries [re]defi= nition
lest leaving pointers to obsolete defining documents.=C2=A0 Hm... perhaps i= t's fine
for a deprecated definition to point to an obsolete document... I'm not= good at
that, I'm asking.

I thought it was = pretty clear that this is a replacement, which means it obsoletes 7601.


*Domain based*
An introductory paragraph sounds outworn, since rfc7281 is not domain-based= :

=C2=A0 =C2=A0This specification is not intended to be restricted to domain-= based
=C2=A0 =C2=A0authentication schemes, but the existing schemes in that famil= y have
=C2=A0 =C2=A0proven to be a good starting point for implementations.

=C2=A0True, this can be removed.

*EAI addresses*
+1 for adding "or email addresses" in Section 1.5.2, Internationa= lized Email,
after the words "allow UTF-8 in most places that free-form text "= .

Deferring to the follow-up thread on = this one.

*Section 1.2. "Trust Boundary"*
That section ends with two questionable statements about A-R fields found i= n an
attachment:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 The details reported by this field cannot be
=C2=A0 =C2=A0trusted in that case.=C2=A0 Thus, this field found within one = of those
=C2=A0 =C2=A0media types is typically ignored.

How about generic spam complaints and ARF reports of various kinds?=C2=A0 O= f course,
trust in the report originator may vary, but I wouldn't say the field i= s
typically ignored.

Do you have a sugges= tion for alternative text?

*This proposal*
The term appears three times (sections 1.5.3. "Security", 7.11. &= quot;Reverse
Mapping", and Appendix A. "Legacy MUAs").=C2=A0 Won't th= e approved RFC be promoted
to "Internet Standard"?=C2=A0 In that case, I'd s/proposal/st= andard/.

No, this is not being advanced= to Internet Standard by this action.=C2=A0 It could be, I suppose, but the= WG hasn't discussed that question.

I'll change &= quot;proposal" to "specification".

*Section 1.6. "Trust Environment"*
The first paragraph deserves a reference to Section 5 "Removing Existi= ng Header
Fields".

I kind of like how the va= rious parts of Section 1 stand alone in terms of laying out the ground work= for what follows.=C2=A0 I'll change it if there's consensus, howev= er.
=C2=A0
*authres-payload*
This rule is new.=C2=A0 Yet, the corresponding syntax doesn't seem to b= e changed; it
seems to be just a readability improvement.=C2=A0 Is that obvious?=C2=A0 If= not, I'd
mention this change/non-change as a first entry in Appendix D, to reassure<= br> parsers implementers.=C2=A0 Or am I misreading the ABNF?

It's meant to create a token that is easier for other= documents (e.g., ARC) to import.=C2=A0 I'll make an entry for it in Ap= pendix D.
=C2=A0
*special-smtp-verb*
This rule is redundant and, if we're after readability, can be striked.= =C2=A0 In
fact, both terms it produces fall under the "Keyword" rule.=C2=A0= In addition, IANA
reports smtp.rcptto as defined by rfc7293, so it can be omitted here.

It's not redundant.=C2=A0 MAILFROM and R= CPTTO are not SMTP verbs.

*Keyword enumeration*
The note says:

=C2=A0 =C2=A0"Keyword" is defined in Section 4.1.2 of [SMTP].=C2= =A0 When used in
=C2=A0 =C2=A0"result" above, it is further constrained by the nec= essity of being
=C2=A0 =C2=A0enumerated in Section 2.7.

I'd replace it with:

=C2=A0 =C2=A0"Keyword" is defined in Section 4.1.2 of [SMTP].=C2= =A0 It is further constrained
=C2=A0 =C2=A0by the necessity of being registered in the relevant IANA Regi= stry.=C2=A0 See
=C2=A0 =C2=A0Section 6.

Simpler and direct, no?

Not quite, beca= use "Keyword" is used in four places, not just that one, and when= used as a "policy", its registration is not required because it = only means something locally.=C2=A0 But I see what you're getting and I= 'll fix it up.

*prospec omission*
OLD:

=C2=A0 =C2=A0The "propspec" may be omitted if, for example, the m= ethod was unable
=C2=A0 =C2=A0to extract any properties to do its evaluation yet has a resul= t to
=C2=A0 =C2=A0report.

NEW:

=C2=A0 =C2=A0The "propspec" may be omitted if the method was unab= le to extract or
=C2=A0 =C2=A0unwilling to disclose any properties involved in its evaluatio= n, yet has a
=C2=A0 =C2=A0result to report.

What'= ;s an example?

*policy*
This ptype can now evolve from catchall to meaningful indicator:
OLD:

=C2=A0 =C2=A0A "ptype" value of "policy" indicates a po= licy decision about the
=C2=A0 =C2=A0message not specific to a property of the message that could b= e
=C2=A0 =C2=A0extracted.=C2=A0 See Section 2.4 for details.

NEW:

=C2=A0 =C2=A0A "ptype" value of "policy" indicates a po= licy decision about the
=C2=A0 =C2=A0method.=C2=A0 Its presence in a "resinfo" indicates = that the algorithmic result
=C2=A0 =C2=A0of the method might have been overridden because of an interna= l criterion.
=C2=A0 =C2=A0Both "property" and "pvalue" concur at hin= ting what the internal criterion
=C2=A0 =C2=A0was.=C2=A0 See Section 2.4 for details.

The above interpretation is based on the example in Section 2.4, The "= policy"
ptype, which reads:

=C2=A0 =C2=A0 =C2=A0 ... dkim=3Dfail policy.dkim-rules=3Dunsigned-subj= ect ...

I disagree, because I think the= existing text still adequately captures this case; there's been a poli= cy decision made that was unrelated to some value found in a header field o= r tag (i.e., it's not a straight "fail"), but rather some com= bination of things that violates something the verifying ADMD wants to enfo= rce.



*Section 2.7. "Defined Methods and Result Values"*
s/New methods/Methods/

Why?=C2=A0 It= 9;s referring to methods that may come in the future, which I would conside= r "new".

-MSK

<= /div> --000000000000a048630572312624-- From nobody Mon Jul 30 08:41:01 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 254EB1310F2 for ; Mon, 30 Jul 2018 08:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtY8a8L7hF6G for ; Mon, 30 Jul 2018 08:40:58 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5768D130DD4 for ; Mon, 30 Jul 2018 08:40:58 -0700 (PDT) Received: (qmail 58594 invoked from network); 30 Jul 2018 15:40:57 -0000 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 30 Jul 2018 15:40:57 -0000 Date: 30 Jul 2018 11:40:57 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" Cc: "IETF DMARC WG" In-Reply-To: References: <4878884.yiV4iTtLKX@kitterma-e6430> <20180730001357.0986820030FC71@ary.qy> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] WGLC on draft-ietf-dmarc-rfc7601bis-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2018 15:41:00 -0000 >>>> In authentication service identifiers in EAI-formatted messages, a U-label >>>> and its equivalent A-label are considered to be the same. > Does that mean the proposed change is appropriate, or the current text is > sufficient? I still prefer my proposed change. The way you handle A-labels and U-labels is an implementation detail. Some convert everything to A, some convert everything to U, some have convoluted comparison routines. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Jul 30 11:16:37 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36AAD1311EB for ; Mon, 30 Jul 2018 11:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4LMAhyut2bN for ; Mon, 30 Jul 2018 11:15:57 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52358130E96 for ; Mon, 30 Jul 2018 11:10:36 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id d189-v6so22955516oib.6 for ; Mon, 30 Jul 2018 11:10:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=ryefvDV0qrmn6UE3NeYL0cVl4vNxckpxkNb0BpN7/XQ=; b=SSCTznwpARoGcKnjpCW9FzHzHB3o09HZm5jUX9xD/Knie0PaAEtXLEqku/Cx9Ju7wB 1O+qo8GqdZrJNLhH2V8HxnJCGWBlfPWyHLLa18sWXfTPw2LgAVN76iWMNlw2y3Mwtei3 2zqopZTgJwTpwhGKa9mwOjvZWty+3oCtFywLCSQU+//85CoOJInJ6/uzdHtR37pwZ1yO SQ+XbNGLh5pMQepxu5zSZtgrlBKd3u+35N2iz+pJDhk8S7WFInyjiWHBgv1fzhfDOKLh Et9ALxiW6DeI36Vz369CdduKF3fD46QKR9gs0tuMmQNLMrMlWMJTCmNwBTIuObpbf/C0 b0Ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=ryefvDV0qrmn6UE3NeYL0cVl4vNxckpxkNb0BpN7/XQ=; b=VJ5plVQfu0k0fuITKDcqdrTGoxM9k7aeuEDMWoogBmeKRImcdcSb9dY9bmH+ssjWCr Nj596Ryewc7HodWRaYEcLQz2NDtGmGTtUwU73xzCGlFHvy4LhuzX1ymkfrfgVSksBtxk f2Hfage9iJ0YxT/45h/4SKhq5+zYMSxB2f404ObKp4SQ+Hi5AzLUG35jODUW5h2S1plQ j7RskNa+lyuJsfBz5H29sfwHDW1wcWnljREs0w5B7CwCJFGl/VfbsIv2fMQFDCsu7lVD XMmAHVaBYLwKZx/ATe9CkDp44WFKma/F2av6s++d4Y1uObUeaaNCe88hiGAj2JAsScx0 HHyg== X-Gm-Message-State: AOUpUlFfBfIlTeIGGQ9F35NDYdIdxtqrO/t29WKW+cEGQaLbghxcnCWw GISbtAKZCeOmvX8femLbjZ6TB0Ci1nqqx+dFMHHoFSc6v/A= X-Google-Smtp-Source: AAOMgpdL94cKkZbRMSnS+m+gJcrpfK1xxpDq65GnyhHYteQPu9i2j0Cx0gfURDBPtB81br+mQQBoGNq5oJaC8uaNRY0= X-Received: by 2002:aca:cdc2:: with SMTP id d185-v6mr5595011oig.350.1532974235232; Mon, 30 Jul 2018 11:10:35 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:2646:0:0:0:0:0 with HTTP; Mon, 30 Jul 2018 11:10:14 -0700 (PDT) In-Reply-To: <1532905189.2879805.1456751232.5F2CDCE4@webmail.messagingengine.com> References: <1532745551.208119.1455489824.75DFC005@webmail.messagingengine.com> <1532905189.2879805.1456751232.5F2CDCE4@webmail.messagingengine.com> From: Seth Blank Date: Mon, 30 Jul 2018 11:10:14 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000bdc35a05723b60be" Archived-At: Subject: Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2018 18:16:09 -0000 --000000000000bdc35a05723b60be Content-Type: text/plain; charset="UTF-8" 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" analogy, if you have a bag of evidence and it's been unsupervised > in the hands of an unknown party, the contents have no evidentiary value > any more. > > There's two types of fail - fail on AMS, which could just be a > modification by somebody, and a fail on an AS, which means there's > definitely either buggy software or somebody screwing with the chain. > > But even a single AMS fail means that an unknown intermediary could have > changed every single header that's covered by the AMS. There's no way to > know what they changed. Ditto the body. It could be a totally different > message and there's no way to know because the chain of evidence is broken. > > So again - all that you can know when you see a broken AMS is that > somebody got their hands on a message which had followed the existing chain. > There are two premises to keep in mind: 1) For the first chunk of ARC's life, there will be a significant amount of ARC breakage due to intermediaries who do not properly or yet implement ARC. Some of the data ARC collects may in isolating these intermediaries and helping them properly adopt ARC. 2) we don't know what data is valuable yet, and would rather collect extra data than throw out potentially useful data (Section 11.3.3) Given these, it is worthwhile to capture the chain information even in failing states (i.e. cv=fail should sign greedily), especially when you consider the three major failure scenarios: 1) A good actor improperly Sealing ALL the data in the Chain is valuable, including the breakage, because it isolates the issue and allows that improper Sealer to get feedback and fix their systems. Realistically, there will be a lot of work done here, as intermediaries deploying ARC for the first time may get it wrong. 2) A good actor not Sealing Again, ALL the data in the Chain is valuable, as it would isolate where the breaking intermediary is and allow outreach. This will probably be the most prevalent ARC failure we see in the wild in the near term - mailing lists that do not yet Seal. 3) A bad actor modifying the chain Sure, the Chain is garbage. But if all the AS's validate, then the bad actor's been forced down two paths: either a) they are forced to extend or replay a valid chain, or b) they must create a garbage chain using only domains they have DNS control over. If the AS's don't need to validate, then there are numerous malicious paths an attacker can take to modify the chain in subtle ways. --000000000000bdc35a05723b60be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= un, Jul 29, 2018 at 3:59 PM, Bron Gondwana <brong@fastmailteam.com> wrote:
I'm not sure what you mean by "th= e veracity of the header field data".=C2=A0 Can you give an example of= a cv=3Dfail where there's useful information still trustworthy in the = message, because I don't see it.=C2=A0 To use the "chain of custod= y" analogy, if you have a bag of evidence and it's been unsupervis= ed in the hands of an unknown party, the contents have no evidentiary value= any more.

There's two types of fail - fail on AM= S, which could just be a modification by somebody, and a fail on an AS, whi= ch means there's definitely either buggy software or somebody screwing = with the chain.

But even a single AMS fail means that an u= nknown intermediary could have changed every single header that's cover= ed by the AMS.=C2=A0 There's no way to know what they changed.=C2=A0 Di= tto the body.=C2=A0 It could be a totally different message and there's= no way to know because the chain of evidence is broken.

So again - all that you can know when you = see a broken AMS is that somebody got their hands on a message which had fo= llowed the existing chain.

There are two prem= ises to keep in mind:

=
1) For the first chunk of ARC's l= ife, there will be a significant amount of ARC breakage due to intermediari= es who do not properly or yet implement ARC. Some of the data ARC collects = may in isolating these intermediaries and helping them properly adopt ARC.<= br>

2) we don't know what data is valuable yet, and would rather collect e= xtra data than throw out potentially useful data (Section 11.3.3)

Giv= en these, it is worthwhile to capture the chain information even in failing= states (i.e. cv=3Dfail should sign greedily), especially when you consider= the three major failure scenarios:

1) A good actor improperly Sealing

ALL the data in = the Chain is valuable, including the breakage, because it isolates the issu= e and allows that improper Sealer to get feedback and fix their systems. Re= alistically, there will be a lot of work done here, as intermediaries deplo= ying ARC for the first time may get it wrong.

2) A good actor not Sealing

Again, ALL th= e data in the Chain is valuable, as it would isolate where the breaking int= ermediary is and allow outreach. This will probably be the most prevalent A= RC failure we see in the wild in the near term - mailing lists that do not = yet Seal.

3) A bad actor modifying the chain

=
Sure, the Chain is garbage. But if all the= AS's validate, then the bad actor's been forced down two paths: ei= ther a) they are forced to extend or replay a valid chain, or b) they must = create a garbage chain using only domains they have DNS control over. If th= e AS's don't need to validate, then there are numerous malicious pa= ths an attacker can take to modify the chain in subtle ways.

--000000000000bdc35a05723b60be-- From nobody Mon Jul 30 11:34:49 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98E1C130EAA for ; Mon, 30 Jul 2018 11:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwjtSY5xGYVL for ; Mon, 30 Jul 2018 11:34:44 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [IPv6:2610:20:6005:13::151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53DAA130EA6 for ; Mon, 30 Jul 2018 11:34:44 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.399.0; Mon, 30 Jul 2018 14:34:38 -0400 Received: from postmark.nist.gov (129.6.16.94) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.3.399.0; Mon, 30 Jul 2018 14:34:40 -0400 Received: from [129.6.140.7] (7-140.antd.nist.gov [129.6.140.7]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id w6UIYB6g012186 for ; Mon, 30 Jul 2018 14:34:12 -0400 From: "Rose, Scott" To: Date: Mon, 30 Jul 2018 14:34:11 -0400 X-Mailer: MailMate (1.11.3r5509) Message-ID: <54D0B12C-2BE5-4B4C-AD44-99AE6044DCB5@nist.gov> In-Reply-To: <1532472947.3343083.1451792120.35CD7BCD@webmail.messagingengine.com> References: <1532472947.3343083.1451792120.35CD7BCD@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_AF265F1C-829B-485E-A790-15CF47F459D3_=" Embedded-HTML: [{"HTML":[502, 1280], "plain":[235, 784], "uuid":"BAE76D82-A26E-4B67-92C1-A6E16A777A40"}] X-NIST-MailScanner-Information: Archived-At: Subject: Re: [dmarc-ietf] Approval of draft-ietf-dmarc-arc-protocol-16 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2018 18:34:48 -0000 --=_MailMate_AF265F1C-829B-485E-A790-15CF47F459D3_= Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable I also support ARC-16 (or the version that comes out of WGLC) for = experimental. I=E2=80=99ve been trying to follow the discussion, but the= core = part of the draft seems ready to go. Scott On 24 Jul 2018, at 18:55, Bron Gondwana wrote: > This isn't a detailed review, because I haven't had time to do it, but > I've been following the process and I'm happy that ARC-16 is ready as = > an > experimental standard. > I'm also happy with Dave's suggested improvements to the descriptive > text. My general belief is that descriptive text is important, but = > test > cases are importanter, when it comes to getting good quality > implementations! Having implementations out there which have been > tested against each other is part of getting interoperability, and the > hackathons have been good for this, but having an experimental = > standard > to encourage more deployment so we can collect data on real mail flows > is important too. > Cheers, > > Bron. > > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.= ietf.org%2Fmailman%2Flistinfo%2Fdmarc&data=3D02%7C01%7Cscott.rose%40n= ist.gov%7C7978fd9fc4034aa9917c08d5f1b8a427%7C2ab5d82fd8fa4797a93e054655c6= 1dec%7C1%7C0%7C636680697691762866&sdata=3DGq08sjYS1lSmsBYyASt%2FiCrgu= fQbAMAORAAqqYS15ME%3D&reserved=3D0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Scott Rose NIST ITL scott.rose@nist.gov +1-301-975-8439 GV: +1-571-249-3671 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --=_MailMate_AF265F1C-829B-485E-A790-15CF47F459D3_= Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I also support ARC= -16 (or the version that comes out of WGLC) for experimental. I=E2=80=99= ve been trying to follow the discussion, but the core part of the draft s= eems ready to go.

Scott

On 24 Jul 2018, at 18:55, Bron Gondwana wrote:

This isn't a detailed review, because I= haven't had time to do it, but I've been following the process and I'm h= appy that ARC-16 is ready as an experimental standard.

I'm also happy with Dave's suggested im= provements to the descriptive text.=C2=A0 My general belief is that descr= iptive text is important, but test cases are importanter, when it comes t= o getting good quality implementations!=C2=A0 Having implementations out = there which have been tested against each other is part of getting intero= perability, and the hackathons have been good for this, but having an exp= erimental standard to encourage more deployment so we can collect data on= real mail flows is important too.

Cheers,

Bron.

--
=C2=A0 Bron Gondwana, CEO, FastMail Pty Ltd
=C2=A0 brong@fastmailteam.com


________________________________= _______________
dmarc mailing list
dmarc@ietf.org
https://na01= =2Esafelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fm= ailman%2Flistinfo%2Fdmarc&amp;data=3D02%7C01%7Cscott.rose%40nist.gov%= 7C7978fd9fc4034aa9917c08d5f1b8a427%7C2ab5d82fd8fa4797a93e054655c61dec%7C1= %7C0%7C636680697691762866&amp;sdata=3DGq08sjYS1lSmsBYyASt%2FiCrgufQbA= MAORAAqqYS15ME%3D&amp;reserved=3D0


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Scott Rose
NIST ITL
scott.rose@nist.gov
+1-301-975-8439
GV: +1-571-249-3671
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--=_MailMate_AF265F1C-829B-485E-A790-15CF47F459D3_=-- From nobody Mon Jul 30 13:48:19 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 568A0130EB9 for ; Mon, 30 Jul 2018 13:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQdE_XpcCmLq for ; Mon, 30 Jul 2018 13:48:15 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3837512D7F8 for ; Mon, 30 Jul 2018 13:48:15 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id k12-v6so23835785oiw.8 for ; Mon, 30 Jul 2018 13:48:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=FDp2vcmqX2+XO1psobPkVDfEhr8r+wk0vPVVHTo3Omg=; b=rV9doqqN6T0yUzCuf1QVj5Ef3RTbHQobqJ2xj43HdIQ+ql2+1AImB8s/fFVycYiuPW Ho3lSyMu004pVURIH/TqDUd/C3Pcl/tHHXJGiBtZfmbo8eNpuc9IX4SLMpqcMOiqvRFN ywMmzfPBQpRQ33Pd9hWj8Y29Nl3Ta8lAqLIuA2nI6DCxCdnWIwqeXDLQG1teIwHQ75/w HvI5J9paWDJibL7K5wDtY80a4mJ7En2SduAVspN0rbTjM7YZ9MDwG5AHU/mIUqJXqnsp 7J6cmzVfkwoO9HVo8KgYmVLVY0ExhBA9qnehLhxykHlJeINHmujypnDgcLRyr0GZNGpg evLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=FDp2vcmqX2+XO1psobPkVDfEhr8r+wk0vPVVHTo3Omg=; b=FeruPvCL0ZHbMwrDllw9kSp097uaeVeQ91DjAgOxo0Ogo74wqhv3xvcewRof4FD9PH kp+pxocLJ3/q6fiivrc+QrfbKRT+1rYe9uaVKw1FanWX/SEHoIhJ0+yXTMLUEWycSXPa pb/sZAGaK28GfRGMTVfVeSKpCwM7pHZZtRDAyLWoGlk3sBv+LtvMjGQ0LC3qVEWC1ZUM dv3cvKcSOiCQsNaY632B9HIu0QxRjUWmFVPnsWY+1gN0N9Ao9ARTii9PP+SquB4d011B d8/48+H/BhOc12PmgvwaQPVbCJNNW+cEt/zdeFNdZ9wJhDXNvjoJoEHJt6ikTOtrYtuM oSRg== X-Gm-Message-State: AOUpUlGleT7yB5ZNy1HfrKWT++iyO0pIR8I0cooOeJGfUaHuerPV2ws7 jfJKwlBVctOVawVLYee65fUikwTWZkaEDWIkS2NSybUoKs0= X-Google-Smtp-Source: AAOMgpeU5d/OksEKGz2Umc3LKCjsma2vTI/J3Up6fwxq6pbH4yFtNH4XLIgL0x4MbRcQv1EspNh2BqNzYvsafbouezI= X-Received: by 2002:aca:cf0e:: with SMTP id f14-v6mr20869286oig.356.1532983694149; Mon, 30 Jul 2018 13:48:14 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:2646:0:0:0:0:0 with HTTP; Mon, 30 Jul 2018 13:47:53 -0700 (PDT) In-Reply-To: References: <1532745551.208119.1455489824.75DFC005@webmail.messagingengine.com> <1532905189.2879805.1456751232.5F2CDCE4@webmail.messagingengine.com> From: Seth Blank Date: Mon, 30 Jul 2018 13:47:53 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000896aa705723d9456" Archived-At: Subject: Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2018 20:48:17 -0000 --000000000000896aa705723d9456 Content-Type: text/plain; charset="UTF-8" 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 otherwise possible to sign the entire ARC Chain (i.e. when the Chain is structurally invalid and a deterministic set of headers cannot be enumerated). Regardless of this behavior, the Chain is still equally dead. But in one scenario (initial ARC Chain not Sealed) you get no data from that dead chain, and in the other (failing Set Seals initial Chain) you can. Might it be clearer to make my recommended change and also put something in 5.1.2 saying that the cv=fail Seal is just for trace purposes since the chain can never validate per 5.2? --000000000000896aa705723d9456 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've been thinking about this and discussing offline, so to put it dif= ferently:

5.1.2 says when a chain fails, to put cv= =3Dfail 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 t= he entire ARC Chain (i.e. when the Chain is structurally invalid and a dete= rministic set of headers cannot be enumerated).

Re= gardless of this behavior, the Chain is still equally dead. But in one scen= ario (initial ARC Chain not Sealed) you get no data from that dead chain, a= nd in the other (failing Set Seals initial Chain) you can.

Might it be clearer to make my recommended change and also put som= ething in 5.1.2 saying that the cv=3Dfail Seal is just for trace purposes s= ince the chain can never validate per 5.2?
--000000000000896aa705723d9456-- From nobody Mon Jul 30 14:55:48 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD25130F04 for ; Mon, 30 Jul 2018 14:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrk6iqvgTO-O for ; Mon, 30 Jul 2018 14:55:43 -0700 (PDT) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 779E6130EF5 for ; Mon, 30 Jul 2018 14:55:43 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id g6-v6so9211679lfb.11 for ; Mon, 30 Jul 2018 14:55:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2xlK1f+wBPcPy/7POpadPvI0tDntMfZyj3NU2seIvMY=; b=u20ZdUW9TYKURFF2HS4Tl+PAU34l1jOblcHeQJ77ve1LvBc38z6yAM2lGz3kAbfZS6 OpfMfJ5KAQPUmI9ETvSTn7Vaqn47ilkAcB/HaZqsTnsho2RZcIMw/CjwtdsZ4mZ3JCxM Ql1BK8WjXPgyVaALXi/a3M1tzAldmUxDnRDHfk0d5QqqodJYBLWTLCMpOUDNYzCIjrzx q8go+MoERqyDMQNDAhPfC6fmOfZ/3FNTLBL2oQR1Phio+ldaGBAOi4IEUx1hIA0HJa64 REo611DpUct/lzzDF8UmXdK3dckFQ5OVupIWHHZXE+uXlEPKu/b5x/fBmke5pzyEe8oI pr7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2xlK1f+wBPcPy/7POpadPvI0tDntMfZyj3NU2seIvMY=; b=LrM3TeslxGsjvYVAG9QnuIy8JKxx+MrPlJD1xISbZyx1WZfJSOyTogHAS8VwxlAGbX ZFsz9ijhwO1XC4fLGSc2enIMIPI18mB3NoNs01c6ALlZlvvqj6/0PnMk8PBTU+hNR86q IRkhuwoNyBtlSPaXm9SqfDfqPIjyoiP7BRyUIazjrefjaEAzbEdamMK4WUE5A7fmGPk6 GX7f8+0HdPPttepJmKrRS1CfDF8mPPnTuexGMyLf/dUoswmQMfo7KZfA/36EcnhYzive JdJdTyCldl76u/XCkMX/AXvz3ZAAYw4U2fCE9kGrQ6MdVq4XHgJzqx5Astmx1E6IPbAY qmCQ== X-Gm-Message-State: AOUpUlF7KMtdkD6abA/iRMwSW9D7X3qtb3MPGnYpBXtkFYN25xM+GOlT UYzyPygi+FcDyEAZBSAMru6PIMT3f/6pjiAGfC8T6g== X-Google-Smtp-Source: AAOMgpdSChyejhoQq3u9rkQ4ltiqqjsyCzkeNrioIk1cpoMydYmPLNA+A4xpMHEbgwDSdlRN5JaScYHGNU+bVeFohjc= X-Received: by 2002:a19:9d92:: with SMTP id g140-v6mr12167610lfe.85.1532987741527; Mon, 30 Jul 2018 14:55:41 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:3a13:0:0:0:0:0 with HTTP; Mon, 30 Jul 2018 14:55:40 -0700 (PDT) In-Reply-To: References: <4878884.yiV4iTtLKX@kitterma-e6430> <20180730001357.0986820030FC71@ary.qy> From: "Murray S. Kucherawy" Date: Mon, 30 Jul 2018 14:55:40 -0700 Message-ID: To: John R Levine Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000c7642105723e85c4" Archived-At: Subject: Re: [dmarc-ietf] WGLC on draft-ietf-dmarc-rfc7601bis-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2018 21:55:47 -0000 --000000000000c7642105723e85c4 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 30, 2018 at 8:40 AM, John R Levine wrote: > In authentication service identifiers in EAI-formatted messages, a U-label >>>>> and its equivalent A-label are considered to be the same. >>>>> >>>> > Does that mean the proposed change is appropriate, or the current text is >> sufficient? >> > > I still prefer my proposed change. The way you handle A-labels and > U-labels is an implementation detail. Some convert everything to A, some > convert everything to U, some have convoluted comparison routines. > Ah, sorry, I hadn't seen your proposed change before. LGTM. -MSK --000000000000c7642105723e85c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jul 30, 2018 at 8:40 AM, John R Levine <johnl@tau= gh.com> wrote:
In authentication service identifiers in EAI-formatted messages, a U-label<= br> and its equivalent A-label are considered to be the same.

Does that mean the proposed change is appropriate, or the current text is sufficient?

 I still prefer my proposed change.=C2=A0 The way you handle A-labels and U-= labels is an implementation detail.=C2=A0 Some convert everything to A, som= e convert everything to U, some have convoluted comparison routines.

Ah, sorry, I hadn't seen your proposed ch= ange before.=C2=A0 LGTM.

-MSK
--000000000000c7642105723e85c4-- From nobody Mon Jul 30 15:26:26 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6E4C130F61 for ; Mon, 30 Jul 2018 15:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4thB2wRt1vaF for ; Mon, 30 Jul 2018 15:26:23 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2B29131143 for ; Mon, 30 Jul 2018 15:17:28 -0700 (PDT) Received: (qmail 26021 invoked from network); 30 Jul 2018 22:17:26 -0000 Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 30 Jul 2018 22:17:26 -0000 Received: by ary.qy (Postfix, from userid 501) id 713CE200316625; Mon, 30 Jul 2018 18:17:25 -0400 (EDT) Date: 30 Jul 2018 18:17:25 -0400 Message-Id: <20180730221726.713CE200316625@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: seth@sethblank.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2018 22:26:25 -0000 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 the Chain is structurally invalid and a >deterministic set of headers cannot be enumerated). I still have a question: if you have the right set of older headers, you could sign them even if they're corrupted and the signatures are invalid. But if the old sets have extra or missing headers, you can only sign your own set. 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. R's, John From nobody Mon Jul 30 15:35:59 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D97CD130F01 for ; Mon, 30 Jul 2018 15:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eudaemon.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzOet3bxn5Pl for ; Mon, 30 Jul 2018 15:35:56 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CB1D130E82 for ; Mon, 30 Jul 2018 15:35:56 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id q129-v6so5016618ywg.8 for ; Mon, 30 Jul 2018 15:35:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eudaemon.net; s=dkey; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+ezj6sxwzoaeyhff6S82wRA9lnV5M3SbMgEslj0lTvg=; b=fO292RgVjfYTmURdD9v9+K/NNR1SASy0WXQYUZPdaQ3iLKSotbis/pV+KPsCr3WrS6 K84eIOgM7pH8qHq5iVirx+L/HKBtbxACbblLt1zT97ZbIS7x8ffWUSchmzt2YIlePJFc v19HYEXyca/PAlWmTwVUa+j90ljXfHE6VqS5w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+ezj6sxwzoaeyhff6S82wRA9lnV5M3SbMgEslj0lTvg=; b=jxihchxbdsKKu08raI9syGNzrsM3ymwcS5ewfoeTSCrIULN0mYM44Td+t9mgXpNeJD I0/B8aEb1o/VKXtojhkYx/JGu/XGE4+lIV45OP7ou/epSZ9VW8Wphjb3k/3/DcgEAUXu qT1MISGXNY1tS/Dk8yIaf+YyFiFf45Qgk5srTHe73W8KPsY54/5DPD9M2nHzSvhmFkse /1fQAu5/iox0vht2xWXKHJkuzhkAj6DR2/Wqh8P7WjzWrC4yBNCG5TJ6fuuhDV+o+yp1 A6o6Ue5DY9F/BOzUq1H8EsZudVvnwwTAEZXHovBmkvFhXjONJtWnHhyj4mqRAsLdbjBl JfyQ== X-Gm-Message-State: AOUpUlF3aVuEqEDkirU58yowkuI8vLrnMzQnaFVYbDwgM71bSHq+5n7u 11upFS5elEbQpVBWFi6gRe+Qp5sY4c8= X-Google-Smtp-Source: AAOMgpdibNeyHb0q6m3aSRWbYOMAMbF2lY+iQn5ZzLnm+cuH2rBKNIgCdRani6GtRsijBaHZVFThnw== X-Received: by 2002:a0d:c203:: with SMTP id e3-v6mr9941094ywd.103.1532990154952; Mon, 30 Jul 2018 15:35:54 -0700 (PDT) Received: from [192.168.0.28] (208-104-133-98.brvd.dsl.dyn.comporium.net. [208.104.133.98]) by smtp.gmail.com with ESMTPSA id g31-v6sm8820549ywk.84.2018.07.30.15.35.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Jul 2018 15:35:53 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Tim Draegen In-Reply-To: Date: Mon, 30 Jul 2018 18:35:52 -0400 Cc: draft-ietf-dmarc-rfc7601bis@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9797FA7D-5F74-4F6A-A356-1128021ECA40@eudaemon.net> References: To: dmarc X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [dmarc-ietf] WGLC on draft-ietf-dmarc-rfc7601bis-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2018 22:35:58 -0000 To get an early start on shepherding the draft, I gave the draft a = top-to-bottom review with an eye towards readability. To ease the editor's burden, I'm avoiding posting a wall of diffs and = have opted for sending changes directly to the editor for consideration. = I'll leave it up to the editor to flag any changes that need may need = discussion. =3D- Tim > On Jul 15, 2018, at 2:04 PM, Barry Leiba = wrote: >=20 > So begins Working Group Last Call (WGLC) on = draft-ietf-dmarc-rfc7601bis-02. >=20 > Please review the latest version: > https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/ > .... and send comments to the DMARC working group mailing list by 3 = August. >=20 > If you review it and think it's ready to go and you have no comments, > please post that as well. > --=20 > Barry, DMARC chair From nobody Mon Jul 30 17:20:35 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61652130EFC for ; Mon, 30 Jul 2018 17:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USr74U__KSy8 for ; Mon, 30 Jul 2018 17:20:32 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91093130E11 for ; Mon, 30 Jul 2018 17:20:32 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id n21-v6so24717421oig.3 for ; Mon, 30 Jul 2018 17:20:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zQcWcx8Wnr7VGcsQCLpUXs52X7KlmIzZ+F0DZGKoWs4=; b=d7pEDumVoiDdolLlSe3YyYyNq+UXe74hPRBptrpgXJVbAare0p448ofmwtYRBAwXzZ E5AdDYeBOAW3Ddg3zECV6mC2+kECQeMONV0X6Yza55+WzWwPXPuXHBhJLNrGHHEVBzbT 0yVFKuGbGjcslcx7rWQPqnOUK6DHKfPzK4tap3ldvPsGJp1zeizW0ov2tntb0BihSsn+ lOqZCQ5Dc/ONoXKWuQSlhCu1E/T2oWzLwLhPTALsQRJa9TNdhQzs6uN4FLOrhKVJSeRS 2XIhARmx9V8kKYLQj12CjpBy47q7C/Gml/2m/EYSYpamcEFLa9KByzQESPoygEaVcqn7 8dYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zQcWcx8Wnr7VGcsQCLpUXs52X7KlmIzZ+F0DZGKoWs4=; b=CGIQ5ZNL9JJeV3+qF4LyMoNsIzzfCPQTtYq1VlRxkyKs4WxQv1gazviHdDt+Vkmble GR3mHtGq+o0ZJyM5Tfz/RxQ9NeaUkvGkv8DQAK8fpGxCNv+fRSNnzVEziJGinMPczs5a QUtjcpTfkAGILRtyhzLlP+BS86oBlukyJHUu0KDQ5I4gPTanZ/lqI+GrQdK9U//VgICG nSbsBOv49dGcVpUpkosa4miHQADw/Z5PYTtsBSeAIenS/TZHHaub8HnQd3vSSvITQsBN xROg3l6YDqnTVQCzeYpcUxS+Cm7aGHTFtXv4Cf1d5R5vQSeMggT80eamOsG/79xS3Ydq p/Fw== X-Gm-Message-State: AOUpUlGpLhgxm1JLqxB9BYGEh+BXpKfleFld3h4ODrTDupd2qqVtFLj/ QYrE92BBrZHnfQZqrztz3eLSyxWxipNauZGfrAkL7XIf X-Google-Smtp-Source: AAOMgpeZ1flQcXx/ws15vavASdGMFbKRMTesz1xBDhoZIq78twLyPqG/2NotxDfaxpZcuCKh7HhR+PX6zMMkcvHZ+Ac= X-Received: by 2002:aca:d088:: with SMTP id j8-v6mr20792627oiy.276.1532996431614; Mon, 30 Jul 2018 17:20:31 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:2646:0:0:0:0:0 with HTTP; Mon, 30 Jul 2018 17:20:11 -0700 (PDT) In-Reply-To: <20180730221726.713CE200316625@ary.qy> References: <20180730221726.713CE200316625@ary.qy> From: Seth Blank Date: Mon, 30 Jul 2018 17:20:11 -0700 Message-ID: To: John Levine Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000bfe0d80572408b52" Archived-At: Subject: Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 00:20:34 -0000 --000000000000bfe0d80572408b52 Content-Type: text/plain; charset="UTF-8" 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. 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 all previous ARC Sets), unless the Chain is invalid in which case you only Seal your own ARC Set. We could add a comment about cv=invalid into Experimental Considerations. If not being able to tell the cases apart creates issues, it can absolutely be added once we are considering the standardization of ARC. --000000000000bfe0d80572408b52 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Jul 30, 2018 at 3:17 PM, John Levine <johnl@taugh.com> wro= te:
I think it's fine to sign and hop= e for the best, but how is a
validator supposed to tell the difference?=C2=A0 Perhaps we need something<= br> like cv=3Drestart.

So that's where = this specific thread started if you roll back to the very first message.

The working group considered cv=3Dinvalid last year,= but there was strong consensus was against it. The guidance for Sealing cv= =3Dinvalid Chains somehow made it into this draft applied to all cv=3Dfail = Chains. All Chains should be Sealed in the same fashion (your AS covers the= ARC Set you've added and all previous ARC Sets), unless the Chain is i= nvalid in which case you only Seal your own ARC Set.

We could add a comment about cv=3Dinvalid into Experimental Consideratio= ns. If not being able to tell the cases apart creates issues, it can absolu= tely be added once we are considering the standardization of ARC.
--000000000000bfe0d80572408b52-- From nobody Mon Jul 30 17:42:03 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E990A130DFB for ; Mon, 30 Jul 2018 17:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jV2nb-Ae1K3g for ; Mon, 30 Jul 2018 17:41:58 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAC57130F09 for ; Mon, 30 Jul 2018 17:41:56 -0700 (PDT) Received: (qmail 85417 invoked from network); 31 Jul 2018 00:41:55 -0000 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 31 Jul 2018 00:41:55 -0000 Date: 30 Jul 2018 20:41:54 -0400 Message-ID: From: "John R Levine" To: "Seth Blank" Cc: "John Levine" , "IETF DMARC WG" In-Reply-To: References: <20180730221726.713CE200316625@ary.qy> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 00:42:02 -0000 > 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 all previous ARC Sets), unless the Chain is invalid in which case > you only Seal your own ARC Set. Ah. Perhaps reword 5.1.1 like this: The signature of an AS header field signs a specific canonicalized form of the ARC Set header values, when all of the previous ARC sets are valid. In that case, the ARC set header values are supplied to the hash function in increasing instance order, starting at 1, and include the ARC Set being added at the time of Sealing the message. If any of the existing sets are invalid, the AS header field only signs its own ARC Set. Within an ARC Set, header fields are supplied to the hash function in the following order: 1. ARC-Authentication-Results 2. ARC-Message-Signature 3. ARC-Seal The ARC-Seal is generated in a manner similar to when DKIM-Signatures are added to messages ([RFC6376], section 3.7). In 5.1.2: In the case of a failed Authenticated Received Chain, the header fields included in the signature scope of the AS header field b= value MUST only include the ARC Set headers in the newly created set, as if this newest ARC Set was the only set present. In 5.2, oldest pass is confusing, since it doesn't tell you whether the validation succeeds or not. I would take out steps 5-7 and add something to the INFORMATIONAL at the end like "A validator can check the AMS headers to estimate when in a chain of forwards the message was modified." Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Tue Jul 31 04:09:30 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 033A8130E6F for ; Tue, 31 Jul 2018 04:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffBw6Q31wJZn for ; Tue, 31 Jul 2018 04:09:26 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9BAC130E03 for ; Tue, 31 Jul 2018 04:09:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=gamma; t=1533035363; bh=lg5oTBEhKHk7SlysThxaBlcp6ey7dyZzw7MUGzzlIt8=; l=5539; h=To:References:From:Date:In-Reply-To; b=AUs5xTOW+kL+lSsMPz9dM0KK2rgwkotPQbR/DLrlSeoLfAjWzm7BlWHtjudoonn0v CffWOH31hp4BEGubn+PHZQjbx3UvMkYjRWVtwMZpM7SVNGqpAX7V52G2/75KxlTDq0 oqSlCDdAzP1VrETTei136xeWznRq8+zIKMBz7zUePbcPxLQEo1nXXYawuvh9/ Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Tue, 31 Jul 2018 13:09:22 +0200 id 00000000005DC056.000000005B604362.00000B8E To: "Murray S. Kucherawy" , IETF DMARC WG References: From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: <91473b01-3bee-8e3f-58b0-7f444e58a19d@tana.it> Date: Tue, 31 Jul 2018 13:09:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] WGLC on draft-ietf-dmarc-rfc7601bis-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 11:09:29 -0000 On Mon 30/Jul/2018 07:58:29 +0200 Murray S. Kucherawy wrote: > On Sun, Jul 29, 2018 at 11:23 AM, Alessandro Vesely wrote: > >> *Section 1.2. "Trust Boundary"* >> That section ends with two questionable statements about A-R fields found >> in an attachment:>> >> The details reported by this field cannot be >> trusted in that case. Thus, this field found within one of those >> media types is typically ignored. >> >> How about generic spam complaints and ARF reports of various kinds? Of >> course, trust in the report originator may vary, but I wouldn't say the >> field is typically ignored.> > Do you have a suggestion for alternative text? Say: In that case, if the producer intent is not to harm or mislead, the trust in this field's content would be proportional to the estimated quality of the producer's software. Consumer's wisdom is key. >> *Section 1.6. "Trust Environment"* >> The first paragraph deserves a reference to Section 5 "Removing Existing >> Header Fields".> > I kind of like how the various parts of Section 1 stand alone in terms of > laying out the ground work for what follows. I'll change it if there's > consensus, however. IMHO, that paragraph was fine when the idea was new. Nowadays it sounds somewhat lengthy. Referencing Section 5 might allow to shorten a little bit the text. It's just a question of taste, and since you're the author, it's up to you. >> *special-smtp-verb* >> This rule is redundant and, if we're after readability, can be striked. In >> fact, both terms it produces fall under the "Keyword" rule. In addition, >> IANA reports smtp.rcptto as defined by rfc7293, so it can be omitted here. > > It's not redundant. MAILFROM and RCPTTO are not SMTP verbs. Right, but their formation is well described in the relevant paragraphs, which I quote: The list of commands eligible for use with the "smtp" ptype can be found in Section 4.1 of [SMTP]. [...omitted paragraph here...] Where an SMTP command name is being reported as a "property", the agent generating the header field represents that command by converting it to lowercase and dropping any spaces (e.g., "MAIL FROM" becomes "mailfrom", "RCPT TO" becomes "rcptto", etc.). Please note that a dumb reader might fail to derive that the latter paragraph is constrained by the former. (Perhaps reordering and/or merging might help.) In the ABNF too, the definition of special-smtp-verb doesn't constrain the rule to the lowercase "smtp" ptype. So, since the definitions of "mailfrom" and "rcptto" can be found in their respective RFCs, 7208 and 7293, I fail to see what's the added value of anticipating their definitions here. To wit, you could as well have defined, say: property = special-dkim-tag / special-smtp-verb / Keyword special-dkim-tag = "a" / "b" / "d" / "i" ... Instead, you appropriately defer that until the DKIM section. Just wondering... >> *prospec omission* >> OLD: >> >> The "propspec" may be omitted if, for example, the method was unable >> to extract any properties to do its evaluation yet has a result to >> report. >> >> NEW: >> >> The "propspec" may be omitted if the method was unable to extract or >> unwilling to disclose any properties involved in its evaluation, yet >> has a result to report. > > What's an example? This message is an example. Unless removed, it bears a header field like: Authentication-Results: tana.it; auth=pass (details omitted) It means I was SMTP-authenticated when I posted the message (otherwise it wouldn't have been DKIM-signed.) However, for obvious reasons, I don't want to disclose the userid I authenticated with. >> *policy* >> This ptype can now evolve from catchall to meaningful indicator: >> OLD: >> >> A "ptype" value of "policy" indicates a policy decision about the >> message not specific to a property of the message that could be >> extracted. See Section 2.4 for details. >> >> NEW: >> >> A "ptype" value of "policy" indicates a policy decision about the >> method. Its presence in a "resinfo" indicates that the algorithmic result >> of the method might have been overridden because of an internal criterion. >> Both "property" and "pvalue" concur at hinting what the internal criterion >> was. See Section 2.4 for details. >> >> The above interpretation is based on the example in Section 2.4, The >> "policy" ptype, which reads: >> >> ... dkim=fail policy.dkim-rules=unsigned-subject ... > > I disagree, because I think the existing text still adequately captures > this case; there's been a policy decision made that was unrelated to some > value found in a header field or tag (i.e., it's not a straight "fail"), > but rather some combination of things that violates something the verifying > ADMD wants to enforce. Isn't that exactly the definition of policy? policy: The message was signed, but some aspect of the signature or signatures was not acceptable to the ADMD. >> *Section 2.7. "Defined Methods and Result Values"* >> s/New methods/Methods/ > > Why? It's referring to methods that may come in the future, which I would > consider "new". I thought the methods in Section 2.7.5. "Other Registered Codes" are not, strictly speaking, /specified in this document/. If the ID is meant to be comprehensive —by definition or by reference— of all valid methods existing at the time of publication, then the wording is fine. Best Ale -- From nobody Tue Jul 31 06:10:28 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB226128B14 for ; Tue, 31 Jul 2018 06:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFogA5J1ZULi for ; Tue, 31 Jul 2018 06:10:25 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0A431252B7 for ; Tue, 31 Jul 2018 06:10:24 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id f18-v6so10698135lfc.2 for ; Tue, 31 Jul 2018 06:10:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HBaxH77F1ve7D1uiYbj8r3S+Lkv3NzSh6rg0pgqg08E=; b=GI5WJR3+iHTs3lAoy7tW3CLQ1BPM8ujZulI5hh1RWqZm0hbivNFCWxyPiU58iHsch4 bFEmzuAznEtUcNbAnX2v2jgI9OdbhprLqY2zrGbvW6VIwVQQigOUfPrBr00lTDYNPxzB qB3pl4ysm9Mczf7Eh5JGkreiN+G6EOo5ldwCn6SzDUTxFLoXQTOKQzixEOb2twhii5M3 OP6UwPgZGfL6QyP5E3ACzjkD5cmA5Ilxz1smncn5XVS4v4MLwjza4cqOSdR3W8TVnyB1 CPH0134TKL3HDwBgFwWqsrMWxwFwT3iM2Lp0VIKdwy94P+OZMQX0Uxj5JIL4QF6lNauZ wR5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HBaxH77F1ve7D1uiYbj8r3S+Lkv3NzSh6rg0pgqg08E=; b=HFDl34zsdPfo06UNTs0CS2gQ3ZJE39RgGq3fwjR7MjwXrz0cXvlS6QvP8qiZDJ6EIp nyIjjXn/FDxvygK973NDS6hg1llsQNuSHkjKV9WHkqiT4XC8FGNB1Jt22lPY+hGnrqGQ Zzu226TezZE6JPM9ICKNQHkgFCt5FhFonFJCmsYEDIM8AJjMblR6uA9OMW86VFAxiVSd K4I7enZ9RL+52/x2zFtDnfBe/xtLALu04al75h7vPBgVzSSe6AzaIHvvYnRKUYMdcezZ g0Ko+BjFzpDbyfICg8cigQ+YHVX0otKR9qRjGqCfxBLUwEyT9J3hlK3bw/UfkHUrLJFc iE5A== X-Gm-Message-State: AOUpUlHoaHqx5p2q1PMbFZxxKVztIBB6uTBztAHHZCZJlYj0VTwEjeh/ rPJazOSNlluHnUGh3iyKRfnaxI76epaYGev5oMY= X-Google-Smtp-Source: AAOMgpehkoMXs/sS8Uy4WJuANAp71Ys+1VV/nE+mIQNRrKpiAYAZY4l80p9YoF6aH+HkVnhU0wY2w+V0Wy7zI3xCU2Y= X-Received: by 2002:a19:dd5c:: with SMTP id u89-v6mr12803156lfg.83.1533042622824; Tue, 31 Jul 2018 06:10:22 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:3a13:0:0:0:0:0 with HTTP; Tue, 31 Jul 2018 06:10:21 -0700 (PDT) In-Reply-To: <91473b01-3bee-8e3f-58b0-7f444e58a19d@tana.it> References: <91473b01-3bee-8e3f-58b0-7f444e58a19d@tana.it> From: "Murray S. Kucherawy" Date: Tue, 31 Jul 2018 06:10:21 -0700 Message-ID: To: Alessandro Vesely Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000f5866b05724b4c4a" Archived-At: Subject: Re: [dmarc-ietf] WGLC on draft-ietf-dmarc-rfc7601bis-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 13:10:27 -0000 --000000000000f5866b05724b4c4a Content-Type: text/plain; charset="UTF-8" On Tue, Jul 31, 2018 at 4:09 AM, Alessandro Vesely wrote: > > Do you have a suggestion for alternative text? > > Say: > > In that case, if the producer intent is not to harm or mislead, the > trust > in this field's content would be proportional to the estimated quality > of > the producer's software. Consumer's wisdom is key. > How is a receiver to know anything about the estimated quality of the producer's software? >> *special-smtp-verb* > >> This rule is redundant and, if we're after readability, can be > striked. In > >> fact, both terms it produces fall under the "Keyword" rule. In > addition, > >> IANA reports smtp.rcptto as defined by rfc7293, so it can be omitted > here. > > > > It's not redundant. MAILFROM and RCPTTO are not SMTP verbs. > > Right, but their formation is well described in the relevant paragraphs, > which > I quote: > > The list of commands eligible for use with the "smtp" ptype can be > found in Section 4.1 of [SMTP]. > > [...omitted paragraph here...] > > Where an SMTP command name is being reported as a "property", the > agent generating the header field represents that command by > converting it to lowercase and dropping any spaces (e.g., "MAIL FROM" > becomes "mailfrom", "RCPT TO" becomes "rcptto", etc.). > > Please note that a dumb reader might fail to derive that the latter > paragraph > is constrained by the former. (Perhaps reordering and/or merging might > help.) > I'm not clear on how ordering helps here. You need the two together regardless of order. I'm also not clear on what problem you're trying to solve. Keep in mind that this is now something like the fourth version of this document, and this has not been identified as a deficiency in any prior version. Is this actually broken? >> *prospec omission* > >> OLD: > >> > >> The "propspec" may be omitted if, for example, the method was unable > >> to extract any properties to do its evaluation yet has a result to > >> report. > >> > >> NEW: > >> > >> The "propspec" may be omitted if the method was unable to extract or > >> unwilling to disclose any properties involved in its evaluation, yet > >> has a result to report. > > > > What's an example? > > This message is an example. Unless removed, it bears a header field like: > > Authentication-Results: tana.it; auth=pass (details omitted) > > It means I was SMTP-authenticated when I posted the message (otherwise it > wouldn't have been DKIM-signed.) However, for obvious reasons, I don't > want to > disclose the userid I authenticated with. > I think that's operationally a poor choice. The whole point of the data that come after the pass/fail is to tell downstream agents what identifier(s) might be of interest to record or highlight to users. If you managed to authenticate as the identity in the From: field, that's a lot more interesting than if you authenticated as something unrelated; the fact that the filter adding this left out that key piece of information almost makes it useless. But since the syntax (unfortunately) allows it, the proposed text change is reasonable. >> *policy* > >> This ptype can now evolve from catchall to meaningful indicator: > >> OLD: > >> > >> A "ptype" value of "policy" indicates a policy decision about the > >> message not specific to a property of the message that could be > >> extracted. See Section 2.4 for details. > >> > >> NEW: > >> > >> A "ptype" value of "policy" indicates a policy decision about the > >> method. Its presence in a "resinfo" indicates that the algorithmic > result > >> of the method might have been overridden because of an internal > criterion. > >> Both "property" and "pvalue" concur at hinting what the internal > criterion > >> was. See Section 2.4 for details. > >> > >> The above interpretation is based on the example in Section 2.4, The > >> "policy" ptype, which reads: > >> > >> ... dkim=fail policy.dkim-rules=unsigned-subject ... > > > > I disagree, because I think the existing text still adequately captures > > this case; there's been a policy decision made that was unrelated to some > > value found in a header field or tag (i.e., it's not a straight "fail"), > > but rather some combination of things that violates something the > verifying > > ADMD wants to enforce. > > Isn't that exactly the definition of policy? > > policy: The message was signed, but some aspect of the signature or > signatures was not acceptable to the ADMD. > Yes, so is there a need to restate all of that here? That's all laid out in Section 2.4. -MSK --000000000000f5866b05724b4c4a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 31, 2018 at 4:09 AM, Alessandro Vesely <vesely@t= ana.it> wrote:
> Do you have= a suggestion for alternative text?

Say:

=C2=A0 =C2=A0 In that case, if the producer intent is not to harm or mislea= d, the trust
=C2=A0 =C2=A0 in this field's content would be proportional to the esti= mated quality of
=C2=A0 =C2=A0 the producer's software.=C2=A0 Consumer's wisdom is k= ey.

How is a receiver to know anything = about the estimated quality of the producer's software?

=
>> *special-smtp-verb*
>> This rule is redundant and, if we're after readability, can be= striked.=C2=A0 In
>> fact, both terms it produces fall under the "Keyword" ru= le.=C2=A0 In addition,
>> IANA reports smtp.rcptto as defined by rfc7293, so it can be omitt= ed here.
>
> It's not redundant.=C2=A0 MAILFROM and RCPTTO are not SMTP verbs.<= br>
Right, but their formation is well described in the relevant paragra= phs, which
I quote:

=C2=A0 =C2=A0The list of commands eligible for use with the "smtp"= ; ptype can be
=C2=A0 =C2=A0found in Section 4.1 of [SMTP].

=C2=A0 =C2=A0[...omitted paragraph here...]

=C2=A0 =C2=A0Where an SMTP command name is being reported as a "proper= ty", the
=C2=A0 =C2=A0agent generating the header field represents that command by =C2=A0 =C2=A0converting it to lowercase and dropping any spaces (e.g., &quo= t;MAIL FROM"
=C2=A0 =C2=A0becomes "mailfrom", "RCPT TO" becomes &quo= t;rcptto", etc.).

Please note that a dumb reader might fail to derive that the latter paragra= ph
is constrained by the former.=C2=A0 (Perhaps reordering and/or merging migh= t help.)

I'm not clear on how order= ing helps here.=C2=A0 You need the two together regardless of order.
<= div>
I'm also not clear on what problem you're trying= to solve.=C2=A0 Keep in mind that this is now something like the fourth ve= rsion of this document, and this has not been identified as a deficiency in= any prior version.=C2=A0 Is this actually broken?

=
>> *prospec omission*=
>> OLD:
>>
>>=C2=A0 =C2=A0 The "propspec" may be omitted if, for examp= le, the method was unable
>>=C2=A0 =C2=A0 to extract any properties to do its evaluation yet ha= s a result to
>>=C2=A0 =C2=A0 report.
>>
>> NEW:
>>
>>=C2=A0 =C2=A0 The "propspec" may be omitted if the method= was unable to extract or
>>=C2=A0 =C2=A0 unwilling to disclose any properties involved in its = evaluation, yet
>>=C2=A0 =C2=A0 has a result to report.
>
> What's an example?

This message is an example.=C2=A0 Unless removed, it bears a header = field like:

=C2=A0 =C2=A0 Authentication-Results: tana.it; auth=3Dpass (details omitted)

It means I was SMTP-authenticated when I posted the message (otherwise it wouldn't have been DKIM-signed.)=C2=A0 However, for obvious reasons, I = don't want to
disclose the userid I authenticated with.

I think that's operationally a poor choice.=C2=A0 The whole point of= the data that come after the pass/fail is to tell downstream agents what i= dentifier(s) might be of interest to record or highlight to users.=C2=A0 If= you managed to authenticate as the identity in the From: field, that's= a lot more interesting than if you authenticated as something unrelated; t= he fact that the filter adding this left out that key piece of information = almost makes it useless.

But since the syntax (unf= ortunately) allows it, the proposed text change is reasonable.
>> *policy*
>> This ptype can now evolve from catchall to meaningful indicator: >> OLD:
>>
>>=C2=A0 =C2=A0 A "ptype" value of "policy" indic= ates a policy decision about the
>>=C2=A0 =C2=A0 message not specific to a property of the message tha= t could be
>>=C2=A0 =C2=A0 extracted.=C2=A0 See Section 2.4 for details.
>>
>> NEW:
>>
>>=C2=A0 =C2=A0 A "ptype" value of "policy" indic= ates a policy decision about the
>>=C2=A0 =C2=A0 method.=C2=A0 Its presence in a "resinfo" i= ndicates that the algorithmic result
>>=C2=A0 =C2=A0 of the method might have been overridden because of a= n internal criterion.
>>=C2=A0 =C2=A0 Both "property" and "pvalue" conc= ur at hinting what the internal criterion
>>=C2=A0 =C2=A0 was.=C2=A0 See Section 2.4 for details.
>>
>> The above interpretation is based on the example in Section 2.4, T= he
>> "policy" ptype, which reads:
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0... dkim=3Dfail policy.dkim-rules=3Dunsi= gned-subject ...
>
> I disagree, because I think the existing text still adequately capture= s
> this case; there's been a policy decision made that was unrelated = to some
> value found in a header field or tag (i.e., it's not a straight &q= uot;fail"),
> but rather some combination of things that violates something the veri= fying
> ADMD wants to enforce.

Isn't that exactly the definition of policy?

=C2=A0 =C2=A0policy:=C2=A0 The message was signed, but some aspect of the s= ignature or
=C2=A0 =C2=A0 =C2=A0 signatures was not acceptable to the ADMD.

Yes, so is there a need to restate all of that her= e?=C2=A0 That's all laid out in Section 2.4.

-MSK
<= /div> --000000000000f5866b05724b4c4a-- From nobody Tue Jul 31 12:47:26 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE80130E5F for ; Tue, 31 Jul 2018 12:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQadtoxb40DB for ; Tue, 31 Jul 2018 12:47:22 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B630130DF7 for ; Tue, 31 Jul 2018 12:47:22 -0700 (PDT) Received: (qmail 62858 invoked from network); 31 Jul 2018 19:47:21 -0000 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 31 Jul 2018 19:47:21 -0000 Date: 31 Jul 2018 15:47:20 -0400 Message-ID: From: "John R Levine" To: "IETF DMARC WG" User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [dmarc-ietf] ARC-16 and EAI messages X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 19:47:24 -0000 I was updating my EAI-izing draft for DKIM and DMARC and realized that it would be nice not to have to update ARC, too. The gist of it is the same as what I said for DKIM: anywhere there's a domain name there can be an IDN written with U-labels (Unicode), and anywhere there's user text, the text can be UTF-8. The easiest thing for me would be for us to give draft-levine-appsarea-eaiauth a nudge so where it says ARC imports ABNF from RFC6376, it instead says it imports from RFC6376 as updated by draft-levine-appsarea-eaiauth. The concrete changes are that in the AS header, the d= s= tags can be IDNs, and in the AMS header, the d= s= tags can be IDNs, i= can have unicode local-part and IDN domain, and throughout dkim-safe-char is updated so that non-ASCII characters don't have to be quoted. I assume 7601bis will be done so AAR can inherit from there. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Tue Jul 31 13:01:40 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE22A130DD0 for ; Tue, 31 Jul 2018 13:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuZQlioV9uzg for ; Tue, 31 Jul 2018 13:01:35 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4607B130E5F for ; Tue, 31 Jul 2018 13:01:34 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id h4-v6so17362630qtj.7 for ; Tue, 31 Jul 2018 13:01:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Ae582OQm1s3ORNctJz0YFzAQhAbhGTaGroDTQguN2as=; b=Y/hasg+5a2OXTJppAO2So5GfO2Z1HyZuxghoswQKSpM9j/3U/6rt8dT/+W/ZtKLJd+ yB9Kg/q9aRuXfpxSOA+/UiN480AWNLLMxyvsefwCK5GKCEZLgZVX+4C06wfmrghdi6Up NEeqVA9mVcB2fACK54ZzQ9FbUzbaskH4QZJJiGjeJiEews48e5gdUGpPGbarnt5MFN6h gZY+pe+SiEyWyBzXbPMN4XJfYJ9VCWrTUEPV6kvu1alybRGFaTTthfLndLaVr+eU1OYU 5IMX02DQMFgIp613/GncmTSmmRMbzxdavoFGK8oVw1WWFCDVHx3DbKZ3MFhP3yQWgJRz 2MjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=Ae582OQm1s3ORNctJz0YFzAQhAbhGTaGroDTQguN2as=; b=fvL0csn6vuN4dWh+otOEPZV+1EBBuOO2nKob1joSffgrB4cOXsgpBt3ZP70JDgNZQV 1OyF2XAd+RPjU05isxxUV+wL01Exeymk0atViFr621hHpbCPkW8skMLfy40CMyMBGk/O awgbDaNP5RdF+wxDMk9ryQebpSHq47TY8DhUrZd3Rjzoy5U00Ezv4+c9tLKYPVxxzEEq sCfh0Rg7QkzJv0wWgTVC2Azr3OTUn6TtIAxNok+/7Xbuf0v11an/KdONqWFR62NU+NKF G3NadaPQZqY5NlqXH3XD5HNTSMznTbwT2OLt08mAjX/+OvDhXqTxbUji5Op6GQrs5dfB dPkw== X-Gm-Message-State: AOUpUlH8jjskUIH1PWp9d1taolbF33FmGjohib7jVDZl7dsuMpSqAzZu iPjiLTTzG4QFqx/l7v26+Bh2DzFb4M9/tGDffnPQdG8ShxU= X-Google-Smtp-Source: AAOMgpeuqDDT0xZ35flHL04ppMsVBZ59u8xI09Wgd11lRhz4UOM4BK+Id6XdoA8w2BViK8Wn9IPlWN2u+vvx+MuSRWE= X-Received: by 2002:a0c:98c1:: with SMTP id g1-v6mr20470549qvd.27.1533067293695; Tue, 31 Jul 2018 13:01:33 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:22e1:0:0:0:0:0 with HTTP; Tue, 31 Jul 2018 13:01:13 -0700 (PDT) In-Reply-To: References: From: Seth Blank Date: Tue, 31 Jul 2018 13:01:13 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000007532d00572510b0b" Archived-At: Subject: Re: [dmarc-ietf] ARC-16 and EAI messages X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 20:01:39 -0000 --0000000000007532d00572510b0b Content-Type: text/plain; charset="UTF-8" I agree ARC should be EAI-ized. To be clear, are you saying that once 7601bis and draft-levine-appsarea-eaiauth are approved by the IESG and properly update 7601 and 6376, then no direct changes are needed to the ARC spec? So the only wording consideration under WGLC is the ABNF import with respect to DKIM and draft-levine-appsarea-eaiauth? Seth On Tue, Jul 31, 2018 at 12:47 PM, John R Levine wrote: > I was updating my EAI-izing draft for DKIM and DMARC and realized that it > would be nice not to have to update ARC, too. > > The gist of it is the same as what I said for DKIM: anywhere there's a > domain name there can be an IDN written with U-labels (Unicode), and > anywhere there's user text, the text can be UTF-8. > > The easiest thing for me would be for us to give > draft-levine-appsarea-eaiauth a nudge so where it says ARC imports ABNF > from RFC6376, it instead says it imports from RFC6376 as updated by > draft-levine-appsarea-eaiauth. > > The concrete changes are that in the AS header, the d= s= tags can be > IDNs, and in the AMS header, the d= s= tags can be IDNs, i= can have > unicode local-part and IDN domain, and throughout dkim-safe-char is updated > so that non-ASCII characters don't have to be quoted. I assume 7601bis > will be done so AAR can inherit from there. > > Regards, > John Levine, johnl@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/listinfo/dmarc > -- Seth Blank | Director of Industry Initiatives E: seth@valimail.com | P: 415.273.8818 --0000000000007532d00572510b0b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree ARC should be EAI-ized.
=
To be clear, are you saying that once = 7601bis and=C2=A0draft-levine-appsarea-eaiauth are approved by the IESG a= nd properly update 7601 and 6376, then no direct changes are needed to the = ARC spec?

So the only wording consideration under WGLC is the A= BNF import with respect to DKIM and draft-levine= -appsarea-eaiauth?

Seth
=
On Tue, Jul 31, 2018 at 12:47 PM, John R Lev= ine <johnl@taugh.com> wrote:
I was updating my EAI-izing draft for DKIM and DMARC and realized that it = would be nice not to have to update ARC, too.

The gist of it is the same as what I said for DKIM: anywhere there's a = domain name there can be an IDN written with U-labels (Unicode), and anywhe= re there's user text, the text can be UTF-8.

The easiest thing for me would be for us to give draft-levine-appsarea-eaia= uth a nudge so where it says ARC imports ABNF from RFC6376, it instead says= it imports from RFC6376 as updated by draft-levine-appsarea-eaiauth.

The concrete changes are that in the AS header, the d=3D s=3D tags can be I= DNs, and in the AMS header, the d=3D s=3D tags can be IDNs, i=3D can have u= nicode local-part and IDN domain, and throughout dkim-safe-char is updated = so that non-ASCII characters don't have to be quoted.=C2=A0 I assume 76= 01bis will be done so AAR can inherit from there.

Regards,
John Levine, johnl@tau= gh.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/listinfo/dmarc



--

Seth Blank | Director = of Industry Initiatives

E: seth@valimail.com | P: 415.273.8818


<= /div>
--0000000000007532d00572510b0b-- From nobody Tue Jul 31 13:48:30 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD872130DF7 for ; Tue, 31 Jul 2018 13:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLJh04k9ltiH for ; Tue, 31 Jul 2018 13:48:27 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE956130DD3 for ; Tue, 31 Jul 2018 13:48:26 -0700 (PDT) Received: (qmail 95047 invoked from network); 31 Jul 2018 20:48:24 -0000 Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 31 Jul 2018 20:48:24 -0000 Received: by ary.qy (Postfix, from userid 501) id 7A19420031B24A; Tue, 31 Jul 2018 16:48:24 -0400 (EDT) Date: 31 Jul 2018 16:48:24 -0400 Message-Id: <20180731204824.7A19420031B24A@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: seth@valimail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] ARC-16 and EAI messages X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 20:48:29 -0000 In article you write: >-=-=-=-=-=- > >I agree ARC should be EAI-ized. > >To be clear, are you saying that once 7601bis and draft-levine-appsarea-eaiauth >are approved by the IESG and properly update 7601 and 6376, then no direct >changes are needed to the ARC spec? > >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. R's, John >On Tue, Jul 31, 2018 at 12:47 PM, John R Levine wrote: > >> I was updating my EAI-izing draft for DKIM and DMARC and realized that it >> would be nice not to have to update ARC, too. >> >> The gist of it is the same as what I said for DKIM: anywhere there's a >> domain name there can be an IDN written with U-labels (Unicode), and >> anywhere there's user text, the text can be UTF-8. >> >> The easiest thing for me would be for us to give >> draft-levine-appsarea-eaiauth a nudge so where it says ARC imports ABNF >> from RFC6376, it instead says it imports from RFC6376 as updated by >> draft-levine-appsarea-eaiauth. >> >> The concrete changes are that in the AS header, the d= s= tags can be >> IDNs, and in the AMS header, the d= s= tags can be IDNs, i= can have >> unicode local-part and IDN domain, and throughout dkim-safe-char is updated >> so that non-ASCII characters don't have to be quoted. I assume 7601bis >> will be done so AAR can inherit from there. From nobody Tue Jul 31 13:52:55 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D4F130E0C for ; Tue, 31 Jul 2018 13:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SruRa7eqFIcO for ; Tue, 31 Jul 2018 13:52:51 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8ACD130DF7 for ; Tue, 31 Jul 2018 13:52:50 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id y207-v6so30541414oie.13 for ; Tue, 31 Jul 2018 13:52:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=W4MZThVtL12LgB/6VWosCKR1R+ujRlecs6+meu7oPOk=; b=HmJQ+1DcCDCi13D1mVXsH4pUTCvV4T6DV4NLGS+AG+S7ESHW7DsuSmnb28uymUAWAt OGrM1jpYilbwfgVRpwm8uq36tAqGlubP5IFuT5+yXtznFq5UeyYxedlWkPwngwhwtEd1 nssyZ3ClJViv/WE7zsVll250QUgmfzTsZJ2RKhd7lS7FopNKZJvm1axLO3Df/ylIMinv RI/zVDfS9yhBUuUFkiWOXZDA9LLJKH8wjrTo4MUB+YS5NuZOmqZlX8g+Eb9sfyG2Pn6l 4QowBUTnEiv806ObS3c/awYZY93BrfBgFbYiGw/kmlcgGmVJNJb2GFeaggkLob0ZVjBj E2vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=W4MZThVtL12LgB/6VWosCKR1R+ujRlecs6+meu7oPOk=; b=nXM5RBfBVM9lrP72alvCkru1xPp9y03Vc4gnnG3Nl7LjToh9jT2u0i9S5nvLGskimC OYovQPVmTuid3e11hUUcL0e2ShFs8n1A/X2s/8EdphGIbDC5KStJ1x5gEtvIRz2mdyGV rSfGl6m/Zx7LLDmpNbbyK7tC+kDYsrwNakDdljPTGxBDTigMSP9U1+73A2yxuhp/KP0f noyFzru8QWd1ttFD30oCybOc53pqXz7KJcLjk0kjF2w1QYSLH5W4/SInfOuwyAXjOTmc DmrxigS5c07NesJbzD++NkMP9tP0rxI6JxE7Npi0dTPtBJ0inP0zdaRjvbCzn1fA9WRt 2E0A== X-Gm-Message-State: AOUpUlFuzGUcE7Jj+6BE1KCch92E2e6Ib+DEA3wC04eADZG+MI9X7TIr nePLtlMKbDE5zcCcPIPAU5bD/t93/Po= X-Google-Smtp-Source: AAOMgpebGy/An75sE5/5njhtkO8zdejOPkhTwd4x9w9K/Hkct+xc+AecUrMK7vBmAJEB8OCg4XWHAg== X-Received: by 2002:aca:ddd4:: with SMTP id u203-v6mr635845oig.204.1533070369818; Tue, 31 Jul 2018 13:52:49 -0700 (PDT) Received: from mail-oi0-f42.google.com (mail-oi0-f42.google.com. [209.85.218.42]) by smtp.gmail.com with ESMTPSA id v5-v6sm10169645oix.36.2018.07.31.13.52.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Jul 2018 13:52:49 -0700 (PDT) Received: by mail-oi0-f42.google.com with SMTP id k12-v6so30547535oiw.8 for ; Tue, 31 Jul 2018 13:52:49 -0700 (PDT) X-Received: by 2002:aca:d088:: with SMTP id j8-v6mr577971oiy.276.1533070369155; Tue, 31 Jul 2018 13:52:49 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:2646:0:0:0:0:0 with HTTP; Tue, 31 Jul 2018 13:52:28 -0700 (PDT) In-Reply-To: <20180731204824.7A19420031B24A@ary.qy> References: <20180731204824.7A19420031B24A@ary.qy> From: Seth Blank Date: Tue, 31 Jul 2018 13:52:28 -0700 X-Gmail-Original-Message-ID: Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000c50983057251c216" Archived-At: Subject: Re: [dmarc-ietf] ARC-16 and EAI messages X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 20:52:54 -0000 --000000000000c50983057251c216 Content-Type: text/plain; charset="UTF-8" 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 appropriate place for this guidance is likely a second paragraph in 4.1 (https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-16#section-4.1), as this guidance will apply to the three following header fields. Would you mind suggesting a paragraph to add in this context? --000000000000c50983057251c216 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 31, 2018 at 1:48 PM, John Levine <johnl@taugh.com> wro= te:
>So the only wording consideration under WGLC is the ABNF import wi= th
>respect to DKIM and draft-levine-appsarea-eaiauth?

Yes, although it's probably worth reminding people where things = are
different in EAI messages.

=

Would you mind suggesting a paragraph to add in this co= ntext?=C2=A0
--000000000000c50983057251c216-- From nobody Tue Jul 31 14:28:10 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6FD126CC7 for ; Tue, 31 Jul 2018 14:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ny51bTWcy51A for ; Tue, 31 Jul 2018 14:28:03 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 695FF130E29 for ; Tue, 31 Jul 2018 14:27:58 -0700 (PDT) Received: (qmail 14450 invoked from network); 31 Jul 2018 21:27:57 -0000 Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 31 Jul 2018 21:27:56 -0000 Received: by ary.qy (Postfix, from userid 501) id CAD1720031B8DC; Tue, 31 Jul 2018 17:27:56 -0400 (EDT) Date: 31 Jul 2018 17:27:56 -0400 Message-Id: <20180731212756.CAD1720031B8DC@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: seth@valimail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] ARC-16 and EAI messages X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 21:28:08 -0000 In article you write: >The appropriate place for this guidance is likely a second paragraph in 4.1 >(https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-16#section-4.1), >as this guidance will apply to the three following header fields. > >Would you mind suggesting a paragraph to add in this context? 4.1.4 Internationalized mail In internationalized messages (RFC 6532) many header fields can contain UTF-8 as well as ASCII text. The changes for EAI are all inherited from DKIM as updated by [draft-levine-eaiauth] and Authentication-Restukts as updated in [rfc7601bis], but are called out here for emphasis. in an AS header, the d= s= tags can be contain U-labels. In an AMS header, the d= s= tags can contain U-labels, i= can have UTF-8 in the local-part and U-labels in the domain, and in all tags, non-ASCII characters need not be quoted in dkim-quoted-printable. The AAR header allows UTF-8 in the same places that A-R does, as described in [7601bis]. From nobody Tue Jul 31 14:39:02 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A840A130E85 for ; Tue, 31 Jul 2018 14:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cU3s5SRNKoe4 for ; Tue, 31 Jul 2018 14:38:55 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 800FF130E0C for ; Tue, 31 Jul 2018 14:38:55 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id j205-v6so915660oib.4 for ; Tue, 31 Jul 2018 14:38:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=1A1gZtvjAOxJ45IFXLgLGR9yV/K09HqyIzKjKF7Px+A=; b=RaObrbEQs06EYuGe16I3kODlZCVlrHH9du0nc0GpuibfBrPLh5OCVUusnzgm7py5es g0pKFbiXVnq3sD514ojRV5GznPnmZvsL0XEcKX3O9nGcudkhiLjsncHg+SC4QXKdlzZY SlpQXRUmwGbtQ7PLTOcvIqWWKe2h4SM70Dm3CK6qRE6njaEo5sKk1oHqUbxOcUzKSWfV Fgyjynuc1yP0eQMsZoJgkbMYhDneigH4bkGWtYpsC2saqlbpdB77PQu46r3e9L4CFb67 I8jM6G3oMKiUvNzbZpvrE+rlfU7FlMPeii7vFz1HEMZXSlSGqJfsCT+PBbGzdMIDWbmu xoXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=1A1gZtvjAOxJ45IFXLgLGR9yV/K09HqyIzKjKF7Px+A=; b=RIZItFIesQjrqcdlNRZxr6BVTg7dNPenQQzFLxXWVgZ4zOb5YzEaLCYCq4BY/8vkUN /CcpeImyE4Xs9EtIs9VBXPnoEDSTFzIl8DV4taC13mELj8RDUUJqRz5+eJaGGPHPKOfm e6UmP0Rc9HEmTS1QJUT++yJVLNarJA44Hf8aTvBvKPSDedeUoZZF/qDCQhL4f/VGgVU7 11fA3A5WDkDyjaZNWUOvyt/XRfps9TKmfnfKngZZvxSCgdoHlBQ2UQq8wRW/7D8wvQHd Ca76P3wCuJKvXAQjeUVPyCbCLc1ESEkt6gy8WbVKVUd8agh0c8oWO4lKD4BqcedXPTIh d6oA== X-Gm-Message-State: AOUpUlFukqNCL/DJ9SYA93/0DJhPLhyRHUTyf+esm0eTlmpExB3HS2aq c275a3xE+ifF1Knl5uZmDeAGQ4xQvWaD8A== X-Google-Smtp-Source: AAOMgpeIx6xkuc/1NYaUI7GWarKo6eR5MqIfAtYiUuHzG0QLAo5TXrHA5/60/UGrftZV2XJmQBs7ZQ== X-Received: by 2002:aca:c70f:: with SMTP id x15-v6mr756233oif.97.1533073134392; Tue, 31 Jul 2018 14:38:54 -0700 (PDT) Received: from mail-oi0-f43.google.com (mail-oi0-f43.google.com. [209.85.218.43]) by smtp.gmail.com with ESMTPSA id w84-v6sm10823765oie.40.2018.07.31.14.38.53 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Jul 2018 14:38:53 -0700 (PDT) Received: by mail-oi0-f43.google.com with SMTP id n21-v6so30779809oig.3 for ; Tue, 31 Jul 2018 14:38:53 -0700 (PDT) X-Received: by 2002:aca:cf0e:: with SMTP id f14-v6mr794556oig.356.1533073133745; Tue, 31 Jul 2018 14:38:53 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:2646:0:0:0:0:0 with HTTP; Tue, 31 Jul 2018 14:38:33 -0700 (PDT) In-Reply-To: <20180731212756.CAD1720031B8DC@ary.qy> References: <20180731212756.CAD1720031B8DC@ary.qy> From: Seth Blank Date: Tue, 31 Jul 2018 14:38:33 -0700 X-Gmail-Original-Message-ID: Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000008d524805725267f8" Archived-At: Subject: Re: [dmarc-ietf] ARC-16 and EAI messages X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 21:39:01 -0000 --0000000000008d524805725267f8 Content-Type: text/plain; charset="UTF-8" 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 for Email Address Internationalization (EAI) are all inherited from DKIM as updated by [draft-levine-eaiauth] and Authentication-Results as updated in [rfc7601bis], but are called out here for emphasis. In the AMS and AS header fields, the d= and s= tags can contain U-labels, and in all tags, non-ASCII characters need not be quoted in dkim-quoted-printable. The AAR header allows UTF-8 in the same places that A-R does, as described in [7601bis]. --0000000000008d524805725267f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I= 9;ve added the following text as Section 4.1.4 (note fixed typos and remova= l of the i=3D section, which is removed from ARC explicitly):

4.1.4:=C2=A0 Intern= ationalized mail considerations

<= div class=3D"gmail_quote">
In internationalized m= essages [RFC 6532] many header fields can contain UTF-8 as well as ASCII te= xt.=C2=A0 The changes for Email Address Internationalization (EAI) are all = inherited from DKIM as updated by [draft-levine-eaiauth] and Authentication= -Results as updated in [rfc7601bis], but are called out here for emphasis.<= /div>

In the= AMS and AS header fields, the d=3D and s=3D tags can contain U-labels, and= in all tags, non-ASCII
characters need not= be quoted in dkim-quoted-printable.=C2=A0=C2=A0

The AAR header allows UTF-8 in t= he same places that A-R does, as described in [7601bis].
<= /div> --0000000000008d524805725267f8-- From nobody Tue Jul 31 15:13:47 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB28130E72 for ; Tue, 31 Jul 2018 15:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZVTJ-U99kXf for ; Tue, 31 Jul 2018 15:13:41 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55EA0130DC3 for ; Tue, 31 Jul 2018 15:13:41 -0700 (PDT) Received: (qmail 36162 invoked from network); 31 Jul 2018 22:13:39 -0000 Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 31 Jul 2018 22:13:39 -0000 Received: by ary.qy (Postfix, from userid 501) id 9E57820031BB6D; Tue, 31 Jul 2018 18:13:39 -0400 (EDT) Date: 31 Jul 2018 18:13:39 -0400 Message-Id: <20180731221339.9E57820031BB6D@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: seth@valimail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] ARC-16 and EAI messages X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 22:13:43 -0000 In article you write: >-=-=-=-=-=- > >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): 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." R's, John >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 for Email Address >Internationalization (EAI) are all inherited from DKIM as updated by >[draft-levine-eaiauth] and Authentication-Results as updated in >[rfc7601bis], but are called out here for emphasis. > >In the AMS and AS header fields, the d= and s= tags can contain U-labels, >and in all tags, non-ASCII >characters need not be quoted in dkim-quoted-printable. > >The AAR header allows UTF-8 in the same places that A-R does, as described >in [7601bis]. From nobody Tue Jul 31 15:19:43 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 867E1130E8A for ; Tue, 31 Jul 2018 15:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEev8tJTOYXC for ; Tue, 31 Jul 2018 15:19:38 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3F90126DBF for ; Tue, 31 Jul 2018 15:19:37 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id q11-v6so30924334oic.12 for ; Tue, 31 Jul 2018 15:19:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qnowdcUWOsbxe6NkgyGBKND0WPHbR0QPfbLSwJrGH34=; b=Ki3JyFnl0sGvx6xxb0s7YhfkcUrF0Z3+iyVb7fo1Apb8EEz69nFVQsnizqQnqGJNwT IAkkDg+glm916OMu6dAAlU5b0GslzeOat0D6zvls+CjXSn2ei24UQcdnJREk4pvU/F9S 2z02TDGYM9W0i6HA/Rohk0eKiAZ2ZfXhLwhlI9jOYhRG9NlQkSyeCBnsoSEfOjJ36pkN 847MlxbU1XNTjhSco5b9NORe6ZKGzACUKa9mxJQkwkESU6iv/UoxI2UbYw0xMrp4z0GO 3bSI4RmXu4BaQ4GzQhqgzhsKtf7TU+KqszPeSWs4/AtZ3e8yeUJIH2/j/+eZjcwaz/AY b6tA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qnowdcUWOsbxe6NkgyGBKND0WPHbR0QPfbLSwJrGH34=; b=Y3t/rIkgZS4sZfStdfEYlfkz/6rDndc7UbjpHXNehiIR58RcrK6hirCjAMm10np1OI QkitwsP1G05dOUpz7k5jys8feB1AYeOXkO043rZHCgBoZB9jf/dou1EQHnRX8CGSzvgm sxFhp9Ui+wZ72UwhRx6wR3tGbYWHIwyATfnRNKqjuOmWOqv8NFkkp0J2gtT0+Zb4saXw DcAsIr8xqJSpxt9IX22SGAbjWE2+BaVdQILtBxTBdedfp3JZurNTQEIImtosFPmS3yeB 81ZldwMOItusAFV7tntnRKsUtbiqeuVN1MZOCBM/7jy4Tuo0O1rjv8WUnKi+BSgC6ZW+ 3xAA== X-Gm-Message-State: AOUpUlG1/CKSJFEcsRKMu2n2+saGe27oaIUk5Ghjpa2wpXwpIdAbPpfT g+wlA596JXeY/mZCmfQpnN7fvdxAJ6I= X-Google-Smtp-Source: AAOMgpfZooLC/Vnl6qT45PjDEEEBlboIBaQaQKJF97uxX4RSC/gkSGlLm1X3RCv7q5I313rY2PM3Ng== X-Received: by 2002:aca:4d87:: with SMTP id a129-v6mr951634oib.256.1533075576910; Tue, 31 Jul 2018 15:19:36 -0700 (PDT) Received: from mail-oi0-f50.google.com (mail-oi0-f50.google.com. [209.85.218.50]) by smtp.gmail.com with ESMTPSA id x5-v6sm11855766oix.3.2018.07.31.15.19.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Jul 2018 15:19:35 -0700 (PDT) Received: by mail-oi0-f50.google.com with SMTP id k12-v6so30942248oiw.8 for ; Tue, 31 Jul 2018 15:19:35 -0700 (PDT) X-Received: by 2002:aca:cdc2:: with SMTP id d185-v6mr935169oig.350.1533075575493; Tue, 31 Jul 2018 15:19:35 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:2646:0:0:0:0:0 with HTTP; Tue, 31 Jul 2018 15:19:14 -0700 (PDT) In-Reply-To: <20180731221339.9E57820031BB6D@ary.qy> References: <20180731221339.9E57820031BB6D@ary.qy> From: Seth Blank Date: Tue, 31 Jul 2018 15:19:14 -0700 X-Gmail-Original-Message-ID: Message-ID: To: John Levine Cc: IETF DMARC WG , Seth Blank Content-Type: multipart/alternative; boundary="000000000000177062057252f9dd" Archived-At: Subject: Re: [dmarc-ietf] ARC-16 and EAI messages X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 22:19:42 -0000 --000000000000177062057252f9dd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=3D 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 =E2=80=9Cinstance tag=E2=80=9D. Additional informatio= n on the =E2=80=9Cinstance tag=E2=80=9D can be found in Section 4.2.1. The instance = tag replaces the DKIM =E2=80=9CAUID=E2=80=9D tag; This language could probably be cleaned up to say "the 'i' (AUID) tag is not imported from DKIM. Instead, it is replaced by the "instance tag" as defined in Section 4.2.1" Then section 4.1.3 should use the identical language as well. --000000000000177062057252f9dd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 31, 2018 at 3:13 PM, John Levine <johnl@taugh.com> wro= te:
It doesn't say= that in 4.1.2, even though it's sort of implicit since
i=3D means something else.=C2=A0 I'd say so explicitly in a fifth bulle= t
after where it says "three (3) differences."

One of those differences says:

* t= he presence of the =E2=80=9Cinstance tag=E2=80=9D. Additional information o= n the =E2=80=9Cinstance tag=E2=80=9D can be found in Section 4.2.1. The ins= tance tag replaces the DKIM =E2=80=9CAUID=E2=80=9D tag;

This language could probably be cleaned up to say "the 'i= 9; (AUID) tag is not imported from DKIM. Instead, it is replaced by the &qu= ot;instance tag" as defined in Section 4.2.1"

Then section 4.1.3 should use the identical language as well.
--000000000000177062057252f9dd-- From nobody Tue Jul 31 16:42:53 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26BB2128CF3 for ; Tue, 31 Jul 2018 16:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sparkpost.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id diey6VyvHGDD for ; Tue, 31 Jul 2018 16:42:50 -0700 (PDT) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2014130E96 for ; Tue, 31 Jul 2018 16:42:49 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id j143-v6so11981542lfj.12 for ; Tue, 31 Jul 2018 16:42:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sparkpost.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=5howskGh3XbVdsR2YN7/vnT56pADaFNimruOwYv7PMw=; b=AlU0lRfYV+OKJdLbDSeiIlOTXaZQGo+ttd5J1RV7NjEoWGW5aZzDyHZ0U1xXUVVCAY +mnJBUHh4N8dBjEd3xZDtXrMVvesrdPfM1nuRbOqJ9tJO4W2jf8f1J3bLGMSISyxeyys 1ipp9WS+EG9xJ3N2SQOE8BCiXS5mkB42EUAwk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=5howskGh3XbVdsR2YN7/vnT56pADaFNimruOwYv7PMw=; b=ud+trDqj1XngoG7iAjIBHBZAFFpNXSHa2Jc8y3l+RthjsRm0UW00+DChho6CVZEjuU 9N/jsYMeI84sgfqfQ5HC6EneX949SkREKqtdVMGDZyKmD5UnA1YXh5Cb2RdXnTRR6S2H bi3NULkYlgrbo0BORoP5u20ZN8tD/O4gWAoePkhxyc7Okb0LbwpPVIiljrr4EQtPD8yL BmfdMasg5tV577k1HqsDO7U9iTHaZ3U+AMcczTXOYf0Y/O97e73aJY/4yi3go/GaEEzf kGLrS0+QYK7EaU02YfZKYXGDUp9vtDd/zCUF2jyCm+kptYQX2qcQYNC9bA7pGqv0Ut3w hS5w== X-Gm-Message-State: AOUpUlGEzyatzbcFzHFi3eyHZ3n98/Yd4ODHuMLfSCUGV5ubDX3OAjIZ tNXQhuyvlckXqCaJDFaQiSx0nkmjX+U21dptZG0tedFA X-Google-Smtp-Source: AAOMgpenyxikwR+BTy6eEvFbF45QgJUm8+3JI6twyaKYNowu0M4LwaExS34GXLn2r8tlqt4fUIHXzxT4tMDE3m4Z/cw= X-Received: by 2002:a19:d98f:: with SMTP id s15-v6mr14639719lfi.103.1533080567883; Tue, 31 Jul 2018 16:42:47 -0700 (PDT) MIME-Version: 1.0 From: Juan Altmayer Pizzorno Date: Tue, 31 Jul 2018 19:42:35 -0400 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="000000000000a9461405725422ad" Archived-At: Subject: [dmarc-ietf] In support of draft-ietf-dmarc-arc-protocol-16 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 23:42:52 -0000 --000000000000a9461405725422ad Content-Type: text/plain; charset="UTF-8" Dear WG, I thought I'd chime in in support of the draft. Having implemented DKIM, SPF and various other email authentication protocols, I've chosen this time to integrate and contribute to OpenARC instead (power to the community! :)). So while I didn't implement it directly, I can't help but read it from that perspective; I think it reads very well and seems very clear. I hope the protocol is successful! .. Juan juan@port25.com / juan@sparkpost.com --000000000000a9461405725422ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear WG,

I thought I'd chime in in = support of the draft.=C2=A0 Having implemented DKIM, SPF
and vari= ous other email authentication protocols, I've chosen this time to
integrate and contribute to OpenARC instead (power to the community! = :)).
So while I didn't implement it directly, I can't hel= p but read it from that perspective;
I think it reads very well a= nd seems very clear.=C2=A0 I hope the protocol is successful!
.. Juan
--000000000000a9461405725422ad-- From nobody Tue Jul 31 17:26:24 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A5D130EAE for ; Tue, 31 Jul 2018 17:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W62GWomIX0Gp for ; Tue, 31 Jul 2018 17:26:20 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 305A4130DFF for ; Tue, 31 Jul 2018 17:26:20 -0700 (PDT) Received: (qmail 91738 invoked from network); 1 Aug 2018 00:26:18 -0000 Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 01 Aug 2018 00:26:18 -0000 Received: by ary.qy (Postfix, from userid 501) id 6DAB020031C6D0; Tue, 31 Jul 2018 20:26:17 -0400 (EDT) Date: 31 Jul 2018 20:26:17 -0400 Message-Id: <20180801002618.6DAB020031C6D0@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: seth@valimail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] ARC-16 and EAI messages X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2018 00:26:22 -0000 In article you write: >> 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 “instance tag”. Additional information on the >“instance tag” can be found in Section 4.2.1. The instance tag replaces the >DKIM “AUID” tag; > >This language could probably be cleaned up to say "the 'i' (AUID) tag is >not imported from DKIM. Instead, it is replaced by the "instance tag" as >defined in Section 4.2.1" > >Then section 4.1.3 should use the identical language as 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. R's, John PS: There's still four bullets after the three (3) differences. From nobody Tue Jul 31 17:29:36 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 601A4130EAE for ; Tue, 31 Jul 2018 17:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.089 X-Spam-Level: X-Spam-Status: No, score=-0.089 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6UfLgAlI3Iv for ; Tue, 31 Jul 2018 17:29:32 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B725130DFF for ; Tue, 31 Jul 2018 17:29:32 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id m13-v6so18091122qth.1 for ; Tue, 31 Jul 2018 17:29:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=B9f5ftyJSp1d9qMhK02QK/uHYkiVl0Ngkuy3ol/suaQ=; b=ZZqVmsCFVH/6EUGTxEnUVjKFtl7w5t9asa1rsWz1xmGmn7OfO4XeBz7153airZx0A9 aMMnECzJlEFK6SRAWX9jvxfKAVKiQDjINAi+7evoiOX/1O5Zi4B2JbAPCcWP6Wj8J5SB hnaDVS8Rc78rrdAZUlXUbquQlluQ4pmUqY6c8JM6GYI5gF1anqfK6vTMlpaZehsxct3o 57GMNW1aZvA5Kl5k0IEQPu/vUUm3MpfVgyD7ewDuNZoxGIdSuPxKwtByNuhDBrqQ9FOk L71AVa0xnsKoRhUOpBDVX4E0lC/WojwUQOgNqpBqNaVpnD90f86KmCox8PaCmcTET9mQ eVXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=B9f5ftyJSp1d9qMhK02QK/uHYkiVl0Ngkuy3ol/suaQ=; b=U/aCEAllJpLthXVN8dwVSPEow1vsDDevK/EggwAg7ZK8xch2ZMXBrmElBy2Kfa5knR toocsvF4R+b6nDcDGkrvOLo6Hum78mjsI37xXls0ZgzV8uQWCRw3BiDzJ8kZVbtQtOKG cPQoZB84Clb1A7d2Mq3vYMw/UcQot75S/3hQJ3hFQqZUJKdIq9gDQv3e/5r77IdcOaMl 6rkF9/xI88ee8rWcE7yULtowKSTIiuEZ5MAeDFtolGfQrOpEFCHcGY4sM/HjUlQxEftP JTdsT8mEEO9ITvvba2eOoHBAP9qQE5gk8wZTtr/49RbmB4AME5D9D6HMIGlsgP6jxqiY yiCQ== X-Gm-Message-State: AOUpUlFDe99TTNBAqVk2vYJnAAJ8Yr7Evm5juc2kqXz520wejWuY5uO1 bNPIUGwcTBX5Ck7V59ffgXNsvZf3GekU1V7htd+C8J6I X-Google-Smtp-Source: AAOMgpd2BS1i+TBi7IMKCJ1NK0vEnjzYioPkcZ4LG66juPQl3pEZ1KUAloUx1ugAgcLbX67SU9zpMTG9miwA0yEEEKQ= X-Received: by 2002:ac8:3fcd:: with SMTP id v13-v6mr23092070qtk.250.1533083371496; Tue, 31 Jul 2018 17:29:31 -0700 (PDT) MIME-Version: 1.0 References: <20180801002618.6DAB020031C6D0@ary.qy> In-Reply-To: <20180801002618.6DAB020031C6D0@ary.qy> From: Seth Blank Date: Tue, 31 Jul 2018 17:29:20 -0700 Message-ID: To: John Levine Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="000000000000c4fa02057254c9df" Archived-At: Subject: Re: [dmarc-ietf] ARC-16 and EAI messages X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2018 00:29:35 -0000 --000000000000c4fa02057254c9df Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 31, 2018 at 17:26 John Levine wrote: > In article vpag@mail.gmail.com> you write: > >> It doesn't say that in 4.1.2, even though it's sort of implicit since > >> i=3D 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 =E2=80=9Cinstance tag=E2=80=9D. Additional informa= tion on the > >=E2=80=9Cinstance tag=E2=80=9D can be found in Section 4.2.1. The instan= ce tag replaces > the > >DKIM =E2=80=9CAUID=E2=80=9D tag; > > > >This language could probably be cleaned up to say "the 'i' (AUID) tag is > >not imported from DKIM. Instead, it is replaced by the "instance tag" as > >defined in Section 4.2.1" > > > >Then section 4.1.3 should use the identical language as 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=3D is obvious. Done. > > PS: There's still four bullets after the three (3) differences. Yeah, I noticed and fixed that, too. S --=20 Seth Blank | Director of Industry Initiatives E: seth@valimail.com | P: 415.273.8818 --000000000000c4fa02057254c9df Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 31, 2018 at 17:26 John Levine <johnl@taugh.com> wrote:
=
In article &= lt;CAD2i3WMWaQ7RKGesphwFAu=3DYVa3pTNKbpKuA46kUL1C1=3D+vpag@mail.gmail.com> you write:<= br> >> It doesn't say that in 4.1.2, even though it's sort of imp= licit since
>> i=3D means something else.=C2=A0 I'd say so explicitly in a fi= fth bullet
>> after where it says "three (3) differences."
>
>One of those differences says:
>
>* the presence of the =E2=80=9Cinstance tag=E2=80=9D. Additional inform= ation on the
>=E2=80=9Cinstance tag=E2=80=9D can be found in Section 4.2.1. The insta= nce tag replaces the
>DKIM =E2=80=9CAUID=E2=80=9D tag;
>
>This language could probably be cleaned up to say "the 'i'= (AUID) tag is
>not imported from DKIM. Instead, it is replaced by the "instance t= ag" as
>defined in Section 4.2.1"
>
>Then section 4.1.3 should use the identical language as well.

Please do.=C2=A0 Experience tells us that the more clearly you lay somethin= g out, the
less likely we are to screw it up.=C2=A0 I don't remember what AUID is = without looking
it up but i=3D is obvious.

Done.

PS: There's still four bullets after the three (3) differences.

Yeah, I noticed and fixe= d that, too.

S
--

Seth Blank | Director of Industry Initiatives

E= : seth@val= imail.com | P: 415.273.8818


--000000000000c4fa02057254c9df--