From nobody Wed Aug 1 05:17: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 715EB130FF0 for ; Wed, 1 Aug 2018 05:17:09 -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 Gl4RgYRCw1A4 for ; Wed, 1 Aug 2018 05:17:06 -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 3DBD91310A0 for ; Wed, 1 Aug 2018 05:16:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=gamma; t=1533125817; bh=Ul0BN1XpE/DIxXZHjJHSzpyEB6DuwmgFSdk6dP1kaY8=; l=6328; h=To:Cc:References:From:Date:In-Reply-To; b=BbX5+bXyFptNlRdULeQ4ViIK+kmVbohm6om+Nhxat4N8T29X/oaCA82uTPRWhZgMC 1V2KFvoorwvsVUUWDuqHWTjQH2cidBT5A+LUXw8sWIahW7/IWYKKZvAx/LX2IqCl0f ajBhG6QjnEkCQNK1ep0QE6EPXCADSFdMKFMgazWoA5Z++hWQNxhHn8SX9jkih 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; Wed, 01 Aug 2018 14:16:57 +0200 id 00000000005DC056.000000005B61A4B9.00003B77 To: "Murray S. Kucherawy" Cc: IETF DMARC WG References: <91473b01-3bee-8e3f-58b0-7f444e58a19d@tana.it> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: Date: Wed, 1 Aug 2018 14:16:57 +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: Wed, 01 Aug 2018 12:17:10 -0000 On Tue 31/Jul/2018 15:10:21 +0200 Murray S. Kucherawy 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? Being proportional works both ways. You can estimate the quality from the accuracy of the content, then you can trust the field content (of a different method or message) based on what you learned about that operator. >>>> *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 meant something like so: The list of commands eligible for use with the "smtp" ptype can be found in Section 4.1 of [SMTP]. To report an SMTP command name 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.). > I'm also not clear on what problem you're trying to solve. No problem. That reorder and merge is just a marginal hint to improve readability. > 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? No, it is not broken, AFAICS. Rather, it's better than previous versions, where the "policy" ptype was overloaded beyond clarity, from covering unregistered properties, to overriding methods' results, to catchall for any property not extracted directly from the message session. >> 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. Agreed. However, my signing agent knows nothing about any AUTH= parameter to the MAIL FROM command. It just knows the (non-public) smtp.auth. What A-R field should it write? > 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. I beg to differ here. If the authentication token is syntactically equal to the [local-part of the] mailbox address, this can be considered as substantial data leakage, given that the mailbox address is public. IMHO, in a multi-host implementation where downstream agents need to acquire smtp.auth, there should be a final agent to redact it before it crosses the trust boundary. For example: Authentication-Results: example.net; auth=pass smtp.auth=REDACTED@example.net Or, according to rfc6590 algorithm: Authentication-Results: example.net; auth=pass smtp.auth=rZ8cqXWGiKHzhz1MsFRGTysHia4=@example.net Or just remove the header field entirely. Which is better? Also compare with varying values of From:: From: Bob+list@example.net To: list@lists.example.com Authentication-Results: example.net; auth=pass smtp.auth=bob@example.net >>>> *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. Both dkim=fail and dkim=policy are valid ways to override the method's algorithmic result. To exemplify the preferred way is fine for me. Best Ale -- From nobody Wed Aug 1 08:54: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 6349C130DD2 for ; Wed, 1 Aug 2018 08:54: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, 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=KQ2Ztn2N; dkim=pass (2048-bit key) header.d=andreasschulze.de header.b=GjM8xYxW 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 PhxphyaqKSvU for ; Wed, 1 Aug 2018 08:54:00 -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 31132129C6B for ; Wed, 1 Aug 2018 08:53:59 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=andreasschulze.de; i=@andreasschulze.de; q=dns/txt; s=ed25519; t=1533138835; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding : subject : from : date; bh=hzaC30aojDl+PYYC1S9TH6+TgzoKa2gol9HKT87WDqE=; b=KQ2Ztn2NTa4ULbBd8r7LitsN6j/kYmpLkzSO3sC3K7tKc0EI8x6AUfq4 0JCfsKM0uKbseGGCasSuWaQ0EOxGDg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andreasschulze.de; s=20180722-E324; t=1533138835; x=1538138835; bh=hzaC30aojDl+PYYC1S9TH6+TgzoKa2gol9HKT87WDqE=; 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=GjM8xYxWHKTQ47bJwQI5EhebxmuqaidIGPLjYKqH4P66EmqiNgvQ2/OH2iKwQB7oS mapWDPdaoNK69SP9dGLbeEiGb61nUDzdrrp7HjcQ3oFFaXT2Q1FbcR62ul+1L8C2N2 eGXQeJg2HSm6OK2rwX2R8OBrasWj0iKq+WtECZcfLv38foyGvjaw0n8YqCfwitXJQK fRYMM60PGKewRsliC/hZyIBiXG8mmXBM/416hOoSZO1OFXnTbdpOd5FzpTJRVIJrie gaRmfP/mbXvZf4p1tdoYetrLgNxtGUnasOku7b0uLjGIYxnTvb2f+vRsRhr7AV3C13 ZM857q7vWMK0A== To: dmarc@ietf.org References: From: "A. Schulze" Message-ID: Date: Wed, 1 Aug 2018 17:53:49 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [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: Wed, 01 Aug 2018 15:54:03 -0000 Hello WG, Seth pushed me to really /read/ the whole draft, thanks! I noted the following points that may or may not be so important... - section-2.1 introduce "AMDM" defined later in section-3 - I read https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-16 in section-3, the links point to sections inside the local document but are intended to point to https://tools.ietf.org/html/rfc5598 - section-12.4 could also mention the domain openarc.org In general it reads well and clear to me. I support that draft. (as well as the implementation just mentioned) Andreas From nobody Wed Aug 1 09:35:56 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 B33DB130E41 for ; Wed, 1 Aug 2018 09:35:55 -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 Hk-63J02TXJH for ; Wed, 1 Aug 2018 09:35:53 -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 4A2BB130DCD for ; Wed, 1 Aug 2018 09:35:53 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id n84-v6so35717508oib.9 for ; Wed, 01 Aug 2018 09:35:53 -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=LCt83vp0HaiCvmiBQ0YnjPUbdqX0Jau0SGbHX++codk=; b=AW9n9NYpbDerlH2rKVMKh6ahZDn/spp4RazwxI0wDj0iwoUmJyJluBj3Mjw/7+KI9a Hg2+RGCqm/aKLDW4E6Qp4oOHYJTMvfLduSymyxlDG1DNRsSeRgCeL/tVrsH84BNoeg30 uZvJ+lFNRleBJFgIM8Zw4duYcQfV3gP6IIKbB++FXamv3o2OVLi5U5E76bU9rLTBa9NW lKpoGjQyNVUJQbwpXbj/O+1DDYcCPMFkR8OV6sGbILl5zgF6BQIOZZfCU4bwZYGPaUoP H9eY6AIFUSSrMM2mBErLDPEKfDG5m1eQlejckrZ3kyM09NG382TzohGz5g3XPnwS8ZMp OUOw== 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=LCt83vp0HaiCvmiBQ0YnjPUbdqX0Jau0SGbHX++codk=; b=nzGNufcrR1qTu+BJ5ki7p0nA7ZwTTP29tOBv2KTK514I+Pd3fkHr8ogvAhGZs7Eu3+ p1N5S3R2T7GUrNtatAlr6KIClDiw9wiiYnBk+8tBkEiFvTEt7nFs8nATbqQZtN9OymUC U6FYt5fXRBuY+4IlSeCiuOJ0sKx4P7cTYGOcizMfsj+DvBRNALlvCVv4syZaVVZBXkTs Jd9826vG5VdtMFBpD+iNXjcYyNodx+mOjBVD+hvLRCVvHwCumBfvkzOR3qUrfbvdmYNJ g8hOuEbxnGzv6sBDN3SKttkYjahgu6BujwOjZhDvR8QjGkKYGHsOG7GiwiKnYVrQUKwF IC1g== X-Gm-Message-State: AOUpUlHOF47uQx3ldGAe073Cfc+gF2LDDVBHnDbx54sYDql7JWFmCbPN zX7bu0ypE3gt8MpPk5tiKmlY90HhBN9C75d8ON3IPDqw X-Google-Smtp-Source: AAOMgpfqNRq2eSCyEBerpw8agdA7o9WYiMWMhJWF/8Sl9Za7SdV3MlwRZiPgV8jBd/9N3SDSvZca4c8CtF/EZbcwVko= X-Received: by 2002:aca:cdc2:: with SMTP id d185-v6mr4483741oig.350.1533141351993; Wed, 01 Aug 2018 09:35:51 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:2646:0:0:0:0:0 with HTTP; Wed, 1 Aug 2018 09:35:31 -0700 (PDT) In-Reply-To: References: From: Seth Blank Date: Wed, 1 Aug 2018 09:35:31 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000ad426405726249ad" Archived-At: Subject: Re: [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: Wed, 01 Aug 2018 16:35:56 -0000 --000000000000ad426405726249ad Content-Type: text/plain; charset="UTF-8" On Wed, Aug 1, 2018 at 8:53 AM, A. Schulze wrote: > - section-2.1 introduce "AMDM" defined later in section-3 > Great catch. Based on Dave Crocker's feedback, we've defined the term "Authentication Assessment" and moved the entire second paragraph of 2.1 into this definition, which ends up addressing this. > - I read https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-16 > in section-3, the links point to sections inside the local document > but are intended to point to https://tools.ietf.org/html/rfc5598 > Yes, there are some link and normative reference clean ups to do for the final draft. > - section-12.4 could also mention the domain openarc.org Will do! > In general it reads well and clear to me. I support that draft. > (as well as the implementation just mentioned) Thanks for the feedback! --000000000000ad426405726249ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Aug 1, 2018 at 8:53 AM, A. Schulze <sca@andreasschulze.de><= /span> wrote:
- section-2.1 introduce &qu= ot;AMDM" defined later in section-3

Great catch. Based on Dave Crocker's feedback, we've defined the = term "Authentication Assessment" and moved the entire second para= graph of 2.1 into this definition, which ends up addressing this.
=C2=A0
- I read https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-16
=C2=A0 in section-3, the links point to sections inside the local document<= br> =C2=A0 but are intended to point to https://tools.ietf.org/html/<= wbr>rfc5598

Yes, there are some link and normative ref= erence clean ups to do for the final draft.
=C2=A0
- section-12.4 could also mention the domain openarc.org

Will do!
=C2=A0
In general it reads well and clear to me. I support th= at draft.
(as well as the implementation just mentioned)

<= div>Thanks for the feedback!=C2=A0

--000000000000ad426405726249ad-- From nobody Wed Aug 1 10:14: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 18AAF130EB1 for ; Wed, 1 Aug 2018 10:14:35 -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, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wemonitoremail.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 2sYKKt0sZXyU for ; Wed, 1 Aug 2018 10:14:33 -0700 (PDT) Received: from email.wemonitoremail.com (email.wemonitoremail.com [78.47.26.204]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7BDB130E92 for ; Wed, 1 Aug 2018 10:14:33 -0700 (PDT) Received: from localhost [127.0.0.1] DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemonitoremail.com; s=mail; t=1533143671; bh=JujpxjI47huUfT+Zt5xWyGgL5yCszRSDbSSqtd1yNhA=; h=Subject:From:To:Date:In-Reply-To:References; b=aCBDLGm5VhxPLYBGIZayu6eEMfNpErn4F/lbK0rQq7PuVdg3vQ148e/MFyS3684F/ kAdrRa79lkWiWy7pZReKMhhdMcpz0QTUOKqUG5TIpXFLFzDoofW+mjLJw6gIM1A55E sw6/gMLcQeX2bnWBZ8eQyiyJ70ObpJfS8TPsD6aE= Message-ID: <1533143665.3889.45.camel@wemonitoremail.com> From: Ken O'Driscoll To: dmarc@ietf.org Date: Wed, 01 Aug 2018 18:14:25 +0100 In-Reply-To: <153185962729.12680.10783427723792084937@ietfa.amsl.com> References: <153185962729.12680.10783427723792084937@ietfa.amsl.com> Organization: We Monitor Email Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.100.1 at email.wemonitoremail.com X-Virus-Status: Clean Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-16.txt 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 17:14:35 -0000 Apologies if this has already been caught by others. Just spotted some small typos in section 8. Was reading this specific section in connection with something GDPR (the fun!) related. 8. Privacy Considerations The Authenticated Received Chain provides a verifiable record of the handlers for a message. This record may include Personally Identifiable Information such as IP address and domain names. Such information is also including in existing header fields such as the "Received" header field. a) Suggest "IP addresses" to match plural for "domain names" or make it "an IP address". b) Replace "including" with "included" because it's grammatically incorrect. c) Suggest "exiting non-ARC related header fields" to distinguish that these are absolutely nothing to do with the protocol. It may be obvious to us but not to those who may discount implementation because they think it adds new risk. Ken. From nobody Wed Aug 1 14:12:08 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 469DB130E76 for ; Wed, 1 Aug 2018 14:12:06 -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 qSisCLS69qYl for ; Wed, 1 Aug 2018 14:12:04 -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 DD4C21271FF for ; Wed, 1 Aug 2018 14:12:03 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id 8-v6so99630oip.0 for ; Wed, 01 Aug 2018 14:12: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; bh=KPOLHvtLz8/Rvl/8tczszWA6dm4o3VIOxsDdRNuKL2k=; b=vwbbFMeiNW0kYTdkzkP3L3TmrU24jFM4k/AfRTTmfN4SdxaPRYVXh+pQTup0dvkUWE tRJCkQ9DoP7yWi1Vy//ct8yCGryfzcxktYBiWjHpnrQPNin5I4xPx1WRGaSWdI3x6mm8 BQR6sBOLxN0gUw5qZJLmUP+gO80knsvpOhV2FEAVkuWxvgnwL4ATi2ujB4IdQLa6rN0c XUTGic6VJcRDl4uLgB+5KSjLgS+KfhN3sGiOhkFwdKafkusjzakW9stY7ceN8AjDkTb5 bR35wrfvAF2sTJq3iLBeElV16h+PpdIXVvRMMFknh5u6Jhs5IyLmbD8xSl0hfPLGxP/N 6ZBQ== 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=KPOLHvtLz8/Rvl/8tczszWA6dm4o3VIOxsDdRNuKL2k=; b=tLIN1PeJVEGgb+lektb/IHLEiGDCclzrCgAr6hGaybGQmcXz8JM6EPvBUMn6avjUBc 0g+oXeqIFkiDWJAChtnkwdEkK3h7LZ1w6jaQPrAxN1Oo3b9UsrJz/XERyXaRCdcYFDyR N1tjS6M/8z1mhIyNSV3PNbwuaEKVNaDdk597rrtaLpqfUMkf5QhtYM4C0s/6vfrR+GCR FODzWA+g5JGBU7uI6PNikRDsKJwiSTJUQ+bArtqfiFgEJGWnhxXK/CwSqr7chmburRGh TMIJXlFmiloDHf3jGJo3Bjro4JeAlAJ1acwq2gZyr+PRrev76ksNvPKZJvVRo+OAC6pU xwtQ== X-Gm-Message-State: AOUpUlGxVFV6R4m60IHXG1+rC83EHfPnZqr28UhZZxFReEUcgPuPh+R2 V/+/+a2+wj9TSpDgYf8dMFRqeNkCbWDpILaERAc2tFZI X-Google-Smtp-Source: AAOMgpfdgzCQCCsFHNYphJB/xUOlXXx9IIrx+1L6pyAWiFdGblwDqYVLFLWxy/giWM75Tkqya7nayCKntRn3FZ/qjiA= X-Received: by 2002:aca:cdc2:: with SMTP id d185-v6mr6696oig.350.1533157922637; Wed, 01 Aug 2018 14:12:02 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:2646:0:0:0:0:0 with HTTP; Wed, 1 Aug 2018 14:11:42 -0700 (PDT) In-Reply-To: <1533143665.3889.45.camel@wemonitoremail.com> References: <153185962729.12680.10783427723792084937@ietfa.amsl.com> <1533143665.3889.45.camel@wemonitoremail.com> From: Seth Blank Date: Wed, 1 Aug 2018 14:11:42 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000005d334805726625ce" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-16.txt 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 21:12:06 -0000 --0000000000005d334805726625ce Content-Type: text/plain; charset="UTF-8" On Wed, Aug 1, 2018 at 10:14 AM, Ken O'Driscoll wrote: > > Apologies if this has already been caught by others. > > Just spotted some small typos in section 8. Was reading this specific > section in connection with something GDPR (the fun!) related. > > 8. Privacy Considerations > > The Authenticated Received Chain provides a verifiable record of the > handlers for a message. This record may include Personally > Identifiable Information such as IP address and domain names. Such > information is also including in existing header fields such as the > "Received" header field. > > > a) Suggest "IP addresses" to match plural for "domain names" or make it "an > IP address". > > b) Replace "including" with "included" because it's grammatically > incorrect. > > c) Suggest "exiting non-ARC related header fields" to distinguish that > these are absolutely nothing to do with the protocol. It may be obvious to > us but not to those who may discount implementation because they think it > adds new risk. > Thanks for these catches; all suggested changes have been made. > > Ken. > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --0000000000005d334805726625ce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Aug 1, 2018 at 10:14 AM, Ken O'Driscoll <k= en=3D40wemonitoremail.com@dmarc.ietf.org> wrote:

Apologies if this has already been caught by others.

Just spotted some small typos in section 8. Was reading this specific
section in connection with something GDPR (the fun!) related.

8.=C2=A0 Privacy Considerations

=C2=A0 =C2=A0The Authenticated Received Chain provides a verifiable record = of the
=C2=A0 =C2=A0handlers for a message.=C2=A0 This record may include Personal= ly
=C2=A0 =C2=A0Identifiable Information such as IP address and domain names.= =C2=A0 Such
=C2=A0 =C2=A0information is also including in existing header fields such a= s the
=C2=A0 =C2=A0"Received" header field.


a) Suggest "IP addresses" to match plural for "domain names&= quot; or make it "an
IP address".

b) Replace "including" with "included" because it's= grammatically
incorrect.

c) Suggest "exiting non-ARC related header fields" to distinguish= that
these are absolutely nothing to do with the protocol. It may be obvious to<= br> us but=C2=A0 not to those who may discount implementation because they thin= k it
adds new risk.


Thanks fo= r these catches; all suggested changes have been made.

=
=C2=A0

Ken.

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

--0000000000005d334805726625ce-- From nobody Thu Aug 2 06:43: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 14B01129AB8 for ; Thu, 2 Aug 2018 06:43:21 -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 oofOV8YEVSYK for ; Thu, 2 Aug 2018 06:43:15 -0700 (PDT) Received: from mail-pl0-x233.google.com (mail-pl0-x233.google.com [IPv6:2607:f8b0:400e:c01::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 A57C7128BAC for ; Thu, 2 Aug 2018 06:43:15 -0700 (PDT) Received: by mail-pl0-x233.google.com with SMTP id e11-v6so1061970plb.3 for ; Thu, 02 Aug 2018 06:43:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=oiUP40Ho40ilrQK3uczJSLuIxWaixS56v/O0h+RW1BM=; b=XOtMk7xqV2ygwXqUm/f3fyVFi11XoNDCMawYWRHvbbNhL4gBwSNG+M3HNoT4EuYONX 15OTOZvwv/W63/oks9GEdzdVQUKYz0Mu8ccGev0UaaoqW8uTvi/MV/yUimMiWObK5wQE +nkgob+kOjt5X6oC0NhK3C/H6vcrpSTTq8HQw8oLRto4Vk09SvzDRnwEe2/Kf4jlhwbg kek28gvjGhYONsUj4sFJVJDVjt2jvq1ZgBZf4EXq9PP2/d2PmRLTjgMe3Q3FO0knkR1W 0Qil0Gl9zmSOG8ue4CKrC45eAqovVC8JHASn5I9D4MEsmZg+KduAZnfiehuUb6k7Pilg jPeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=oiUP40Ho40ilrQK3uczJSLuIxWaixS56v/O0h+RW1BM=; b=QZoDf5XadJlhGY3SXDpX9MfFUcErZ5N425UJI+8k3uDAwx7AHrIPKlfFXH4Ird4PcS 0fMNXnflJ6J283cRAp49sTfmFq1icygTZLY0HlWBNXeHx3884QCP5dymvp/UUg1OxrQg eYVPTvMGIf9hZYKHHBKdlyAiSe3XLZjn6vxwIh0uzn3mgeipT++TZRya8Rts2RKG3IDI VbULBX3BPB+L03XXUReo4fHHbWvK8rh06GWb10ImuJoCVTXPF51l9YQ/n6o1m0hEa2ar GXm2t5Xa9+UrizrxkmMlap8QVnv5dFo0dGQ9SknhEiuEnB3K0NkoMEuelRtvCpHzC14/ DzWQ== X-Gm-Message-State: AOUpUlEjU0WkIJTIxsiHqcLyxA9ra7bLo2eLxmv4lpj3+xoOolHdHu+V WrCCZoRNGa3UnqPOnRcmRZCCkBom X-Google-Smtp-Source: AAOMgpfXxX+G3mwb2gXnPsby01drKkEclOIWJHRn3LUerBPSa7qJeskgGQDeniYYNiceGk0obVLUjw== X-Received: by 2002:a17:902:8a87:: with SMTP id p7-v6mr2412901plo.281.1533217394587; Thu, 02 Aug 2018 06:43:14 -0700 (PDT) Received: from [172.20.17.138] ([12.226.241.16]) by smtp.gmail.com with ESMTPSA id s85-v6sm4662384pfa.116.2018.08.02.06.43.12 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Aug 2018 06:43:13 -0700 (PDT) From: Dave Crocker To: IETF DMARC WG Message-ID: Date: Thu, 2 Aug 2018 06:43:11 -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] Additional 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: Thu, 02 Aug 2018 13:43:21 -0000 Continuing my review of: draft-ietf-dmarc-arc-protocol-16 NB: These are comments, not demands. Use however is helpful... > 4. Protocol Elements I keep thinking that it would help to have some summary text, possibly with a figure, that shows the role of individual header fields and sets of them. My first inclination is to suggest putting it here, but perhaps it would actually be better to have it at the /end/ of this section, after each component has been defined. (I'd offer some candidate text/figure, but I am not sure I have a solid enough sense of the details.) > 4.1. ARC Headers Headers -> Header Fields (I feel compelled to constantly apologize that RFC 733 made the term be 'header field' rather than 'header'...) > > ARC introduces three new header fields. Syntax for new header fields > borrows heavily from existing specifications. This document only > borrows heavily from -> adapts > Andersen, et al. Expires January 18, 2019 [Page 7] > > > Internet-Draft ARC-Protocol July 2018 > > > describes where ARC-specific changes in syntax and semantics differ > from existing specifications. > > 4.1.1. ARC-Authentication-Results (AAR) > > The ARC-Authentication-Results (AAR) header field records the message > authentication state as processed by an ARC-participating ADMD at > message arrival time. I'll note my continuing concern for 'authentication state'... > > In General Concept terms, the AAR header field is where Evidence is > recorded by a Custodian. The arguments against the chain of custody model and terminology have swayed me. The operation of ARC is not strict enough or reliable enough to justify the model or terms, which means that using them sets expectations to high. > > The AAR header field is similar in syntax and semantics to an > Authentication-Results field [I-D-7601bis], with two (2) differences: > > o the name of the header field itself; > > o the presence of the "instance tag". Additional information on the > "instance tag" can be found in Section 4.2.1. > > The formal ABNF for the AAR header field is: > > arc-info = instance [CFWS] ";" authres-payload > arc-authres-header = "ARC-Authentication-Results:" [CFWS] arc-info > > Because there is only one AAR allowed per ARC set, the AAR MUST > contain all authentication results from within the participating > ADMD, regardless of how many Authentication-Results headers are > attached to the message. > > 4.1.2. ARC-Message-Signature (AMS) > > The ARC-Message-Signature (AMS) header field allows an ARC- > participating ADMD to convey some responsibility (custodianship) for > a message and possible message modifications to future ARC- > participating Custodians. > > In General Concept terms, the AMS header field identifies a > Custodian. The text after this provides some technical details about differences, but in terms of utility/purpose, how does this compare to doing a DKIM signature by this ADMD? It's worth providing some comment about this. > > The AMS header field is similar in syntax and semantics to a DKIM- > Signature field [RFC6376], with three (3) differences: is similar in -> has the same to a -> as the > > o the name of the header field itself; > > o no version tag ("v") is defined for the AMS header field. As > required for undefined tags (in [RFC6376]), if seen, a version tag > MUST be ignored; > > > > Andersen, et al. Expires January 18, 2019 [Page 8] > > > Internet-Draft ARC-Protocol July 2018 > > > o 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; > > o when building the header field list to be signed, ARC-related > headers MUST be submitted to the hash function in increasing > instance order. header -> fields > > ARC places no requirements on the selectors and/or domains used for > the AMS header field signatures. > > The formal ABNF for the AMS header field is: > > arc-ams-info = instance [CFWS] ";" tag-list > arc-message-signature = "ARC-Message-Signature:" [CFWS] arc-ams-info > > To avoid unwanted invalidation of AMS signatures: There are cases where invalidation is /wanted/??? Perhaps: To minimize the problem of AMS signature invalidation: > > o AMS header fields are added by ARC-participating ADMDs as messages > exit the ADMD. AMS header fields SHOULD be attached so that any > modifications made by the ADMD are included in the signature of > the AMS header field. > > o Authentication-Results header fields MUST NOT be included in AMS > signatures as they are likely to be deleted by downstream ADMDs > (per [I-D-7601bis] Section 5). > > o ARC-related header fields (ARC-Authentication-Results, ARC- > Message-Signature, ARC-Seal) MUST NOT be included in the list of > header fields covered by the signature of the AMS header field. > > To preserve the ability to verify the integrity of a message, the > signature of the AMS header field SHOULD include any DKIM-Signature > header fields already present in the message. Arguably, including it/them does NOT alter integrity validation. i suspect /ever/. At the least, be explicit about /what/ integrity is being maintain. That is, the dkim signature provides a specific kind of integrity. If it validates, that integrity is proved. If it doesn't, it isn't. covering it by ARC doesn't affect either outcome. > > 4.1.3. ARC-Seal (AS) > > The ARC-Seal (AS) header field is the mechanism by which ARC- is a mechanism by which -> permits > participating ADMDs can verify the integrity of AAR header fields and can -> to > corresponding AMS header fields. > > In General Concept terms, the AS header field is how Custodians bind > Evidence into a Chain of Custody so that Validators can inspect > individual Evidence and Custodians. > > The AS header field is similar in syntax and semantics to DKIM- > Signatures [RFC6376], with the following differences: > > > > > Andersen, et al. Expires January 18, 2019 [Page 9] > > > Internet-Draft ARC-Protocol July 2018 > > > o the presence of the "instance tag". Additional information on the > "instance tag" can be found in Section 4.2.1. > > o the signature of the AS header field does not cover the body of > the message and therefore there is no 'bh' tag. The signature of > the AS header field only covers specific header fields as defined > in Section 5.1.1. > > o no body canonicalization is performed as the AS signature does not > cover the body of a message. > > o only "relaxed" header canonicalization ([RFC6376] section 3.4.2) > is used. > > o the only supported tags are "i" (from Section 4.2.1 of this > document), and "a", "b", "d, "s", "t" from [RFC6376] Section 3.5. > Note especially that the DKIM "h" tag is NOT allowed and if found, > MUST result in a cv status of "fail" (for more information see > Section 5.1.1); > > o an additional tag, "cv" ("seal-cv-tag" in the ARC-Seal ABNF > definition) is used to communicate Chain Validation Status to > subsequent ADMDs. > > ARC places no requirements on the selectors and/or domains used for > the AS header field signatures. what does this mean? how is it relevant? > > The formal ABNF for the AS header field is: > > arc-as-info = instance [CFWS] ";" tag-list > arc-seal = "ARC-Seal:" [CFWS] arc-as-info > > 4.2. ARC Set > > An "ARC Set" is a single collection of three ARC Headers (AAR, AMS, > and AS). ARC Headers of an ARC Set share the same "instance" value. > > By adding all ARC Headers to a message, an ARC Sealer adds an ARC Set > to a message. A description of how Sealers add an ARC Set to a > message is found in Section 5.1. > > 4.2.1. Instance Tags > > Instance tags describe which ARC Headers belong to an ARC Set. Each > ARC Header of an ARC Set shares the same instance tag value. > > Instance tag values are integers that begin at 1 and are incremented > by each addition of an ARC Set. Through the incremental values of > > > > Andersen, et al. Expires January 18, 2019 [Page 10] > > > Internet-Draft ARC-Protocol July 2018 > > > instance tags, an ARC Validator can determine the order in which ARC > Sets were added to a message. > > Instance tag values can range from 1-50 (inclusive). > > _INFORMATIONAL:_ The upper limit of 50 was picked based on some > initial observations reported by early working group members with a > safety margin multiple added on top to support the vast majority of > all intermediary mail flows. Rather than citing a wg process, document the technical, administrative and/or operation concerns, benefits, etc. that justify the choice. > > Valid ARC Sets MUST have exactly one instance of each ARC Header > field (AAR, AMS, and AS) for a given instance value and signing > algorithm. > > _INFORMATIONAL:_ Initial development of ARC is only being done with a > single allowed signing algorithm, but parallel work in the DCRUP > working group is expanding that. For handling multiple signing > algorithms, see [ARC-MULTI]. As a rule, RFCs should not refer to parallel activities, since the reference is soon to become stale and wrong. If additional signing algorithms are anticipated -- and of course they should be -- then define a means for extending what is permitted, noting that the initial algorithm is provided to ensure basic, initial interoperability. > > 4.3. Authenticated Received Chain > > An Authenticated Received Chain is an ordered collection of ARC Sets. > As ARC Sets are enumerated sets of ARC Headers, an Authenticated > Received Chain represents the output of message authentication state > along the handling path of ARC-enabled processors. > > Results of message authentication processing along each step of the > ARC-enabled handling path is present in an Authenticated Received > Chain in the form of AAR header fields. The ability to verify the > identity of message handlers and the integrity of message content is > provided by AMS header fields. AS header fields allow messages > handlers to validate the assertions, order and sequence of the > Authenticated Received Chain itself. > > In General Concept terms, an Authenticated Received Chain represents > a message's Chain of Custody. Validators can consult a message's > Chain of Custody to gain insight regarding each Custodian of a > message and the Evidence collected by each Custodian. > > 4.4. Chain Validation Status > > The state of the Authenticated Received Chain at a specific > processing step is called the "Chain Validation Status". Chain > Validation Status information is communicated in several ways: > > o the AS header field in the "cv" tag, and > > o as part of Authentication-Results and AAR headers. > > > > Andersen, et al. Expires January 18, 2019 [Page 11] > > > Internet-Draft ARC-Protocol July 2018 > > > Chain Validation Status has one of three possible values: > > o none: There was no Authenticated Received Chain on the message > when it arrived for validation. Typically this occurs when a > message is received directly from a message's original Message > Transfer Agent (MTA) or Message Submission Agent (MSA), or from an > upstream Internet Mail Handler that is not participating in ARC > handling. > > o fail: The message contains an Authenticated Received Chain whose > validation failed. > > o pass: The message contains an Authenticated Received Chain whose > validation succeeded. > > 5. Protocol Actions > > ARC-enabled Internet Mail Handlers generally act as both ARC Sealers > (when sending messages) and ARC Validators (when receiving messages). generally? that statement is worth expanding. When are they only one? When are they only the other? Is it possible to do neither and still be an Arc-enabled IM handler? What is the benefit of doing only one? > 5.1. Sealer Actions > > To "seal" a message, an ARC Sealer adds an ARC Set (the three ARC > header fields AAR, AMS, and AS) to a message. All ARC header fields > in an ARC Set share the same instance tag value. > > To perform Sealing (aka to build and attach a new ARC Set), the > following actions must be taken by an ARC Sealer when presented with > a message: > > 1. All message modifications (including adding DKIM-Signatures) MUST > be performed before Sealing. Does it include adding Received fields? Given how common the action, it's worth citing it explicitly. > > 2. Calculate the instance value: if the message contains an contains -> already contains > Authenticated Received Chain, the instance value is 1 more than > the highest instance number found in the Authenticated Received > Chain. If no Authenticated Received Chain exists, the instance > value is 1. > > 3. Using the calculated instance value, generate and attach to the > message in the following order: 4-6 are subordinate to 3. They should be sub-numbered. Alternatively (and probably better) is to get rid of 3 and mildly modify 4, 5 and 6 to have the 'generate and attach' verbiage directly... > > 4. An ARC-Authentication-Results header field as defined in > Section 4.1.1. > > 5. An ARC-Message-Signature header field as defined in > Section 4.1.2. > > > > > Andersen, et al. Expires January 18, 2019 [Page 12] > > > Internet-Draft ARC-Protocol July 2018 > > > 6. An ARC-Seal header field using the AS definition found in > Section 4.1.3, the method described in Section 5.1.1, and the > Chain Validation Status as determined during ARC validation. > > 5.1.1. Header Fields To Include In ARC-Seal Signatures > > The signature of an AS header field signs a specific canonicalized delete 'specific'. > form of the ARC Set header values. The ARC set header values are > supplied to the hash function in increasing instance order, starting 'the hash function'. Not clear to be that which hash function will be clear to the reader, especially since there is more than one in ARC, isn't there -- one for arc signature and one for arc seal? > at 1, and include the ARC Set being added at the time of Sealing the > message. > > 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). Not sure how the above sentence is supposed to be used, especially in the middle of the detailed procedural specification. > > Note that when an Authenticated Received Chain has failed validation, > the signing scope for the ARC-Seal is modified (see Section 5.1.2). This sounds like it should be more than a terse, offhand 'note' and it seems to imply that the reader should already be aware of the point. > > 5.1.2. Marking and Sealing "cv=fail" (Invalid) Chains > > 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 created by the MTA which > detected the malformed chain, as if this newest ARC Set was the only > set present. > > _INFORMATIONAL_: This approach is mandated to handle the case of a > malformed or otherwise invalid Authenticated Received Chain. There > is no way to generate a deterministic set of AS header fields > (Section 5.1.1) in most cases of invalid chains. > > 5.1.3. Only One Authenticated Received Chain Per Message > > A message can have only one Authenticated Received Chain on it at a > time. Once broken, the chain cannot be continued, as the chain of > custody is no longer valid and responsibility for the message has > been lost. For further discussion of this topic and the designed > restriction which prevents chain continuation or re-establishment, > see [ARC-USAGE]. > > > > Andersen, et al. Expires January 18, 2019 [Page 13] > > > Internet-Draft ARC-Protocol July 2018 > > > 5.1.4. Broad Ability to Seal > > ARC is not solely intended for perimeter MTAs. Any mediator > ([RFC5598], section 5) that modifies a message may Seal its own > changes. For additional information, see Section 7.1. > > 5.1.5. Sealing is Always Safe > > The utility of an Authenticated Received Chain is limited to very > specific cases. Authenticated Received Chains are designed to > provide additional information to an Internet Mail Handler when > evaluating messages for delivery in the context of authentication > failures. Specifically: > > o Properly adding an ARC Set to a message does not damage or > invalidate an existing Authenticated Received Chain. > > o Sealing an Authenticated Received Chain when a message has not > been modified does not negatively affect the chain. > > o Validating a message exposes no new threat vectors (see > Section 9). > > o An ADMD may choose to Seal all inbound messages whether or not a > message has been modified or will be retransmitted. > > 5.1.6. Signing vs Sealing > > Signing is the process of affixing a digital signature to a message > as a header, such as when a DKIM-Signature (as in [RFC6376] section > 2.1), or an AMS or AS is added. Sealing is when an ADMD affixes a > complete and valid ARC Set to a message creating or continuing an > Authenticated Received Chain. This paragraph should not be buried deep here. It should probably be at the beginning of 5, or a similar 'introductory' place. I'm starting to wonder about whether the term should be 'seal' or 'ARC seal'. Here's my concern: 'signing' is a well-established, generic term. 'Sealing' is not. Sealing applies only to ARC; the term is being created here. There is less likelihood of confusion about the term if it is always formally referred to as 'ARC Sealing', because that will always make clear the context for its use. BTW, do a complete pass over the doc, looking for 'header' and check whether it should actually be 'field' or 'header field'... > > 5.2. Validator Actions > > A validator performs the following steps, in sequence, to process an > Authenticated Received Chain. Canonicalization, hash functions, and > signature validation methods are imported from [RFC6376] section 5. > > 1. Collect all ARC Sets currently attached to the message. If there break this into a list of sub-steps/-conditions > are none, the Chain Validation Status is "none" and the algorithm > stops here. The maximum number of ARC Sets that can be attached > to a message is 50. If more than the maximum number exist the > Chain Validation Status is "fail" and the algorithm stops here. > In the following algorithm, the maximum ARC instance value is > referred to as "N". > > > > > Andersen, et al. Expires January 18, 2019 [Page 14] > > > Internet-Draft ARC-Protocol July 2018 > > > 2. If the Chain Validation Status of the highest instance value ARC > Set is "fail", then the Chain Validation status is "fail" and the > algorithm stops here. > > 3. Validate the structure of the Authenticated Received Chain. A > valid ARC has the following conditions: > > 1. Each ARC Set MUST contain exactly one each of the three ARC > header fields (AAR, AMS, and AS). > > 2. The instance values of the ARC Sets MUST form a continuous > sequence from 1..N with no gaps or repetition. > > 3. The "cv" value for all ARC-Seal header fields must be non- "non-failing" is not a listed value. I think an acceptable for of what you want to say: Each ARC-Seal MUST NOT have a "cv" value of "fail". > failing. For instance values > 1, the value must be "pass". > For instance value = 1, the value must be "none". must -> MUST > > * If any of these conditions are not met, the Chain Validation > Status is "fail" and the algorithm stops here. > > 4. Validate the AMS with the greatest instance value (most recent). > If validation fails, then the Chain Validation Status is "fail" > and the algorithm stops here. > > 5. _OPTIONAL:_ Determine the "oldest-pass" value from the ARC Set by > validating each prior AMS beginning with the N-1 and proceeding > in decreasing order to the AMS with the instance value of 1: why do this? i gather some of the following are subordinate to 5? > > 6. If an AMS fails to validate (for instance value "M"), then set > the oldest-pass value to the lowest AMS instance value which > passed (M+1) and go to the next step (there is no need to check > any other (older) AMS headers). This does not affect the > validity of the Authenticated Received Chain. > > 7. If all AMS headers verify, set the oldest-pass value to zero (0). > > 8. Validate each AS beginning with the greatest instance value and > proceeding in decreasing order to the AS with the instance value > of 1. If any AS fails to validate, the Chain Validation Status > is "fail" and the algorithm stops here. > > 9. If the algorithm reaches this step, then the Chain Validation > Status is "pass", and the algorithm is complete. > > The end result of this Validation algorithm is added into the > Authentication-Results header for the ADMD. > > > > > > Andersen, et al. Expires January 18, 2019 [Page 15] > > > Internet-Draft ARC-Protocol July 2018 > > > As with a failing DKIM signature ([RFC6376] section 6.3), a message > with a failing Authenticated Received Chain MUST be treated the same > as a message with no Authenticated Received Chain. fail"ing"? I think you mean DKIM signature validation failure. > > _INFORMATIONAL_: Recipients of an invalid or failing Authenticated > Received Chain can use that information as part of a wider handling > context. ARC adoption cannot be assumed by intermediaries; many > intermediaries will continue to modify messages without adding ARC > Seals. > > 5.2.1. All Failures Are Permanent > > Authenticated Received Chains represent the traversal of messages > through one or more intermediaries. All errors, including DNS > failures, become unrecoverable and are considered permanent. > > Any error Validating an Authenticated Received Chain results in a > failed Chain Validation Status. For further discussion of this topic > and the design restriction which prevents chain continuation or re- > establishment, see [ARC-USAGE]. > > 5.2.2. Responding to ARC Validation Failures During the SMTP > Transaction > > If an ARC Validator determines that the incoming message fails > authentication checks (potentially including ARC validation), the > Validator MAY signal the breakage through the extended SMTP response > code 5.7.7 [RFC3463] "message integrity failure" [ENHANCED-STATUS] > and corresponding SMTP response code. > > 5.3. Result of Validation > > An Authenticated Received Chain with a Chain Validation Status of > "pass" allows Internet Mail Handlers to ascertain: > > o all ARC-participating ADMDs that claim responsibility for handling > (and possibly modifying) the message in transit; > > o the authentication state of the message as perceived by each ADMD > (from Authentication-Results header fields). > > Given this information, handlers can inform local policy decisions > regarding disposition of messages that experience authentication > failure due to intermediate processing. 5.3 isn't really a results specification. It seems more like a useful summary of the tool's value proposition. > > > > > > > > Andersen, et al. Expires January 18, 2019 [Page 16] > > > Internet-Draft ARC-Protocol July 2018 > > > 6. Communication of Validation Results > > Chain Validation Status (described in Section 4.4) is communicated > via Authentication-Results (and AAR) headers using the auth method > "arc". This auth method is described in Section 10.1. > > If necessary data is available, the ptypes and properties defined in > Section 10.2 SHOULD be recorded in an Authentication-Results header > field: > > o smtp.client-ip - The connecting client IP address from which the > message is received. this seems such a large privacy concern, I question allowing it here. (This highlights the difference between passing information inside an enterprise, vs. over the open Internet, across administrations.) > > o header.oldest-pass - The instance number of the oldest AMS that > still validates, or 0 if all pass. > > Upon Sealing of a message, this Authentication-Results information > along with all other Authentications-Results added by the ADMD will > be recorded into the AAR as defined in section Section 4.1.1. > > In General Concept terms, the information recorded in the ARC- > Authentication-Results header field is the Evidence that gets > attached to a message. 1. Don't capitalize GC 2. Each of these summary statements is better put much earlier. > > 7. Use Cases > > This section explores several messaging handling use cases that are > addressed by ARC. > > 7.1. Communicate Authentication Results Across Trust Boundaries > > When an intermediary ADMD adds an ARC Set to a message's > Authenticated Received Chain (or creates the initial ARC Set), the > ADMD communicates authentication state to the next ADMD in the > message handling path. to the next ARC-participating ADMD... > > If ARC-enabled ADMDs are trusted, Authenticated Received Chains can > be used to bridge administrative boundaries. This use case really isn't a use case, IMO. Rather, it is a basic observation about the nature and purpose of ARC. > > 7.1.1. Message Scanning Services > > Message services are available to perform anti-spam, anti-malware, > and anti-phishing scanning. Such services typically remove malicious > content, replace HTTP links in messages with sanitized links, and/or > attach footers to messages advertising the abilities of the message > scanning service. These modifications almost always break signature- > based authentication (such as DKIM). > > > > > Andersen, et al. Expires January 18, 2019 [Page 17] > > > Internet-Draft ARC-Protocol July 2018 > > > Scanning services typically require clients to point MX records of an > Internet domain to the scanning service. Messages destined for the > Internet domain are initially delivered to the scanning service. > Once scanning is performed, messages are then routed to the client's > own mail handling infrastructure. Re-routing messages in this way > almost always breaks path-based authentication (such as SPF). > > Message scanning services can attach Authenticated Received Chains to > messages to communicate authentication results into client ADMDs. > Clients can then benefit from the message scanning service while > processing messages as if the client's infrastructure were the > original destination of the Internet domain's MX record. A message scanning service has a tight relationship with the receiving ADMD. In fact they are arguably /part/ of the receiving ADMD, in terms of trust among actors. Hence I don't understand they they need ARC. They do all of the assessment work. Why can't they just attach a normal auth-results field? > > 7.1.2. Multi-tier MTA Processing > > Large message processing infrastructure is often divided into several > processing tiers that can break authentication information between > tiers. For example, a large site may maintain a cluster of MTAs > dedicated to connection handling and enforcement of IP-based > reputation filtering. A secondary cluster of MTAs may be dedicated > and optimized for content-based processing of messages. > > Authenticated Received Chains can be used to communicated > authentication state between processing tiers. Again, this is inside an enterprise's operation - a single ADMD - where the trust of actors should be quite high. Why is ARC needed here, rather than normal Auth-Results? > > 7.1.3. Mailing Lists > > Mailing lists resend posted messages to subscribers. A full re-send posted messages -> take delivery of messages and re-post them 'send' is not precise enough here. > description of authentication-related mailing list issues can be > found in [RFC7960] Section 3.2.3. > > Mailing list services can implement ARC to convey the original > authentication state of posted messages sent to the list's subscriber > base. The ADMDs of the mailing list subscribers can then use the > Authenticated Received Chain to determine the authentication state of > the original message before mailing list handling. > > 7.2. Inform Message Disposition Decisions > > ARC functionality allows Internet Mail Handlers to reliably identify > intermediary ADMDs and for ADMDs to expose authentication state that > can survive additional intermediary handling. This seems a highly redundant paragraph. > > Intermediaries often break authentication through content > modification, interfere with path-based authentication (such as SPF), > and strip authentication results (if an MTA removes Authentication- > Results headers). > > > > > Andersen, et al. Expires January 18, 2019 [Page 18] > > > Internet-Draft ARC-Protocol July 2018 > > > Authenticated Received Chains allow ARC Validators to: > > 1. identify ARC-enabled ADMDs that break authentication while > processing messages; > > 2. gain extended visibility into the authentication-preserving > abilities of ADMDs that relay messages into ARC-enabled ADMDs. > > Through the collection of ARC-related data, an ADMD can identify > handling paths that have broken authentication. > > An Authenticated Received Chain allows an Internet Mail Handler to > potentially base decisions of message disposition on authentication > state provided by different ADMDs. > > 7.2.1. DMARC Local Policy Overrides > > DMARC introduces a policy model where Domain Owners can request email > receivers to reject or quarantine messages that fail DMARC alignment. > Interoperability issues between DMARC and indirect email flows are > documented in [RFC7960]. > > Authenticated Received Chains allow DMARC processors to consider > authentication states provided by other ADMDs. As a matter of local > policy, a DMARC processor may choose to accept the authentication may -> MAY > state provided by an Authenticated Received Chain when determining if > a message is DMARC compliant. > > When an Authenticated Received Chain is used to determine message > disposition, the DMARC processor can communicate this local policy > decision to Domain Owners as described in Section 7.2.2. > > 7.2.2. DMARC Reporting > > DMARC-enabled receivers indicate when ARC Validation influences > DMARC-related local policy decisions. DMARC reporting of ARC- > influenced decisions is accomplished by adding a local_policy comment > containing a list of data discovered during ARC Validation, which at > a minimum includes: > > o the Chain Validation Status, > > o the domain and selector for each AS, > > o the originating IP address from the first ARC Set: a local policy comment /where/? according to what specification for such comments? > > > > > > Andersen, et al. Expires January 18, 2019 [Page 19] > > > Internet-Draft ARC-Protocol July 2018 > > > EXAMPLE: > > > none > fail > fail > > local_policy > 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 > > > > In the above example DMARC XML reporting fragment, data relating to > specific validated ARC Sets are enumerated using array syntax (eg, > "ams[2]" means AMS header field with instance value of 2). d2.example > is the Sealing domain for ARC Set #2 (i=2) and d1.example is the > Sealing domain for ARC Set #1 (i=1). > > Depending on the reporting practices of intermediate message > handlers, Domain Owners may receive multiple DMARC reports for a > single message. DMARC report processors should be aware of this > behaviour and make the necessary accommodations. > > 8. Privacy Considerations > > The Authenticated Received Chain provides a verifiable record of the > handlers for a message. This record may include Personally > Identifiable Information such as IP address and domain names. Such > information is also including in existing header fields such as the > "Received" header field. > > 9. Security Considerations > > The Security Considerations of [RFC6376] and [I-D-7601bis] apply > directly to this specification. > > As with other domain authentication technologies (such as SPF, DKIM, > and DMARC), ARC makes no claims about the semantic content of > messages. > > 9.1. Increased Header Size > > Inclusion of Authenticated Received Chains into messages may cause > issues for older or constrained MTAs due to increased total header > size. Large header blocks, in general, may cause failures to deliver header /field/? > > > > > Andersen, et al. Expires January 18, 2019 [Page 20] > > > Internet-Draft ARC-Protocol July 2018 > > > or other outage scenarios for such MTAs. ARC itself would not cause > problems. > > 9.2. DNS Operations > > The validation of an Authenticated Received Chain composed of N ARC > Sets can require up to 2*N DNS queries (not including any DNS > redirection mechanisms which can increase the total number of > queries). This leads to two considerations: > > 1. An attacker can send a message to an ARC participant with a > concocted sequence of ARC Sets bearing the domains of intended > victims, and all of them will be queried by the participant until > a failure is discovered. The difficulty of forging the signature > values should limit the extent of this load to domains under > control of the attacker. Query traffic pattern analysis may > expose information about downstream validating ADMD > infrastructure. > > 2. DKIM only performs one DNS query per signature, while ARC can > introduce many (per chain). Absent caching, slow DNS responses > can cause SMTP timeouts; and backlogged delivery queues on > Validating systems. This could be exploited as a DoS attack. > > 9.3. Message Content Suspicion ARC authenticates the identity of some email handling actors. It does not make any assessment of their trustworthiness. > > Recipients are cautioned to treat messages bearing Authenticated > Received Chains with the same suspicion applied to all other > messages. This includes appropriate content scanning and other > checks for potentially malicious content. > > Just as passing message authentication is not an indication of > message safety, forwarding that information through the mechanism of > ARC is also not an indication of message safety. Even if all ARC- > enabled ADMDs are trusted, ADMDs may have become compromised, may > miss unsafe content, or may not properly authenticate messages. > > 9.4. Message Sealer Suspicion > > Recipients are cautioned to treat every Sealer of the ARC Chain with > suspicion. Just as with a validated DKIM signature, responsibility > for message handling is attributed to the signing domain, but whether > or not that signer is a malicious actor is out of scope of the > authentication mechanism. Since ARC aids message delivery in the > event of an authentication failure, ARC Sealers should be treated > with suspicion, so that a malicious actor cannot Seal spam or other > fraudulent messages to aid their delivery, too. > > > > > Andersen, et al. Expires January 18, 2019 [Page 21] > > > Internet-Draft ARC-Protocol July 2018 > > > 9.5. Replay Attacks > > Since ARC inherits heavily from DKIM, it has similar attack vectors. > In particular, the Replay Attack described in [RFC6376] section 8.6 > is potentially amplified by ARC's chained statuses. In an ARC replay > attack, a malicious actor would take an intact and passing ARC Chain, > and then resend it to many recipients without making any > modifications that invalidate the latest AMS or AS. The impact to a > receiver would be more DNS lookups and signature evaluations. This > scope of this attack can be limited by caching DNS queries and > following the same signing scope guidance from [RFC6376] section > 5.4.1. > > 10. IANA Considerations > > [[ *Note to the RFC Editors:* "dkim - header - s" is defined both > here and in [I-D-7601bis]. Please delete the overlap from whichever > document goes through the publication process after the other. ]] This directive suggests a problem in clarity about document relationship. This happens often in IETF specifications, where documents mutually cross reference, rather than establishing a clear hierarchical relationship. Very rarely, documents really are co-equal. I think this is /not/ such a case. My view is that rfc760bis has higher referential precedence and should therefore be the place for the cited definition. The ARC document should inherit that definition. > > This draft introduces three new headers fields and updates the Email > Authentication Parameters registry with one new authentication method > and several status codes. > > 10.1. Email Authentication Results Names Registry Update > > This draft adds one Auth Method with three Codes to the IANA "Email > Authentication Result Names" registry: > > o Auth Method : arc > Code: "none", "pass", "fail" > Specification: [I-D.ARC] 2.2 > Status: active > > 10.2. Email Authentication Methods Registry Update > > This draft adds several new items to the Email Authentication Methods > registry, most recently defined in [I-D-7601bis]: > > o Method: arc > Definition: [I-D.ARC] > ptype: smtp > Property: client-ip > Value: IP address of originating SMTP connection > Status: active > Version: 1 > > o Method: arc > Definition: [I-D.ARC] > > > > Andersen, et al. Expires January 18, 2019 [Page 22] > > > Internet-Draft ARC-Protocol July 2018 > > > ptype: header > Property: oldest-pass > Value: The instance id of the oldest validating AMS, or 0 if they > all pass (see Section 5.2) > Status: active > Version: 1 > > o Method: dkim > Definition: [RFC6376] > ptype: header > Property: s > Value: value of signature "s" tag > Status: active > Version: 1 > > 10.3. Definitions of the ARC header fields > > This specification adds three new header fields to the "Permanent > Message Header Field Registry", as follows: > > o Header field name: ARC-Seal > Applicable protocol: mail > Status: draft > Author/Change controller: IETF > Specification document(s): [I-D.ARC] > Related information: [RFC6376] > > o Header field name: ARC-Message-Signature > Applicable protocol: mail > Status: draft > Author/Change controller: IETF > Specification document(s): [I-D.ARC] > Related information: [RFC6376] > > o Header field name: ARC-Authentication-Results > Applicable protocol: mail > Status: standard > Author/Change controller: IETF > Specification document(s): [I-D.ARC] > Related information: [I-D-7601bis] > > 11. Experimental Considerations > > The ARC protocol is designed to address common interoperability > issues introduced by intermediate message handlers. Interoperability > issues are described in [RFC6377] and [RFC7960]. > > > > > > Andersen, et al. Expires January 18, 2019 [Page 23] > > > Internet-Draft ARC-Protocol July 2018 > > > As the ARC protocol is implemented by intermediary handlers over > time, the following should be evaluated in order to determine the > success of the protocol in accomplishing the intended benefits. > > 11.1. Success Consideration > > In an attempt to deliver legitimate messages that users desire, many > receivers use heuristic-based methods to identify messages that > arrive via indirect delivery paths. > > ARC will be a success if the presence of Authenticated Received > Chains allows for improved decision making when processing legitimate > messages. +1 > > 11.2. Failure Considerations > > ARC should function without introducing significant new vectors for > abuse (see Section 9). If unforseen vectors are enabled by ARC, then unforeseen > this protocol will be a failure. Note that weaknesses inherent in > the mail protocols ARC is built upon (such as DKIM replay attacks and > other known issues) are not new vectors which can be attributed to > this specification. > /d -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Aug 2 09:08: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 625FE130E1B for ; Thu, 2 Aug 2018 09:08: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 RbRqP2Zc6YSo for ; Thu, 2 Aug 2018 09:08:21 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::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 79A6D130E15 for ; Thu, 2 Aug 2018 09:08:21 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id d9-v6so4198918itf.2 for ; Thu, 02 Aug 2018 09:08: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=BIArsNHhObgWUg2MS2gVCbuY1NWM9T4wQlZlcQIe00g=; b=fv7MtN/vr2wzfV5YgZ4RQs4lNY3Jyz4exQNXQ/SID+tw6ft0kl2wSaZP6e4ravCWra HoLrJOnZtqrgTmTitOzEKGeYi6sSoIoWiV0PI124VCZhHxuraivvo0N9O7ZSn/AehSfQ MczDK1uNr56Mh4LnLqhs0Y4/mk11dJsy2bUt/8SZAxNXyYndYEcnxwvRZiq1c8yqAfZY uaC9U3VypLALrpWIcmb+aEVlstMunPmMJ/wPuhhvFjO4EUaKaA0fp/hr/OU/tK3JuORQ FvDzhIdGyVdPPEu71nCD1KkWPS8taJDILh1dsJvK/IvlMfq+bkvH5HfOy3vN9u7VWQ8q ugCg== 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=BIArsNHhObgWUg2MS2gVCbuY1NWM9T4wQlZlcQIe00g=; b=fva2NPsBRqwXYTKnFpU2Z43owS1bP/cAp7yBBZgjaOmhc3eo6GCSsw0ey4iGWjijy0 k4eHwm3ud6zUPQBbNqgDnCk2aCNLGgNUnzyvyLScFi7ETAhcqTy0ed4pEbdriq9V7Qqj qUSQiWFUPJixzI9LOew/XfTSER7FrEKUzJK4tjNzvJqLdHZRuBQsvjNqqFEs+IsvntOp jmDwHKUe9+sV3MG1evWp81/vECDARrlD667JOfoTXOuCi+aVNyX256TFPWRsOieYCHDI YmClryq6kpjfQwHrnM7cgPxa0t3kal/Vtsx5B5hfTvbdXgKAp+GcPaEO3i1OZFQcuqcl k0kw== X-Gm-Message-State: AOUpUlH8PSdIjJr6kHcSLqnpCaxopu6qCEbxojFVCvB1r0C3qoab8tdS stPWAfVXxAtEEtsaosiDWoLUb1aFFzHwcAKzO0afY4b6 X-Google-Smtp-Source: AAOMgpciSVU4nN+wa6aAqIk+dmMzNJwkzZoXsFa2m4ADoehzov/DgRXqgKUQTPYjjywR3wp41dDaHQV40tq6PD2br98= X-Received: by 2002:a02:687:: with SMTP id 129-v6mr86494jav.59.1533226100396; Thu, 02 Aug 2018 09:08:20 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:2646:0:0:0:0:0 with HTTP; Thu, 2 Aug 2018 09:07:59 -0700 (PDT) In-Reply-To: References: From: Seth Blank Date: Thu, 2 Aug 2018 09:07:59 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000132ef705727605c9" Archived-At: Subject: Re: [dmarc-ietf] Additional 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: Thu, 02 Aug 2018 16:08:23 -0000 --000000000000132ef705727605c9 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 2, 2018 at 6:43 AM, Dave Crocker wrote: > Continuing my review of: draft-ietf-dmarc-arc-protocol-16 > > NB: These are comments, not demands. Use however is helpful... Dave, thanks for these comments. I've quickly scanned your notes and nearly everything makes sense. I'll go through the document and make the changes you've recommended over the next day or so, and reply to this thread *where I have NOT* followed your suggestions so further conversation can be focused on just those areas. --000000000000132ef705727605c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Aug 2, 2018 at 6:43 AM, Dave Crocker <dcrocker@gmail.com> wrote:
Continuing my review of: draft-= ietf-dmarc-arc-protocol-16

NB:=C2=A0 These are comments, not demands. Use however is helpful...

Dave, thanks for these comments. I've quickly= scanned your notes and nearly everything makes sense.

=
I'll go through the document and make the changes you've recom= mended over the next day or so, and reply to this thread *where I have NOT*= followed your suggestions so further conversation can be focused on just t= hose areas.

--000000000000132ef705727605c9-- From nobody Fri Aug 3 04:03: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 33952130FBD for ; Fri, 3 Aug 2018 04:03:12 -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 qckkF9ybnPFD for ; Fri, 3 Aug 2018 04:03:05 -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 C7CA5130ECA for ; Fri, 3 Aug 2018 04:03:04 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id j8-v6so3763257lfb.4 for ; Fri, 03 Aug 2018 04:03:04 -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=+2VLkHyxEMp6B6/qvqyKWQRK0xdk6+2UXPYNsASZ5P8=; b=IyBYLzZgdCTOw282sxN6A/NAEajyqyn1b/yjExIjUGYnSfjNtR/6AP6brEhVYlelm/ jPGxzR47AeCPX0ho4grAFSGcDuYwlIGquoVqSOMN7+89WiVeTDRBqu1VSWsRI0xixAsp fkkARxttlgF6TzuPLB0WOxMbW4Y4XXG27xPBHQbn0Q6SfPjxBfCgFm+S95kI7Tzj0JPH Mib8rDl2QbisZaL6NmXXjdOKctFSRceIdAvxSgT8r2VF+DDQ6hMksrWibIZYNILmF53W 7P64/AhG+dqkf+2LP7KpeAVkkuRHhSMD2bd6aOTw0uINdbDtJcmFpO9f/uJhenlg3J0s YXMg== 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=+2VLkHyxEMp6B6/qvqyKWQRK0xdk6+2UXPYNsASZ5P8=; b=AgD1T0qvqpv3p05U7lWtTx5M7oTA+/+CeJqIILMBNS/cW+POP9OTxF2gPQA+NarVTs 7vlBxzYh9OBBupvTK8pm0bsIvvnMGpw5LXtE9WP+RyQwoHmcvOtZcthD6UKQHJfwhMO9 1y8eWzz8trJBAPGS2p62IFeNlAGzd1xmOJ6CgIK7sfUGyhXghA3tRqhUFOMtGZLBl5nm +8Ihc5ROH3Ff9F1LfVcf13FXeQSopmVH28QaHpVtZwxizoJDfQrkhjoifDbgLR/rFQhh SL87TnXrlavVRfyvC9xAAmmAb3oPFqY5ZMG28JgP3U6uBbjbiblOBrEhRgLWo7lTktwL 2RXg== X-Gm-Message-State: AOUpUlFG0DL1TzXMxKmKa/k1bXvgUjPCuKQhuaqtKlJ2gWDgaw0zjX1C 1W61l8+GBB6hwC4xpWVD6pMcqGJjWdgtxmQQKgSR928A X-Google-Smtp-Source: AAOMgperL9b65RcEEYFcsf8ouyJ95XDJ2TEH+s8eZLpKkNssHVCiTUScXuJdPad2rMpSj3LmXxdZpguI35fl8QPXpls= X-Received: by 2002:a19:eb1b:: with SMTP id j27-v6mr4559217lfh.0.1533294182807; Fri, 03 Aug 2018 04:03:02 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:3a13:0:0:0:0:0 with HTTP; Fri, 3 Aug 2018 04:03:01 -0700 (PDT) In-Reply-To: References: <91473b01-3bee-8e3f-58b0-7f444e58a19d@tana.it> From: "Murray S. Kucherawy" Date: Fri, 3 Aug 2018 04:03:01 -0700 Message-ID: To: Alessandro Vesely Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000001a3ea7057285df94" 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: Fri, 03 Aug 2018 11:03:12 -0000 --0000000000001a3ea7057285df94 Content-Type: text/plain; charset="UTF-8" To the rest of the WG: Is there consensus to make this change or the others being proposed? I feel like we're making a lot more edits here than the WG intended to make. It's fine if the WG wants to turn this into a larger editorial pass, but I thought the updates here were tightly scoped before, namely just enough to allow ARC to do what it needs. I'm inclined to resist, absent consensus, any changes that are other than (a) something ARC needs, or (b) something clearly incorrect. On Wed, Aug 1, 2018 at 5:16 AM, Alessandro Vesely wrote: > >> 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? > > Being proportional works both ways. You can estimate the quality from the > accuracy of the content, then you can trust the field content (of a > different > method or message) based on what you learned about that operator. > How is a receiver supposed to go about estimating the quality of something? This is starting to feel a lot like either scope creep or philosophical ruminating (or both). Do we really want to get into things like that in this document? >>>> *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 meant something like so: > > The list of commands eligible for use with the "smtp" ptype can be > found in Section 4.1 of [SMTP]. To report an SMTP command name 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.). > > > I'm also not clear on what problem you're trying to solve. > > No problem. That reorder and merge is just a marginal hint to improve > readability. > I'd like to know what the WG thinks here as well. > 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? > > No, it is not broken, AFAICS. Rather, it's better than previous versions, > where the "policy" ptype was overloaded beyond clarity, from covering > unregistered properties, to overriding methods' results, to catchall for > any > property not extracted directly from the message session. > It has always been deliberately ambiguous, since we obviously can't specify all policy-based decision trees. But the intent has always been to identify situations where a method failed for a reason other than that method's defined algorithms reporting a failure result. >> 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. > > Agreed. However, my signing agent knows nothing about any AUTH= parameter > to > the MAIL FROM command. It just knows the (non-public) smtp.auth. What A-R > field should it write? > I would suggest not adding one at all. What is a downstream agent to do with a plain "auth=pass"? > 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. > > I beg to differ here. If the authentication token is syntactically equal > to > the [local-part of the] mailbox address, this can be considered as > substantial > data leakage, given that the mailbox address is public. > How would a verifier determine syntactical equivalence? IMHO, in a multi-host implementation where downstream agents need to acquire > smtp.auth, there should be a final agent to redact it before it crosses the > trust boundary. For example: > > Authentication-Results: example.net; auth=pass > smtp.auth=REDACTED@example.net > > Or, according to rfc6590 algorithm: > > Authentication-Results: example.net; auth=pass > smtp.auth=rZ8cqXWGiKHzhz1MsFRGTysHia4=@example.net > > Or just remove the header field entirely. Which is better? Also compare > with > varying values of From:: > > From: Bob+list@example.net > To: list@lists.example.com > Authentication-Results: example.net; auth=pass > smtp.auth=bob@example.net This is almost certainly scope creep. What do others think? Both dkim=fail and dkim=policy are valid ways to override the method's > algorithmic result. To exemplify the preferred way is fine for me. > Ah, the example is wrong. Will fix it. -MSK --0000000000001a3ea7057285df94 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To the rest of the WG: Is there consensus to make this change or the o= thers being proposed?

I feel like we're making a lot more edits here than the WG intended to= =20 make.=C2=A0 It's fine if the WG wants to turn this into a larger editor= ial=20 pass, but I thought the updates here were tightly scoped before, namely=20 just enough to allow ARC to do what it needs.

I= 9;m inclined to resist, absent consensus, any changes that are other than=20 (a) something ARC needs, or (b) something clearly incorrect.

=
On Wed, Aug 1, 2018 at 5:16 AM, Alessandro Vesely <vesely@tana.it> wrote:
>>=C2=A0 =C2=A0 =C2=A0In tha= t case, if the producer intent is not to harm or mislead, the trust
>>=C2=A0 =C2=A0 =C2=A0in this field's content would be proportion= al to the estimated quality of
>>=C2=A0 =C2=A0 =C2=A0the producer's software.=C2=A0 Consumer'= ;s wisdom is key.
>
> How is a receiver to know anything about the estimated quality of the =
> producer's software?

Being proportional works both ways.=C2=A0 You can estimate the quali= ty from the
accuracy of the content, then you can trust the field content (of a differe= nt
method or message) based on what you learned about that operator.

How is a receiver supposed to go about estimatin= g the quality of something?

This is starting to fe= el a lot like either scope creep or philosophical ruminating (or both).=C2= =A0 Do we really want to get into things like that in this document?

>>>> *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 defin= ed by rfc7293, so
>>>> it can be omitted here.>>>
>>> It's not redundant.=C2=A0 MAILFROM and RCPTTO are not SMTP= verbs.
>>
>> Right, but their formation is well described in the relevant parag= raphs,
>> which I quote:>>
>>=C2=A0 =C2=A0 The list of commands eligible for use with the "= smtp" ptype can be
>>=C2=A0 =C2=A0 found in Section 4.1 of [SMTP].
>>
>>=C2=A0 =C2=A0 [...omitted paragraph here...]
>>
>>=C2=A0 =C2=A0 Where an SMTP command name is being reported as a &qu= ot;property", the
>>=C2=A0 =C2=A0 agent generating the header field represents that com= mand by
>>=C2=A0 =C2=A0 converting it to lowercase and dropping any spaces (e= .g., "MAIL FROM"
>>=C2=A0 =C2=A0 becomes "mailfrom", "RCPT TO" bec= omes "rcptto", etc.).
>>
>> Please note that a dumb reader might fail to derive that the latte= r
>> paragraph is constrained by the former.=C2=A0 (Perhaps reordering = and/or
>> merging might help.)>
>
> I'm not clear on how ordering helps here.=C2=A0 You need the two t= ogether
> regardless of order.

I meant something like so:

=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 To report an SMTP= command name as a
=C2=A0 =C2=A0"property", the agent generating th= e header field represents that
=C2=A0 =C2=A0command by converting it to lowercase and dropping any spaces = (e.g.,
=C2=A0 =C2=A0"MAIL FROM" becomes "mailfrom", "RCPT= TO" becomes "rcptto", etc.).

> I'm also not clear on what problem you'= ;re trying to solve.

No problem.=C2=A0 That reorder and merge is just a marginal hint to = improve readability.

I'd like to kn= ow what the WG thinks here as well.

> Keep in mind that this is now something like the four= th version of this
> document, and this has not been identified as a deficiency in any prio= r
> version.=C2=A0 Is this actually broken?

No, it is not broken, AFAICS.=C2=A0 Rather, it's better than pre= vious versions,
where the "policy" ptype was overloaded beyond clarity, from cove= ring
unregistered properties, to overriding methods' results, to catchall fo= r any
property not extracted directly from the message session.
<= div>
It has always been deliberately ambiguous, since we obvi= ously can't specify all policy-based decision trees.=C2=A0 But the inte= nt has always been to identify situations where a method failed for a reaso= n other than that method's defined algorithms reporting a failure resul= t.

>> This message is an example.=C2=A0 Unless removed,= it bears a header field like:
>>
>>=C2=A0 =C2=A0 =C2=A0Authentication-Results: tana.it; auth=3Dpass (details = omitted)
>>
>> It means I was SMTP-authenticated when I posted the message (other= wise it
>> wouldn't have been DKIM-signed.)=C2=A0 However, for obvious re= asons, I don't
>> want to disclose the userid I authenticated with.
>
> I think that's operationally a poor choice.

Agreed.=C2=A0 However, my signing agent knows nothing about any AUTH= =3D parameter to
the MAIL FROM command.=C2=A0 It just knows the (non-public) smtp.auth.=C2= =A0 What A-R
field should it write?

I would suggest = not adding one at all.=C2=A0 What is a downstream agent to do with a plain = "auth=3Dpass"?

> 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.=C2=A0 If you managed to authenticate as the identi= ty in the
> From: field, that's a lot more interesting than if you authenticat= ed as
> something unrelated; the fact that the filter adding this left out tha= t key
> piece of information almost makes it useless.

I beg to differ here.=C2=A0 If the authentication token is syntactic= ally equal to
the [local-part of the] mailbox address, this can be considered as substant= ial
data leakage, given that the mailbox address is public.

How would a verifier determine syntactical equivalence?

IMHO, in a multi-host implementation where downstream agents need to acquir= e
smtp.auth, there should be a final agent to redact it before it crosses the=
trust boundary.=C2=A0 For example:

=C2=A0 =C2=A0 Authentication-Results: example.net; auth=3Dpass
=C2=A0 =C2=A0 =C2=A0 =C2=A0smtp.auth=3DREDACTED@example.net

Or, according to rfc6590 algorithm:

=C2=A0 =C2=A0 Authentication-Results: example.net; auth=3Dpass
=C2=A0 =C2=A0 =C2=A0 =C2=A0smtp.auth=3DrZ8cqXWGiKHzhz1MsFRGTysHia4=3D@= ex= ample.net

Or just remove the header field entirely.=C2=A0 Which is better?=C2=A0 Also= compare with
varying values of From::

=C2=A0 =C2=A0 From: Bob+list@exam= ple.net
=C2=A0 =C2=A0 To: list@lists.exam= ple.com
=C2=A0 =C2=A0 Authentication-Results: example.net; auth=3Dpass
=C2=A0 =C2=A0 =C2=A0 =C2=A0smtp.auth=3Db= ob@example.net

This is almost certainly= scope creep.=C2=A0 What do others think?

Both dkim=3Dfail and dkim=3Dpolicy are valid ways to ove= rride the method's
algorithmic result.=C2=A0 To exemplify the preferred way is fine for me.

Ah, the example is wrong.=C2=A0 Will fix = it.

-MSK
--0000000000001a3ea7057285df94-- From nobody Fri Aug 3 07:26:00 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 93F76131027 for ; Fri, 3 Aug 2018 07:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 gfQtG-vhc7Nk for ; Fri, 3 Aug 2018 07:25: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 020B3131026 for ; Fri, 3 Aug 2018 07:25:55 -0700 (PDT) Received: (qmail 235 invoked from network); 3 Aug 2018 14:25:53 -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; 03 Aug 2018 14:25:53 -0000 Received: by ary.qy (Postfix, from userid 501) id 64F4B200339D5B; Fri, 3 Aug 2018 10:25:52 -0400 (EDT) Date: 3 Aug 2018 10:25:52 -0400 Message-Id: <20180803142553.64F4B200339D5B@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] 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: Fri, 03 Aug 2018 14:25:58 -0000 In article you write: >-=-=-=-=-=- > > To the rest of the WG: Is there consensus to make this change or the >others being proposed? Not that I've seen. I thought we agreed to make changes to support ARC, to handle EAI, and to fix any actual errors. Other than that, leave it alone. R's, John > >I feel like we're making a lot more edits here than the WG intended to >make. It's fine if the WG wants to turn this into a larger editorial pass, >but I thought the updates here were tightly scoped before, namely just >enough to allow ARC to do what it needs. > >I'm inclined to resist, absent consensus, any changes that are other than >(a) something ARC needs, or (b) something clearly incorrect. > >On Wed, Aug 1, 2018 at 5:16 AM, Alessandro Vesely wrote: > >> >> 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? ... From nobody Fri Aug 3 07:36:21 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 F2E6F131029 for ; Fri, 3 Aug 2018 07:36:19 -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 jgwJnQfrodUN for ; Fri, 3 Aug 2018 07:36:18 -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 16C7212DD85 for ; Fri, 3 Aug 2018 07:36:18 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id s198-v6so10147022oih.11 for ; Fri, 03 Aug 2018 07:36:18 -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=7D83oh6EtDZAz0fvqHw6Kp3YnE/4pUv7y2YqS+ON488=; b=GeRmLHZPtLNHkGDRU1ONLDZjMwB8kq8Jc/xznRQuaD17Gi6gHkTbelOyboYO4qRZZb nhN7uafz5eIRjiKsDQV9S7tBTceDN2pQVxP2lS4B0PMCj3MUmOg9zlFumwVtao/qBVjt npEY0DXnvoO2Lqulxqiu+B+ZqTY3bIPuWDB0P7ItmcmG1tzjm3fq38/KcbX0O28a3v19 ItTaZa21HxwVgkfdI0ZnVp7U4TOQo9ZNdmvHQr3XWJeog9CpXiUR5EJFYwE14UqqZv5W fyh667XZdIDgrwDBcWvYv44E5iaDNABuM79a4WXz1KzLYw0AQyB/fJDpERWnLug4qH/1 6Vrg== 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=7D83oh6EtDZAz0fvqHw6Kp3YnE/4pUv7y2YqS+ON488=; b=slK6vV3K+uMqFGkJllffNdnllZFX531RvQDtuOLkRkPfmXl/STQRUVh8KjIlumiWI1 lFrPEhBOHSt9u6geQesX10M97J0UxkS1ZuvfmyJ9nE9wou/AgIhXXG8ywyAq2F0Z6n63 lB+oNSsG+2s7QboDRXlIKnh4nXNQUTrfrVHX2F5Sl+tHqK1oizwWxjbDqJvkVF3JENlj jEkhRss1AIgw1eMPX45plnfgt85ZM/HV1/RQl5dBimkni8qFhwPLw7rv9GLzyAycyLKI njL19ozhEtVx3BTnDXtJZEU5LboxK88kJTmnWRiXi5RRJeLz6BRKYuVReJjUXmOnkbm7 3UTw== X-Gm-Message-State: AOUpUlFulT5iPGDvZ/1DAuU/swW7BTMe8MFULnBaIm9PNoPRKvYzA3sy tPJYYDHdZ48nG3ebNLOMKY9w2pu7ASEdjeQN+T9pi168 X-Google-Smtp-Source: AAOMgpfI5ezd36/lmVCG5UicBwyRe7TB5oCB82a5LIkc610hWj51Q9NmQSNq5BCVOcAZzXhrwcZr7Hh30EYXoVp7/wE= X-Received: by 2002:aca:cdc2:: with SMTP id d185-v6mr3672043oig.350.1533306976973; Fri, 03 Aug 2018 07:36:16 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:2646:0:0:0:0:0 with HTTP; Fri, 3 Aug 2018 07:35:56 -0700 (PDT) In-Reply-To: <20180803142553.64F4B200339D5B@ary.qy> References: <20180803142553.64F4B200339D5B@ary.qy> From: Seth Blank Date: Fri, 3 Aug 2018 07:35:56 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000b1d110057288d96c" 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: Fri, 03 Aug 2018 14:36:20 -0000 --000000000000b1d110057288d96c Content-Type: text/plain; charset="UTF-8" On Fri, Aug 3, 2018 at 7:25 AM, John Levine wrote: > > > To the rest of the WG: Is there consensus to make this change or the > >others being proposed? > > Not that I've seen. I thought we agreed to make changes to support ARC, to > handle EAI, and to fix any actual errors. Other than that, leave it alone. +1. ARC, EAI, and errors only. --000000000000b1d110057288d96c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Aug 3, 2018 at 7:25 AM, John Levine <johnl@taugh.com> wrot= e:
> To the rest of the WG: Is there consensus to make this change or the >others being proposed?

Not that I've seen.=C2=A0 I thought we agreed to make changes to= support ARC, to
handle EAI, and to fix any actual errors.=C2=A0 Other than that, leave it a= lone.

+1. ARC, EAI, and errors only.
<= /div>
--000000000000b1d110057288d96c-- From nobody Fri Aug 3 07: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 3FFF5131045 for ; Fri, 3 Aug 2018 07:52:12 -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 xx1Nu_Uus9EI for ; Fri, 3 Aug 2018 07:52:10 -0700 (PDT) Received: from mail-pf1-x441.google.com (mail-pf1-x441.google.com [IPv6:2607:f8b0:4864:20::441]) (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 A9280131041 for ; Fri, 3 Aug 2018 07:52:10 -0700 (PDT) Received: by mail-pf1-x441.google.com with SMTP id d4-v6so3384115pfn.0 for ; Fri, 03 Aug 2018 07:52:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=HqLvM5JvpOxL6DTumIX6W0JksIMK7p4qjQMme6dzuFg=; b=FoMLe4D+U0LQnRPFMjec6uZUENpcgtMlp3DGRT70h0Hf0GcwLMMzFyAFoZzZxNz828 1gnUcJRHxhW2DHfd8Qwq6EZM6DKWkuIopxrXSiFoAX572LoAeLTxXWCk7gtcUxagdwPs NTVjzKDdAPyRGQA13Zemu2o6X5pKOTYS18Q0T20UBWCEN+bE06r7zDrXFuHIYjvQVy4O yoDNaybZ1L9S/asQYffQ3kXXAV3MpfEf0wi55HPt2kajGOttqdNjCXgxgtdDM+QW7A7G 1G0ND824Pz7aLaj6bRi8umYrLn9uQA4VXllBNcynqpr2g9f89QL6zwj0w0eQVuMYlr/o qDVw== 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:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=HqLvM5JvpOxL6DTumIX6W0JksIMK7p4qjQMme6dzuFg=; b=PM+Iq1tycZWV/y2gC8UvStZ5uoz5XI7WKTsi+EBVi3YxHOHpkarDQ4QXypmqdWovcR dDW5C/Fyk7xLEfohhoBxRqUErRN4MV+vCUqKHFsc+o5LOvG7/SMQ8EQiwXbe8QigjrKR 4s5Rz+rs124PqC9S/lK0KlOcT9vzukQHUYZc8MSnTZlRNxjSDHOwQl7CTzA9UZ6GnLed TJDRBRNJsDfOX2Yuhvg5ylDqYf08PcXkP3jrFkqCExjuKNAIlqY0feIKyyl4kTZ2UwTY wDzj1yXooAdhQeyL3vFmz9yn7mkDDEkYNSoJdqkDbohaP9ksllwwy4IY9QJKuLnu8q6b fDlw== X-Gm-Message-State: AOUpUlHcNG4xcxtub8Lg+zUhM9SUaEQC2ChMPLySe/9iwvIQqmXao5cq X3+yK9b5Jw1YjAw0ae1wWawk1iFU X-Google-Smtp-Source: AAOMgpewKWZa9qr4MD4txNBhbLAl+ksB3zQp0dKoWafMXB0ITaOflvRMSAYLMKuTyZk0xXhWAD+p3Q== X-Received: by 2002:a63:d002:: with SMTP id z2-v6mr4209551pgf.262.1533307929676; Fri, 03 Aug 2018 07:52:09 -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 r81-v6sm7749650pfa.18.2018.08.03.07.52.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Aug 2018 07:52:08 -0700 (PDT) To: dmarc@ietf.org References: <20180803142553.64F4B200339D5B@ary.qy> From: Dave Crocker Message-ID: <033a8d8c-f2e6-7e66-597b-6686fc4444f9@gmail.com> Date: Fri, 3 Aug 2018 07:51:59 -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: 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: Fri, 03 Aug 2018 14:52:12 -0000 On 8/3/2018 7:35 AM, Seth Blank wrote: > On Fri, Aug 3, 2018 at 7:25 AM, John Levine > wrote: > > > To the rest of the WG: Is there consensus to make this change or the > >others being proposed? > > Not that I've seen.  I thought we agreed to make changes to support > ARC, to > handle EAI, and to fix any actual errors.  Other than that, leave it > alone. > > > +1. ARC, EAI, and errors only. +2 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Aug 3 10:16: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 BCA19130E21 for ; Fri, 3 Aug 2018 10:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 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, 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 fWx5jMAnREuX for ; Fri, 3 Aug 2018 10:16:44 -0700 (PDT) Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::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 0E68B130E06 for ; Fri, 3 Aug 2018 10:16:44 -0700 (PDT) Received: by mail-yb0-x22f.google.com with SMTP id y3-v6so2905637ybo.10 for ; Fri, 03 Aug 2018 10:16:43 -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=wXVD76FH6v220+Ez9uCQsZXfilQN8eGXEhUfJRee5+A=; b=g+zR/QD4ruSizTrHDLSHINb0VGwI0KDgxixwdYmNanG3JtZEoxZ3fnatujXgUKzmQs CwJsTR+5YYvz2xg1G33yugO59IOvv1UNAQeEHXDRKM5PDlwFgI4QsYHoVRw2eRsr0HBA XlQuZPbabhT3c4DmAXYaqBkTerzK3aW0pNyXFhl+2mulOhWBx+JxNJlNyh6Dgglj/yqJ ROGlaz4X8XhseXb1ZmaCSr2J5M0yZ+gbmoKZ2XX1kG0ACBA6ViUDPuXBShC0P9yE3bx8 lH9SlRmSa+0r5SJajMbT+9IlC3zhZDgOpGE5Pl+VV3gLIzUL/cn5DsJWagFiaWtLRGaf oqTw== 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=wXVD76FH6v220+Ez9uCQsZXfilQN8eGXEhUfJRee5+A=; b=dIeLvP0BYokZiuiWrmW/VtkTCu667ttanOuFSFmktQ9BnFk9ZyK5wOU95GgOeycGDQ x96MoJKZdcBpSAOKNJWpwlP622PY8isxVj73cLuiK7u5Uc6YFBK6g8wjsdVVIE7p5/hx iZdFPpHAqMUFFvckY3YFbvApEuV5v9k79ZpICo2ioH5+pWqdlompp2aoPlKAiM9rSA4O +gEXOjatrqHdR5/i3+4B0eeR24ltLWXELuzthaK1m5NTaPFdbI/kWbxR+ozxY0YtvvX7 OKYY3t5ArNGyLSz7l++Nqm9q6NC97/VkMdfGLRMGN+28/ZX137qJxhMzKlVQ7vpQBZIA RhJQ== X-Gm-Message-State: AOUpUlHp+Zu+rl8DocrDKIhEC66sY4MWUk6f9kOxvc4eCt1yd76rKszc TxXBphaLN1LBUqD7g1EbZDlN5evanmLwr8wKldiO X-Google-Smtp-Source: AAOMgpeU30XfHr3fGAy1xMPcQJsGezHPtK1maIASzCjaG9MnxivtrepzqkNBUv+45CFp7LDx196KnVOi3vMJ5EiVlhc= X-Received: by 2002:a25:860a:: with SMTP id y10-v6mr2482269ybk.327.1533316602650; Fri, 03 Aug 2018 10:16:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brandon Long Date: Fri, 3 Aug 2018 10:16:30 -0700 Message-ID: To: Dave Crocker Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="0000000000006e8e4505728b179d" Archived-At: Subject: Re: [dmarc-ietf] Additional 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: Fri, 03 Aug 2018 17:16:46 -0000 --0000000000006e8e4505728b179d Content-Type: text/plain; charset="UTF-8" On Thu, Aug 2, 2018 at 6:43 AM Dave Crocker wrote: > Continuing my review of: draft-ietf-dmarc-arc-protocol-16 > [snip] > > 6. Communication of Validation Results > > > > Chain Validation Status (described in Section 4.4) is communicated > > via Authentication-Results (and AAR) headers using the auth method > > "arc". This auth method is described in Section 10.1. > > > > If necessary data is available, the ptypes and properties defined in > > Section 10.2 SHOULD be recorded in an Authentication-Results header > > field: > > > > o smtp.client-ip - The connecting client IP address from which the > > message is received. > > this seems such a large privacy concern, I question allowing it here. > (This highlights the difference between passing information inside an > enterprise, vs. over the open Internet, across administrations.) > It is true that the privacy aspects of IP addresses are more concerning than they have been, but they also continue to be widely used in email message headers. For this particular case, the IP is the IP of the sending server, not the actual client. Perhaps that means the name is poorly chosen. Perhaps smtp.remote-ip? The IP of the sending server doesn't seem nearly as privacy sensitive as the IP of the sending user. Some folks have brought up that there may still be some geographic hints from this if the sending service has servers in multiple regions, but that's a much smaller privacy concern that I think is out-weighed by the utility of having it here. Especially considering that it's already in the Received and Received-SPF headers. Also, it is obviously optional, is SHOULD the wrong choice? I guess there is a slight increase over the existing uses in that the value is signed and therefore has more signal than the other uses which could all be faked. That seems to point more to the "plausible deniability" privacy points, which arguably DKIM and ARC make more challenging (ie, with the Clinton email leaks, the Gmail ARC signature proved the message was intact as Gmail received it, and the DKIM signature proved the message was sent by the campaign). I don't think there is consensus on that type of privacy. For our internal design docs, we'd certainly highlight these things in the privacy section and the separate privacy design doc, I'm not sure where this would go in an rfc, the security section? Or just a privacy section? Brandon --0000000000006e8e4505728b179d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu= , Aug 2, 2018 at 6:43 AM Dave Crocker <dcrocker@gmail.com> wrote:
Continuing my review of: draft-ietf-dmarc-arc-protocol-16

[snip]
=C2=A0
> 6.=C2=A0 Communication of Validation Results
>
>=C2=A0 =C2=A0 Chain Validation Status (described in Section 4.4) is com= municated
>=C2=A0 =C2=A0 via Authentication-Results (and AAR) headers using the au= th method
>=C2=A0 =C2=A0 "arc".=C2=A0 This auth method is described in S= ection 10.1.
>
>=C2=A0 =C2=A0 If necessary data is available, the ptypes and properties= defined in
>=C2=A0 =C2=A0 Section 10.2 SHOULD be recorded in an Authentication-Resu= lts header
>=C2=A0 =C2=A0 field:
>
>=C2=A0 =C2=A0 o=C2=A0 smtp.client-ip - The connecting client IP address= from which the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0message is received.

this seems such a large privacy concern, I question allowing it here.
(This highlights the difference between passing information inside an
enterprise, vs. over the open Internet, across administrations.)

It is true that the privacy aspects of IP address= es are more concerning than they have been,
but they also continu= e to be widely used in email message headers.

For = this particular case, the IP is the IP of the sending server, not the actua= l client.=C2=A0 Perhaps that
means the name is poorly chosen.=C2= =A0 Perhaps smtp.remote-ip?=C2=A0 The IP of the sending server
do= esn't seem nearly as privacy sensitive as the IP of the sending user.= =C2=A0 Some folks have brought up
that there may still be some ge= ographic hints from this if the sending service has servers in multiple reg= ions,
but that's a much smaller privacy concern that I think = is out-weighed by the utility of having it here.=C2=A0 Especially
considering that it's already in the Received and Received-SPF headers= .

Also, it is obviously optional, is SHOULD the wr= ong choice?

I guess there is a slight increase ove= r the existing uses in that the value is signed and therefore has more sign= al than the
other uses which could all be faked.=C2=A0 That seems= to point more to the "plausible deniability" privacy points, whi= ch arguably DKIM and ARC make more challenging (ie, with the Clinton email = leaks, the Gmail ARC signature proved the message was intact as Gmail recei= ved it, and the DKIM signature proved the message was sent by the campaign)= .=C2=A0 I don't think there is consensus on that type of privacy.
For our internal design docs, we'd certainly highlight these things i= n the privacy section and the separate privacy design doc, I'm not sure= where this would go in an rfc, the security section?=C2=A0 Or just a priva= cy section?

Brandon
--0000000000006e8e4505728b179d-- From nobody Fri Aug 3 10:24: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 CE9FB131070 for ; Fri, 3 Aug 2018 10:24:36 -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, 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 Wv-n6hKAZrxY for ; Fri, 3 Aug 2018 10:24:35 -0700 (PDT) Received: from mail-yw1-xc32.google.com (mail-yw1-xc32.google.com [IPv6:2607:f8b0:4864:20::c32]) (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 D8CD113106B for ; Fri, 3 Aug 2018 10:24:34 -0700 (PDT) Received: by mail-yw1-xc32.google.com with SMTP id l189-v6so1240102ywb.10 for ; Fri, 03 Aug 2018 10:24:34 -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=pOzJw23Qc9QXlKJM2mbTeLmN2CGKTOwm7wvDXzL1/ck=; b=rEQ983nNayfbedf0FNG3kWliBcViXXBxgLbohRECGnsuH/Tqq8PmHE1P9r/SXa0iyD yAXm2Q00AzeM2M3U3y83qBT1zdezIXgbU7DeGlSN+1irzvsR/CCeS86N0C7hjYSaTqUD XGHwHKDQ8M0o/PwuGhanfR/dc64EkQtG/HSTOUjVjtESuTMR/y1wxBw+BFvZGJMUkT6u 48OwYBVT/rLzc16+/mVmBqAnP5Zz525NKPxLwCP/Mp+yoCYpDqJYonuGnnr3XB7lZlat fZlfQIPRVzpjegtK2bkqGo+6nCocf5FpZZMeXm22o0MgNqHjEIAJBhzVcLPasn1tAjqh +RFw== 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=pOzJw23Qc9QXlKJM2mbTeLmN2CGKTOwm7wvDXzL1/ck=; b=qrCrC+sIJm3ENAIKKeHp+WNr7xnIhNTJ6jk/ZBad3WmQvKOQjv5zGQGiKBYrk+tgmF Of9xmPbYL7XAeRC1D5/QAhA57AZjpozg6vQTkSJ7hcd0UYAjB6gRHkSJUwD1tVPB5R32 Qbpi8ZuJ3+fczSguoXtQ8LIr6GZM6QC4cMrzE3mal8FHztXTOsNfwwGCMQ/JRdcg1y8I r6/nesxrHLHvxLxvL2q3hwJiDsAbuw38ejkBBeFk5XLMcDVZgZmppB9/ZFEN+GPb8nPA 8AiEhimB/G5PpvtjO2Rl9H1SMd1Qidv/Cvzgh6Ql+x0xfcilp6TJLogxNuFYPvJQfqxD 3Yeg== X-Gm-Message-State: AOUpUlFx+VlU0NphxG2L7tGS9p3iTYMgHhO80H9FqERGAEqnHh24gR3C UjR+QtfsKnUOKy3YxTfJW/WswVuGbYsKhAf0epFTO9c= X-Google-Smtp-Source: AAOMgpdQOV4VN4mDGV8fsVOhotN9f43IzZle1F8ocSPDIUDfEU8eLR7TDs2bo/EWSljcg1dmWBUP4S7DDkFmNw1odz8= X-Received: by 2002:a0d:e501:: with SMTP id o1-v6mr2615168ywe.409.1533317073506; Fri, 03 Aug 2018 10:24:33 -0700 (PDT) MIME-Version: 1.0 References: <20180730221726.713CE200316625@ary.qy> In-Reply-To: From: Brandon Long Date: Fri, 3 Aug 2018 10:24:21 -0700 Message-ID: To: John Levine Cc: Seth Blank , dmarc@ietf.org Content-Type: multipart/alternative; boundary="0000000000007f20b105728b33ec" 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, 03 Aug 2018 17:24:37 -0000 --0000000000007f20b105728b33ec Content-Type: text/plain; charset="UTF-8" I know I lost the argument on cv (I think cv is entirely superfluous and there's no point adding/signing a cv=fail header), but it seems the argument for that is more data. That said, this "either or" signing set thing on cv=fail seems pretty cumbersome. Brandon On Mon, Jul 30, 2018 at 5:42 PM John R Levine wrote: > > 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 > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --0000000000007f20b105728b33ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I know I lost the argument on cv (I think cv is entirely s= uperfluous and there's no point adding/signing a cv=3Dfail header), but= it seems the argument for that is more data.=C2=A0 That said, this "e= ither or" signing set thing on cv=3Dfail seems pretty cumbersome.
=
Brandon

On Mon, Jul 30, 2018 at 5:42 PM John R Levine <johnl@taugh.com> wrote:
> The working group considered cv=3Dinvalid last year, bu= t 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 C= hains
> should be Sealed in the same fashion (your AS covers the ARC Set you&#= 39;ve
> added and all previous ARC Sets), unless the Chain is invalid in which= case
> you only Seal your own ARC Set.

Ah.=C2=A0 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.=C2=A0 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 f= ollowing 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=3D 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.=C2=A0 I would take out steps 5-7 and add something to the INFORMATIONAL at the end like "A validator can check<= br> the AMS headers to estimate when in a chain of forwards the message
was modified."


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
--0000000000007f20b105728b33ec-- From nobody Fri Aug 3 10:54: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 4AB62131084 for ; Fri, 3 Aug 2018 10:54:05 -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 H4srms1akhsl for ; Fri, 3 Aug 2018 10:54: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 536DA131088 for ; Fri, 3 Aug 2018 10:54:03 -0700 (PDT) Received: (qmail 83355 invoked from network); 3 Aug 2018 17:54:02 -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; 03 Aug 2018 17:54:02 -0000 Date: 3 Aug 2018 13:54:01 -0400 Message-ID: From: "John R Levine" To: "Brandon Long" Cc: dmarc@ietf.org 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: Fri, 03 Aug 2018 17:54:05 -0000 > I know I lost the argument on cv (I think cv is entirely superfluous and > there's no point adding/signing a cv=fail header), but it seems the > argument for that is more data. That said, this "either or" signing set > thing on cv=fail seems pretty cumbersome. You guys have looked at as many ARC signatures as anyone. Once the chain has a cv=fail do you learn anything useful from further seals? R's, John >> 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." From nobody Fri Aug 3 10:56:00 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 1432D131088 for ; Fri, 3 Aug 2018 10:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 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, 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 cH17WqiZ1K-d for ; Fri, 3 Aug 2018 10:55:57 -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 8B7D0131084 for ; Fri, 3 Aug 2018 10:55:57 -0700 (PDT) Received: by mail-yb0-x235.google.com with SMTP id h127-v6so2940776ybg.12 for ; Fri, 03 Aug 2018 10:55:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=5UQA9EG7YrXii/H4GeqjwiRtixg769t2Z+hDpA5nuTM=; b=cumIvHbdBwbQdyKY8qUt9JJW8522f3upTab64hutKGKBeXjKFAhL4pfroskSxVG3qa UYlyfMhP4LmF5RiGQe3j0KQ/AQXH9l9sYOM6ngSak4WQ+t4fTgj8IxvFtoSQVGInoVgB yGZ75ODX9KGBqc2ysi8qzh4fl4FvqW5PMk062jqQaugtWv5fafKCof9KcL5HmSf/dBy0 FgueCPXEVhs+QYijo8wQnX6MygMS7PY246UARrA+gT1NnNUQZGq9mUBwq1GDRJdBqdHE HmWzmyAQTk+oYm7QrGVad1NE17CJ481DCryEwTxXS8oeuZ+zLOPoEjiJZnh/CXWGF4da ut+Q== 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=5UQA9EG7YrXii/H4GeqjwiRtixg769t2Z+hDpA5nuTM=; b=WPZw0RFv0mpW/76gv9aT4auWhVCn+4pkcvKpLiFWamlSRKl68un8BPc0BVaRACMbXq 57FfMqPXNEoVik4x3xyKHrFSok3u/sonFCDfcejoqhvjyHh0f0xStFAHFFDMiPWDx3jZ V4uuq7aMFStt6Dtd6Dz4gVAQQUpAVv36hI75gB5OjUI4w9wFYZwigUmCxBV5ZLpzebXN 20v3AAmRLiC87hQP0j//nDRPaBC+hy3kug4L/jbf90RGrHsV3QAd2dA5ia5gA/Ba0fhq NSeK1CDJjhVD4K6WRo5GgOpxR0gwMTEUDl6ymc4mW9VQwV4rAF1PeEFazybk245YRLFW PgHw== X-Gm-Message-State: AOUpUlHG6zoHrwEMraAuiREZLHh06SB7yVPJSpw9b1VLsb2nTlddOehP LR4lUddwYg+pomJnNWUayP9A/GTbwzT3nGtTV9bkDdQ= X-Google-Smtp-Source: AAOMgpfa04w9GgJdsZhgab+KlY/Q7DYuCeS6DsG37KF4LK85whN5efny73WodAFKiiECOO5APa959qqGv6LluQ6s+OA= X-Received: by 2002:a25:a167:: with SMTP id z94-v6mr2673302ybh.8.1533318956028; Fri, 03 Aug 2018 10:55:56 -0700 (PDT) MIME-Version: 1.0 From: Brandon Long Date: Fri, 3 Aug 2018 10:55:44 -0700 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="000000000000b45e5105728ba351" Archived-At: Subject: [dmarc-ietf] WGLC 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: Fri, 03 Aug 2018 17:55:59 -0000 --000000000000b45e5105728ba351 Content-Type: text/plain; charset="UTF-8" LGTM modulo some of the discussions already in progress Brandon --000000000000b45e5105728ba351 Content-Type: text/html; charset="UTF-8"
LGTM modulo some of the discussions already in progress

Brandon
--000000000000b45e5105728ba351-- From nobody Fri Aug 3 11:00: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 8E4ED13108C for ; Fri, 3 Aug 2018 11:00:35 -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 YJOHEmd2Q-YI for ; Fri, 3 Aug 2018 11:00:33 -0700 (PDT) Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::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 A4A1E131084 for ; Fri, 3 Aug 2018 11:00:33 -0700 (PDT) Received: by mail-yb0-x233.google.com with SMTP id i9-v6so2964299ybo.5 for ; Fri, 03 Aug 2018 11:00:33 -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=SO3PkzrKgDhIAFsWgucJ6yGTc390+Q0S8c9w6C1gD1A=; b=khar2lqcUZD9m1ZIJhWQOw1VL3uFqNwzQlUhOti4kwsORJmzObi91QYnNsVhcmpJhr 7fNiN+NKEhiTSdyG7M8/fXQBCprhZWCLTcmsyDGXd+bhDODBGh/iFwoBsDdsgUla/ekk Hde3PDdoxYxYPuZGBEMCPEy8Dq1YpGy2ycWwGWNlsO3rFxDXqXGebRXoOpj+/7PIbxtO 0FQYzpgk0EUoNAmMT3VttpWFNmN8+euOr8yWt+7/HVv7UJ6oKWUsA/R8uHtwfWBMzo3i sXWNVTG4qDVJeYo88465qtpNG/R8KNSFGIbmW5ganrNxWJaQ/KRhN5+PO40Fo7JazgZL rr8Q== 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=SO3PkzrKgDhIAFsWgucJ6yGTc390+Q0S8c9w6C1gD1A=; b=RwiIITi4RacZx/6tJlW/+MAywTMWmSCVcUUfhyJ17R/C651G02C1bIqhQWSPUt0YmM mfOl0bJ5WK4Gw+/pu8dokBvja81dgpxPysVln8lKfvz+LE0s66O4AgAmTBfD+ItRpYZY cGQ/0Wv4t24cei3yL8bc+skjFo0erjlCq+ntaHZ8pmFhYeWJF4wEboPwQeKJExhGZCh3 HZpwrWB79oqf/wvrO6DekMEOTuXzEHn5GEKFQxzJeCOH6/zBmBmk3gi+Eo/zGzTbl2N3 xywRIHhqdePoSecs6WoVNBa532NicIvgO0rXMWKLcFyFMUkkuj9xMWxlDBn6RzDtjgXA TOmQ== X-Gm-Message-State: AOUpUlGEt0//HhQDha2mfbJbv2x1whI4QI/anoe/J/llJ0qkeMV3eAQG d2pYfLPV+XDTRqsRPIXIcZ8RtlXO3jxdokcdsCccmo0= X-Google-Smtp-Source: AAOMgpcwhkE+HQE0V67vq01QtOvsNZtWObBjuc53vT9/yEYr5DvTUgcvZKtjIQ4vZkZ6mFXO3AbA5pEYeQHkqOI8WjI= X-Received: by 2002:a25:860a:: with SMTP id y10-v6mr2573191ybk.327.1533319232210; Fri, 03 Aug 2018 11:00:32 -0700 (PDT) MIME-Version: 1.0 References: <20180730221726.713CE200316625@ary.qy> In-Reply-To: From: Brandon Long Date: Fri, 3 Aug 2018 11:00:18 -0700 Message-ID: To: John Levine Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="0000000000002a9ab905728bb463" 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, 03 Aug 2018 18:00:36 -0000 --0000000000002a9ab905728bb463 Content-Type: text/plain; charset="UTF-8" Currently, we don't do anything with failed chains short of keeping stats. Everything we've used the chain for so far has been from passing chains. That said, we still only trust our own chain elements, we haven't seen wide enough adoption to spend much effort on interpreting chains which involve multiple parties. Brandon On Fri, Aug 3, 2018 at 10:54 AM John R Levine wrote: > > I know I lost the argument on cv (I think cv is entirely superfluous and > > there's no point adding/signing a cv=fail header), but it seems the > > argument for that is more data. That said, this "either or" signing set > > thing on cv=fail seems pretty cumbersome. > > You guys have looked at as many ARC signatures as anyone. Once the chain > has a cv=fail do you learn anything useful from further seals? > > R's, > John > > >> 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." > --0000000000002a9ab905728bb463 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Currently, we don't do anything with failed chains sho= rt of keeping stats.=C2=A0 Everything we've used the chain for so far h= as been from passing chains.

That said, we still only tr= ust our own chain elements, we haven't seen wide enough adoption to spe= nd much effort on interpreting chains which
involve multiple part= ies.

Brandon

On Fri, Aug 3, 2018 at 10:54 AM John R Levine <johnl@taugh.com> wrote:
> I know I lost the argument on cv (I think = cv is entirely superfluous and
> there's no point adding/signing a cv=3Dfail header), but it seems = the
> argument for that is more data.=C2=A0 That said, this "either or&= quot; signing set
> thing on cv=3Dfail seems pretty cumbersome.

You guys have looked at as many ARC signatures as anyone.=C2=A0 Once the ch= ain
has a cv=3Dfail do you learn anything useful from further seals?

R's,
John

>> In 5.2, oldest pass is confusing, since it doesn't tell you wh= ether
>> the validation succeeds or not.=C2=A0 I would take out steps 5-7 a= nd add
>> something to the INFORMATIONAL at the end like "A validator c= an check
>> the AMS headers to estimate when in a chain of forwards the messag= e
>> was modified."
--0000000000002a9ab905728bb463-- From nobody Fri Aug 3 11:04: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 74426131093 for ; Fri, 3 Aug 2018 11:04:50 -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 iu9YCCbFI9vE for ; Fri, 3 Aug 2018 11:04:48 -0700 (PDT) Received: from mail-pl0-x22e.google.com (mail-pl0-x22e.google.com [IPv6:2607:f8b0:400e:c01::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 CA66F13108E for ; Fri, 3 Aug 2018 11:04:48 -0700 (PDT) Received: by mail-pl0-x22e.google.com with SMTP id ba4-v6so2877035plb.11 for ; Fri, 03 Aug 2018 11:04:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=M5OkaSYZuVLTUCBNeEYNUXCq967Bwj23HVgAiAvZzyQ=; b=O2PVUJhnkYAa3/g+Mb4tFJc1v++uzBoxrsXuIcFkuFtdgnQ5eWXQLHmRTJFOATfm4A nyoHkTRo32W/d1tZ0roG2b7PhdlCmLO/lABsBxmIMAd0+PkYbmY84Xpx/YrRBBbOJ+yR nE2KupfyFq4RkDgbc4ngedfmE0UEsFo6ygJIcntG0gSNdKlZqxuRQwXJFjWyP0w/8Yva tdEN5haTmEj8lAXU6oTxobk5mus1ebsGmhESujLUvXCV22CANtTjSFNLbcivqEICM1/3 fSWyItvkwvC4515GS3E4t8rQ4wQB+26dtMV2FcGZEjse/k//7K2Iv8LYCOlfVPM3j9Ar kC3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=M5OkaSYZuVLTUCBNeEYNUXCq967Bwj23HVgAiAvZzyQ=; b=ftYg6d324largUzL01vlhvAw4Gh80sz07gRy9NTMHaMlHijA2RaFegIGtnAWg5YeA1 hvyaPb+ZvG82mi3/3ZC6Z2/MagyUgsss9w10mLKhEKkNDkIeEIxB1XobdL5SMO/DKG+V 92jzqhqBT6C2WqqoFukX4ueLbrXCt1x9YcohBCSXmOGTQyDTKIZNS2NqHHANnbROlhVu KOd2v58ykCM8dD1EZHcXHhw8jEd5K2q99iqsijdIkZsKGLJbB+0YvAzD3AeB11WUSNc0 YDGsvQkflqTuigbDaEgX4kN6PWwaXTyoUNxvCeewx+ued07X4dCsobzNf1+NoE8ce52L Oqog== X-Gm-Message-State: AOUpUlHnnMBFrE3hqlAQKyJJKQ5hT2SVEAoTEHfEkq4Ba1/gv83BJe/b 3hLyJZmxbERUInh1BUVZAujWn0bX X-Google-Smtp-Source: AAOMgpczg1uBEc0rbGensh6aYrsB36qY4pucN28Ci1IW56kyElyMe8cf5EIFQOCPwYuC4KJfUG2P+w== X-Received: by 2002:a17:902:7b96:: with SMTP id w22-v6mr4568602pll.24.1533319487783; Fri, 03 Aug 2018 11:04:47 -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 z4-v6sm11924026pfl.11.2018.08.03.11.04.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Aug 2018 11:04:46 -0700 (PDT) To: Brandon Long Cc: dmarc@ietf.org References: From: Dave Crocker Message-ID: <333edf96-39b9-21c9-2c2c-bb95a90dcc8e@gmail.com> Date: Fri, 3 Aug 2018 11:04:43 -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: 8bit Archived-At: Subject: Re: [dmarc-ietf] Additional 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: Fri, 03 Aug 2018 18:04:51 -0000 On 8/3/2018 10:16 AM, Brandon Long wrote: > >    o  smtp.client-ip - The connecting client IP address from > which the > >       message is received. > > this seems such a large privacy concern, I question allowing it here. > (This highlights the difference between passing information inside an > enterprise, vs. over the open Internet, across administrations.) > > > It is true that the privacy aspects of IP addresses are more concerning > than they have been, > but they also continue to be widely used in email message headers. At a minimum, I suggest clear and relatively forceful language, making clear the privacy concerns. (Privacy is new enough and, frankly, fuzzy enough as a technical topic, to warrant the redundancy I usually argue against...) > For this particular case, the IP is the IP of the sending server, not > the actual client.  Perhaps that > means the name is poorly chosen.  Perhaps smtp.remote-ip?  The IP of the oh. yeah. 'client' seems the right technical term, absent a much longer string like 'initiating' (and I am not sugesting it.) Perhaps change the explanatory text to something like: The address of the initiating SMTP server, from which the message is being relayed. > sending server > doesn't seem nearly as privacy sensitive as the IP of the sending user. > Some folks have brought up > that there may still be some geographic hints from this if the sending > service has servers in multiple regions, That highlights the challenges of all things labeled 'privacy concern'. And it's why I think noting issues where they occur AND summarized in a privacy considerations section is warranted. > but that's a much smaller privacy concern that I think is out-weighed by > the utility of having it here.  Especially > considering that it's already in the Received and Received-SPF headers. > > Also, it is obviously optional, is SHOULD the wrong choice? Yes. The semantics of should is 'must do this, unless you are extremely careful and know exactly what you are doing'... So MAY is probably the right choice. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Aug 3 11:44: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 6979A1310B0 for ; Fri, 3 Aug 2018 11:44:54 -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 blMoiNk6g1Du for ; Fri, 3 Aug 2018 11:44:52 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::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 40C671310DA for ; Fri, 3 Aug 2018 11:44:52 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id f8-v6so5736870ljk.1 for ; Fri, 03 Aug 2018 11:44:52 -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=wAjaBYdZeKmLEtsWFzVGh7o/88+8AznZJbWWmmiMM7g=; b=fxCs+MBIN2/omGZVYngWEfqbDk7j7OpPUrdvlyowgx9oUsOFqIIVv2WyVUGqX87vPH AICFys0MMdhxtlFl9Pw5Knbi2rMhxjNpiFO5bdlk6LSA9+LYuTOMmBmuwN0bAVuN70Vo GSDDcpzNMLoiXKS4wIkTEAfvDMIm3E9nNAo9w= 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=wAjaBYdZeKmLEtsWFzVGh7o/88+8AznZJbWWmmiMM7g=; b=FHHfLyhyPcfKidXY9LB0rww/z1MZEZFxQSJ2OcGIqknWxQoDK8Q1uGccqJSUL07Z4C 2rdfzcBi6k6Y0eupbDEZp+3tP8llmCVC3GogufiH8LuEYS3kEihXhaoBF+YEFCqNu0GV Y53rmLVsV+uhry9qwDcxDD2I+hnOqN9PVRDr6bwHQcmiBjLSTyeH/n97nWnLr7Yx0Jcc mqYfDkpbtiFpzZImiXrYYRkBbUauTQLwr9hqdhKubG4SnNRb4WPzdWBjsZPPmAV/MMyE n4K2MVz69COV9K1ArLPznYxiBaNS3XqNyyGdwGrkzQX7CNM1NJoPMwi0ToMfp1rx09Ct IwIQ== X-Gm-Message-State: AOUpUlGWtGEhOaXmFxBgaqhrRi5YuEAU8q/TFO6+CRVOvw8QrhAGExJc d3NepvoGjjox3wrkd1qLfEAceGygcUyWWt8v1LRlAQ== X-Google-Smtp-Source: AAOMgpfzLB+GuAy+mbEmgr4KkOzOnfD8xIBh3AEgmj6Bz8nCUYWe0oHpZbcb0GsC2619Mqj8qop4B/jB0IUdH3u+zxY= X-Received: by 2002:a2e:9f4d:: with SMTP id v13-v6mr6056177ljk.42.1533321890426; Fri, 03 Aug 2018 11:44:50 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 2002:a19:5943:0:0:0:0:0 with HTTP; Fri, 3 Aug 2018 11:44:49 -0700 (PDT) In-Reply-To: References: <20180803142553.64F4B200339D5B@ary.qy> From: "Kurt Andersen (b)" Date: Fri, 3 Aug 2018 11:44:49 -0700 X-Google-Sender-Auth: tv_jR5xwc8ZAiVq1oNmojikWFik Message-ID: To: Seth Blank Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000009b0e6c05728c52ab" 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: Fri, 03 Aug 2018 18:44:58 -0000 --0000000000009b0e6c05728c52ab Content-Type: text/plain; charset="UTF-8" On Fri, Aug 3, 2018 at 7:35 AM, Seth Blank wrote: > On Fri, Aug 3, 2018 at 7:25 AM, John Levine wrote: >> >> > To the rest of the WG: Is there consensus to make this change or the >> >others being proposed? >> >> Not that I've seen. I thought we agreed to make changes to support ARC, >> to >> handle EAI, and to fix any actual errors. Other than that, leave it >> alone. > > > +1. ARC, EAI, and errors only. > Ditto --0000000000009b0e6c05728c52ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Aug 3, 2018 at 7:35 AM, Seth Blank <seth@sethblank.com>= wrote:
On Fri, Aug 3, 2018 = at 7:25 AM, John Levine <johnl@taugh.com> wrote:
> To the rest of the WG: Is there consensus to make this change or the >others being proposed?

Not that I've seen.=C2=A0 I thought we agreed to make changes to= support ARC, to
handle EAI, and to fix any actual errors.=C2=A0 Other than that, leave it a= lone.

+1. ARC, EAI, and errors only.=

Ditto=C2=A0
<= /div>
--0000000000009b0e6c05728c52ab-- From nobody Fri Aug 3 14:55: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 4F4E81310E6 for ; Fri, 3 Aug 2018 14:55:30 -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=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 cTOHGxpdhh9O for ; Fri, 3 Aug 2018 14:55:28 -0700 (PDT) Received: from mail-yw1-xc2b.google.com (mail-yw1-xc2b.google.com [IPv6:2607:f8b0:4864:20::c2b]) (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 845361310E3 for ; Fri, 3 Aug 2018 14:55:28 -0700 (PDT) Received: by mail-yw1-xc2b.google.com with SMTP id c135-v6so1523084ywa.0 for ; Fri, 03 Aug 2018 14:55:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eudaemon.net; s=dkey; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=Zrl4c+dNFQ6jz82ZW1LK8kAOaB2uAXVaLS//QbNhnLE=; b=c+igdfyegYGlaUR2GU6/SVivgJno0m3UfErFxnF/tILLTywZruUq/+93mVTZF7tSW9 evb1Vi00UdcuB+2ryh0P1DdAm5c6OdysTLjGFEz6yQXlB837dQzHf8h9zqnzFXhkfaAq hPskN0eid9YdXdfJruHGdxeiu/nUUUOBV7sKE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=Zrl4c+dNFQ6jz82ZW1LK8kAOaB2uAXVaLS//QbNhnLE=; b=ArzB+My8Mlj3FAmMjQrzMelkqF66Uu48L1rgfqjNZo2W8SVYmuB5GVz3SfsaoQJmip sIxwUbumI17Cr433V+JLP72ESu4ShVrYHtMDgRi63LKrGvFnsE81+en6PxWNBdyjDDtH wBV0RpzpSMvlwAe5S2C5ArAByU3oVqdrHv9+d6PIXJhtxVb2HeW4umBOSGd/kyBktMgb EdE3EiMwdtDow5O7zqjrrVBfP9olQpo+yIaNJ0Y8FKDyav1cxU/3G6Vp7UaMBQZGC9m7 kTFXLFNtG4nCqXYcovYodSOSuZB02RJ8LJORE5gonAkilZijtOeeLyAof0gDNhO2G4d3 2Y7w== X-Gm-Message-State: AOUpUlGI19cITFBGAtej5e7n5DJLCv9crwlsFDWn1rf/+4K/hIKHDE8v Cs+Cx5P5iS0tCE2Bl4S3aynk1bgaPVI= X-Google-Smtp-Source: AAOMgpdp4lq2mnHyvRxAtydKeBi81DaMT+9TphrV+JYFVNGofETR116bFokbQF5w7zvSPO0SjviNwA== X-Received: by 2002:a81:eb01:: with SMTP id n1-v6mr3177108ywm.448.1533333327199; Fri, 03 Aug 2018 14:55:27 -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 z190-v6sm2849863ywd.97.2018.08.03.14.55.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Aug 2018 14:55:26 -0700 (PDT) From: Tim Draegen Content-Type: multipart/alternative; boundary="Apple-Mail=_0D0B0A37-1A39-4956-8727-8BB58EC8D7B1" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 3 Aug 2018 17:55:24 -0400 References: <91473b01-3bee-8e3f-58b0-7f444e58a19d@tana.it> To: dmarc In-Reply-To: Message-Id: <53941325-880C-4506-92B8-C8026F88BC95@eudaemon.net> 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: Fri, 03 Aug 2018 21:55:30 -0000 --Apple-Mail=_0D0B0A37-1A39-4956-8727-8BB58EC8D7B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Aug 3, 2018, at 7:03 AM, Murray S. Kucherawy = wrote: >=20 > I feel like we're making a lot more edits here than the WG intended to = make. It's fine if the WG wants to turn this into a larger editorial = pass, but I thought the updates here were tightly scoped before, namely = just enough to allow ARC to do what it needs. I supplied a list of editorial + bug fixes. IMO there's a fuzzy line = between fixing errors, removing ambiguity, and de-torturing sentences = for future readers. I'm also a fan of using tight scoping to keep focus, but need to point = out that this WG has relaxed scope in the past to take on far more = challenging work. Given that no document is ever taken on purely for = editorial fixes, I'm OK with correcting the confusing bits while the = door is open. -=3D Tim --Apple-Mail=_0D0B0A37-1A39-4956-8727-8BB58EC8D7B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On = Aug 3, 2018, at 7:03 AM, Murray S. Kucherawy <superuser@gmail.com>= wrote:

I feel like we're making a lot = more edits here than the WG intended to make.  It's fine if the WG = wants to turn this into a larger editorial pass, but I thought the = updates here were tightly scoped before, namely just enough to allow ARC = to do what it needs.

I supplied a list of editorial + bug fixes. IMO there's a = fuzzy line between fixing errors, removing ambiguity, and de-torturing = sentences for future readers.

I'm also a fan of using tight scoping = to keep focus, but need to point out that this WG has relaxed scope in = the past to take on far more challenging work. Given that no document is = ever taken on purely for editorial fixes, I'm OK with correcting the = confusing bits while the door is open.

-=3D Tim



= --Apple-Mail=_0D0B0A37-1A39-4956-8727-8BB58EC8D7B1-- From nobody Fri Aug 3 16:14: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 52D2A130E6B for ; Fri, 3 Aug 2018 16:14:11 -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 PJAsCt4iJl46 for ; Fri, 3 Aug 2018 16:14:09 -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 AF09B130DD3 for ; Fri, 3 Aug 2018 16:14:09 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id n21-v6so12703662oig.3 for ; Fri, 03 Aug 2018 16:14:09 -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=3D1FY51xx5NGooawGyjXlihA1GO4sBK1rHRBcN+9jJs=; b=Up/cBVOAO33A0aZ3JgeaPsq0bZByNFkSXEHjSMOXiRr9j8G2yguG4NjJfkQz/2Rf0v 6BDomSJGAM7DZtbnv32iyvHrDSFhmyqQG7nkcI93sYibQRKsYFTeJIDJJ3YdqBHm7iRj Hu0nqBXv4ELJKoMvilP5FhjoGOAOoBe6F6nTO+gSKyIhMWL8VIxibdsUKh0YnHx6E1lG QU35NX3kaLcRBmYpXSwW++xASMzlQXKBO5jrqdjNTT88MWdzyjJgjbTu2g2ZsSLXpltB M59EvH7wW4qSk6jrFdv4ItIMRviUyaCHWN5JbaAyLKF+tlNHmEIfWK5Yzsf2hbp0Iehh JAIA== 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=3D1FY51xx5NGooawGyjXlihA1GO4sBK1rHRBcN+9jJs=; b=lYjluxJIuP4WkdXOMHlpfVCYPwmsa8ibwYvk7ZkGZ1/P5DR9wZLV7eaqcZDHF0TrmF 88dvgMN3qlzyVkn+/5ogl4V9ArMIOTd1rerb+fyhcgYHwJ52Q64p9DoG5Ja/9TlMSfXm 9JdG7BBroBEohaBrEsSH92JC7vIj1FGQW88FHmIiZgxDrN3fsVFljCHTqio2oVRmLdQ6 NPhOTQNaSGdUBJjLY/YdHhSnBQM7w6Mg5cvotiipVSzS9rrZaJE0iS6oFtL8YkzxdmZM +zqOtysEMF7bvIRtYMWySfuiDvo9RUvL2sHy1GHDGrg5PgIWEUSGX73hu5C7RoA8PTqR N/Mg== X-Gm-Message-State: AOUpUlFMDWPC92FqICcxeOLF0xruqS98G9eTQGtZ3G0GCaWrUudvgek3 8hBqobB1suL4JhrjMNeFpZm2d0kPVbruRbtroh1Z1Ofh X-Google-Smtp-Source: AA+uWPwDHyyspYVntcUMl3inU16q6w342SVzb9ybd76MH/iCX4QZr/ctw7ETPYS1fbTh66FMFCIzUiACyyBI3TiKxkU= X-Received: by 2002:aca:d9c5:: with SMTP id q188-v6mr4889534oig.239.1533338048574; Fri, 03 Aug 2018 16:14:08 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:2646:0:0:0:0:0 with HTTP; Fri, 3 Aug 2018 16:13:47 -0700 (PDT) In-Reply-To: References: <20180730221726.713CE200316625@ary.qy> From: Seth Blank Date: Fri, 3 Aug 2018 16:13:47 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000b4d7200572901543" 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, 03 Aug 2018 23:14:11 -0000 --000000000000b4d7200572901543 Content-Type: text/plain; charset="UTF-8" On Fri, Aug 3, 2018 at 11:00 AM, Brandon Long < blong=40google.com@dmarc.ietf.org> wrote: > Currently, we don't do anything with failed chains short of keeping > stats. Everything we've used the chain for so far has been from passing > chains. > Especially as an Experiment, I think it's important to sign even failing chains, especially for the reasons I've already enumerated. Otherwise, the above scenario - only data from passing chains is usable - is the only possible scenario. This seems myopic, especially when we don't yet know what the real world landscape will look like. --000000000000b4d7200572901543 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Aug 3, 2018 at 11:00 AM, Brandon Long <blong=3D40goo= gle.com@dmarc.ietf.org> wrote:
Currently, we don't do anything with failed chains= short of keeping stats.=C2=A0 Everything we've used the chain for so f= ar has been from passing chains.

Espe= cially as an Experiment, I think it's important to sign even failing ch= ains, especially for the reasons I've already enumerated. Otherwise, th= e above scenario - only data from passing chains is usable - is the only po= ssible scenario. This seems myopic, especially when we don't yet know w= hat the real world landscape will look like.
--000000000000b4d7200572901543-- From nobody Fri Aug 3 16: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 017EC131123 for ; Fri, 3 Aug 2018 16:27:24 -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 0Ms9bRuVRTh3 for ; Fri, 3 Aug 2018 16:27:22 -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 03D65131120 for ; Fri, 3 Aug 2018 16:27:22 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id v8-v6so12706474oie.5 for ; Fri, 03 Aug 2018 16:27: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=kXzR6sMMGuc5XnJz9JE6VmRETlgDM7/Oqwr7opc7O+E=; b=Ed4Y9dpSBwZa0469L1sEjm++dT+2E4O7oZ8Qh1XW/67mM9IuUL84LjhbUjH36APy/f taG4sXDyNFlOevb1eQMEHu2I8lM9hDEH7zmv5aCjkt5G2dMlgoR9bY++xEzSUs50NElO yG8I6FSse6h9+Knmq6MJDe8h1LjjwHp9uCgO5N5FuI6m2403oh4t7i6o9aMF4Qx0k/Rh sfHniMjl9ErGDKu89d3W+o3ljEl7dA0pxYKpJdJc5NrVMnKuQBWYH253Hm2KWG4qolad IrTXhNh4szUrey6FE6Vf+UlQ6c8U2mNWX/XMYsZ0CforlRLzOeyCjZfSnbm18rtFgh3U zTow== 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=kXzR6sMMGuc5XnJz9JE6VmRETlgDM7/Oqwr7opc7O+E=; b=qkd4BuPqW0X3B/qccuHeYuOuZjzLukH8lforve4b7Gz5xGGIlaNKZ7YrHJP9JZ46eu 6qrUWHqjJ9M6qkDS7HFoRVqji0qb11vSbs3B5GE2sLkbCNlLZQRxHGKutmJiienp50k1 KumPYY940pPpW4h17XPjswIh28P3oWvRufyqeUqfp6BZ5KTeXsJiph5v4HnxdDZZm67d I+B3Knn+bgDykB7TgkHb5xc9CbEITHjyhJS6qHobURMF00/8iIQbjPwJiA0wNDqTsURG YuCiMR7twEn/eVNob+wCTe0a0fmY1Gr5/tY83GacVInThMoRe1Fe1U59OWMvC5cZe3bq Y+8Q== X-Gm-Message-State: AOUpUlE5cKfM+Oke84Aa69hJF2JSktmZdYQ1EYdIPizNVDP70XDXse5e tjGsgMFfw5IjuGJ6KTfd7ZVZbO5ACZhvQo4R1GbG+HIN X-Google-Smtp-Source: AA+uWPxA7aO7WwUmopYKCGqk3VV6XJdRgZ4S77CWyvSQxIL93sYwu4F+mqa6qDjStGQAOiMBkroljJOt6PQscxVdS+8= X-Received: by 2002:aca:d9c5:: with SMTP id q188-v6mr4922780oig.239.1533338840980; Fri, 03 Aug 2018 16:27:20 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:2646:0:0:0:0:0 with HTTP; Fri, 3 Aug 2018 16:27:00 -0700 (PDT) In-Reply-To: <333edf96-39b9-21c9-2c2c-bb95a90dcc8e@gmail.com> References: <333edf96-39b9-21c9-2c2c-bb95a90dcc8e@gmail.com> From: Seth Blank Date: Fri, 3 Aug 2018 16:27:00 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000efee1c0572904440" Archived-At: Subject: Re: [dmarc-ietf] Additional 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: Fri, 03 Aug 2018 23:27:24 -0000 --000000000000efee1c0572904440 Content-Type: text/plain; charset="UTF-8" On Fri, Aug 3, 2018 at 11:04 AM, Dave Crocker wrote: > > At a minimum, I suggest clear and relatively forceful language, making > clear the privacy concerns. (Privacy is new enough and, frankly, fuzzy > enough as a technical topic, to warrant the redundancy I usually argue > against...) > What would you suggest? Might this be better in "Experimental Considerations" instead of a "Privacy Considerations" section? (Or to your below comment, in both places?) > Perhaps change the explanatory text to something like: > > The address of the initiating SMTP server, from which the message is > being relayed. Will do. > but that's a much smaller privacy concern that I think is out-weighed by >> the utility of having it here. Especially >> considering that it's already in the Received and Received-SPF headers. >> >> Also, it is obviously optional, is SHOULD the wrong choice? >> > > Yes. The semantics of should is 'must do this, unless you are extremely > careful and know exactly what you are doing'... > > So MAY is probably the right choice. As a receiver of reports, this IP is crucial information, because otherwise the message source is badly obfuscated by intermediary handling. This in turn becomes deeply confusing to a domain owner trying to effectively *do something* with the reports they receive. The feedback loop here is critical, and is incomplete without the IP. However, not every entity that ARC Seals has access to this information (for instance, Mailman uses LMTP and has no direct access to the IP of the incoming SMTP connection), which is why it is SHOULD. The intent is "must do this, unless you don't have the ability to or have other good reason." --000000000000efee1c0572904440 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Aug 3, 2018 at 11:04 AM, Dave Crocker <dcrocker@gmail.com> wrote:
At a minimum, I suggest clear and relatively forceful language, making clea= r the privacy concerns.=C2=A0 (Privacy is new enough and, frankly, fuzzy en= ough as a technical topic, to warrant the redundancy I usually argue agains= t...)

What woul= d you suggest?

Might this be better in "Exper= imental Considerations" instead of a "Privacy Considerations"= ; section? (Or to your below comment, in both places?)
=C2=A0
Perhaps change the explanatory text to something like:

=C2=A0 =C2=A0The address of the initiating SMTP server, from which the mess= age is being relayed.

Will do.
= =C2=A0
but that's a much smaller privacy concern that I think is out-weighed b= y the utility of having it here.=C2=A0 Especially
considering that it's already in the Received and Received-SPF headers.=

Also, it is obviously optional, is SHOULD the wrong choice?

Yes.=C2=A0 The semantics of should is 'must do this, unless you are ext= remely careful and know exactly what you are doing'...

So MAY is probably the right choice.

As a r= eceiver of reports, this IP is crucial information, because otherwise the m= essage source is badly obfuscated by intermediary handling. This in turn be= comes deeply confusing to a domain owner trying to effectively *do somethin= g* with the reports they receive. The feedback loop here is critical, and i= s incomplete without the IP.

However, not every en= tity that ARC Seals has access to this information (for instance, Mailman u= ses LMTP and has no direct access to the IP of the incoming SMTP connection= ), which is why it is SHOULD. The intent is "must do this, unless you = don't have the ability to or have other good reason."
<= /div>
--000000000000efee1c0572904440-- From nobody Fri Aug 3 19:23: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 9B09E130DE3 for ; Fri, 3 Aug 2018 19:23: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 bRficrMzvp7l for ; Fri, 3 Aug 2018 19:23:26 -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 3476B130DBE for ; Fri, 3 Aug 2018 19:23:26 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id v8-v6so13141140oie.5 for ; Fri, 03 Aug 2018 19:23: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=QmeIkQBPnBc/ezo8qvJLf/149pdmbqqiSxvudsmfrQo=; b=N01bXBsnQ9+pw0fgdNiBOXJXa/2CMd6XzI17w3MklEHXvB3OKS6zoHvZw7LS3Ypymz Q8dcD/JcQW+0zGFXdRgCQsGxhqET8gYA4NYqK3f/DT24VTEgPy20PQf4oY8/p5sPhEsP uIvsFZNzjqPvkL2o2Fl5UvETSrklU7bZnPFSOe1bYlGRQQ7ZXhINxzMi/1uyWu/fsbdK SCrQa+p3KBijzbq5CUtZOil2ReVb0WUYbUU+aG/llHdvhQ6nXu9U4YiTpeB0tdL48IWS p6opOEstkxSl9o7uGlLLJ7X87btsVhDBWd2/SncpNj/A0iMJ9kHBH67vFO5912K4axyZ fxCg== 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=QmeIkQBPnBc/ezo8qvJLf/149pdmbqqiSxvudsmfrQo=; b=IUHpFb/uJqt4c92uh681CbBro/ks2foubiXaN9ir7xwlssCy05iJRmOMn50T6I/ZqY 6CNjXfaDsEwikF/aW8T8hgm2CQYb0SQWBXP41JL/uWrJG5j0KqsSCk7RTdskrU4u0Jy2 SKWfytT3MPTdbHgBFjBLwun+4i7KFG0z2vfaewUysV/Avj2wPHqTZHfTT1lWaDWzE78y tbbWtn225pXA96uPKjH5VluAt8hAVFJX718dEObUZ8sadQPz0eARdDkZErgyhj4yU7dV 34r3bVmDariYxk+9co+ztPtrOjlqPM4/6cL61uWoKOgiK9IQd0oPq9lKkEdz+oiCEFHR RkUg== X-Gm-Message-State: AOUpUlG5Ycu3X7A8qW7A9hzLHMhUnZkXPUGBTU/ie8svUirYcdJMLpXh yyhepKFmJwiHOkgr5KKW9vV8KJUKrGc/i/ExgeiolOQR X-Google-Smtp-Source: AAOMgpdwNwylO9EPxYXL3UPAcIx9Rxhl6A9CRnbm87q1J6DTAlMcPPZZq0/2NFWD1Y+SgXS7PUkC0rnBbzjo3cLmxPg= X-Received: by 2002:aca:cdc2:: with SMTP id d185-v6mr6054592oig.350.1533349405110; Fri, 03 Aug 2018 19:23:25 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:2646:0:0:0:0:0 with HTTP; Fri, 3 Aug 2018 19:23:04 -0700 (PDT) In-Reply-To: References: From: Seth Blank Date: Fri, 3 Aug 2018 19:23:04 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000009bc986057292ba85" Archived-At: Subject: Re: [dmarc-ietf] Additional 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: Sat, 04 Aug 2018 02:23:29 -0000 --0000000000009bc986057292ba85 Content-Type: text/plain; charset="UTF-8" As stated previously, I've made all stated changes, with the exception of the below, for further discussion: On Thu, Aug 2, 2018 at 6:43 AM, Dave Crocker wrote: > 4. Protocol Elements >> > > > I keep thinking that it would help to have some summary text, possibly > with a figure, that shows the role of individual header fields and sets of > them. > > My first inclination is to suggest putting it here, but perhaps it would > actually be better to have it at the /end/ of this section, after each > component has been defined. > > (I'd offer some candidate text/figure, but I am not sure I have a solid > enough sense of the details.) > This is a good suggestion, but form is unclear. Any guidance from the working group would be appreciated. > To preserve the ability to verify the integrity of a message, the >> > signature of the AMS header field SHOULD include any DKIM-Signature >> header fields already present in the message. >> > > Arguably, including it/them does NOT alter integrity validation. i suspect > /ever/. At the least, be explicit about /what/ integrity is being maintain. > > That is, the dkim signature provides a specific kind of integrity. If it > validates, that integrity is proved. If it doesn't, it isn't. covering it > by ARC doesn't affect either outcome. > This feels more like guidance than a requirement for interoperability. Should it be moved into ARC-USAGE, or further clarified the way suggested? > _INFORMATIONAL:_ The upper limit of 50 was picked based on some > > initial observations reported by early working group members with a >> safety margin multiple added on top to support the vast majority of >> all intermediary mail flows. >> > > Rather than citing a wg process, document the technical, administrative > and/or operation concerns, benefits, etc. that justify the choice. > I think this is OK for an Experimental draft, especially with the callout in 11.3.2. For standards track clarification will be essential. > Valid ARC Sets MUST have exactly one instance of each ARC Header >> field (AAR, AMS, and AS) for a given instance value and signing >> algorithm. >> >> _INFORMATIONAL:_ Initial development of ARC is only being done with a >> single allowed signing algorithm, but parallel work in the DCRUP >> working group is expanding that. For handling multiple signing >> algorithms, see [ARC-MULTI]. >> > > As a rule, RFCs should not refer to parallel activities, since the > reference is soon to become stale and wrong. > > If additional signing algorithms are anticipated -- and of course they > should be -- then define a means for extending what is permitted, noting > that the initial algorithm is provided to ensure basic, initial > interoperability. > Understood. Earlier consensus was that this is fine for the experiment (as algorithm rotation is irrelevant if the experiment fails), and that requirements for rotation would be part of a final standards track document. Should these INFORMATIONAL items just be ripped out in the meantime? --0000000000009bc986057292ba85 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As s= tated previously, I've made all stated changes, with the exception of t= he below, for further discussion:

On Thu, Aug 2, 2018 at 6:43 AM, Dave Crocker <dcrocker@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
4.=C2=A0 Protocol Elements


I keep thinking that it would help to have some summary text, possibly with= a figure, that shows the role of individual header fields and sets of them= .

My first inclination is to suggest putting it here, but perhaps it would ac= tually be better to have it at the /end/ of this section, after each compon= ent has been defined.

(I'd offer some candidate text/figure, but I am not sure I have a solid= enough sense of the details.)


This is a good suggestion, but form is unclear. Any guidance from th= e working group would be appreciated.

=C2=A0
=
=C2=A0 =C2=A0= To preserve the ability to verify the integrity of a message, the
=C2=A0 =C2=A0signature of the AMS header field SHOULD include any DKIM-Sign= ature
=C2=A0 =C2=A0header fields already present in the message.

Arguably, including it/them does NOT alter integrity validation. i suspect = /ever/.=C2=A0 At the least, be explicit about /what/ integrity is being mai= ntain.

That is, the dkim signature provides a specific kind of integrity.=C2=A0 If= it validates, that integrity is proved.=C2=A0 If it doesn't, it isn= 9;t. covering it by ARC doesn't affect either outcome.
=

This feels more like guidance than a requirement for in= teroperability. Should it be moved into ARC-USAGE, or further clarified the= way suggested?

=C2=A0
=C2=A0 =C2=A0_INFORMATIONAL:_ The u= pper limit of 50 was picked based on some
=C2=A0 =C2=A0initial observations reported by early working group members w= ith a
=C2=A0 =C2=A0safety margin multiple added on top to support the vast majori= ty of
=C2=A0 =C2=A0all intermediary mail flows.

Rather than citing a wg process, document the technical, administrative and= /or operation concerns, benefits, etc. that justify the choice.

I think this is OK for an Experimental draft, es= pecially with the callout in 11.3.2.=C2=A0For standards track clarif= ication will be essential.

=C2=A0
=C2=A0 =C2=A0Valid ARC S= ets MUST have exactly one instance of each ARC Header
=C2=A0 =C2=A0field (AAR, AMS, and AS) for a given instance value and signin= g
=C2=A0 =C2=A0algorithm.

=C2=A0 =C2=A0_INFORMATIONAL:_ Initial development of ARC is only being done= with a
=C2=A0 =C2=A0single allowed signing algorithm, but parallel work in the DCR= UP
=C2=A0 =C2=A0working group is expanding that.=C2=A0 For handling multiple s= igning
=C2=A0 =C2=A0algorithms, see [ARC-MULTI].

As a rule, RFCs should not refer to parallel activities, since the referenc= e is soon to become stale and wrong.

If additional signing algorithms are anticipated -- and of course they shou= ld be -- then define a means for extending what is permitted, noting that t= he initial algorithm is provided to ensure basic, initial interoperability.=

Understood. Earlier consensus was that= this is fine for the experiment (as algorithm rotation is irrelevant if th= e experiment fails), and that requirements for rotation would be part of a = final standards track document.

Should these INFOR= MATIONAL items just be ripped out in the meantime?
--0000000000009bc986057292ba85-- From nobody Fri Aug 3 22:04: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 38237130E21 for ; Fri, 3 Aug 2018 22:04: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 (2048-bit key) header.d=crash.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 24aqCngRvNVG for ; Fri, 3 Aug 2018 22:04:20 -0700 (PDT) Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) (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 A24C0130E07 for ; Fri, 3 Aug 2018 22:04:20 -0700 (PDT) Received: from [172.23.119.8] ([216.52.21.1]) (authenticated bits=0) by segv.crash.com (8.15.2/8.15.2/cci-colo-1.7) with ESMTPSA id w7454B4c004515 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sat, 4 Aug 2018 05:04:20 GMT (envelope-from smj@crash.com) DKIM-Filter: OpenDKIM Filter v2.10.3 segv.crash.com w7454B4c004515 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1533359060; bh=2Ey707q4mPuNDN1nU9fj8RV7zsrq+8jB/pYJsthwK40=; h=From:Subject:To:References:Date:In-Reply-To; b=BE35r9GeCXa6L/c++yETVvyqZu7xjn8GISt/Bx3yGe7LTtaChN6HiQQmxGU7hlkyi iz2zYThgs21c/AKp+jI0+qSjDkPf6vWY1dmDHzQ8zyzrS9gegYh1jzjA2zsZFjMVVY nAyXkSSe3ahQxFR+rgUx+GJ6mXuD/r2lAvwSef6fw0aC7lkjdFCaDTXJerxauaU63I GZ4Z43KeviRh1F4+7zaWKtemVOXocLRgLT2wIeS+aHMXJHi2Urq7yHgeLpJfHxuAmb SqrIqW501E9FMaVMzXIJ7JEL4CKwyU7cDki768yc/6XagWy7MbapnDqLHijusmvLX1 rbuzKBu34ZOlQ== X-Authentication-Warning: segv.crash.com: Host [216.52.21.1] claimed to be [172.23.119.8] From: Steven M Jones To: dmarc@ietf.org References: Message-ID: <3af55e32-b05f-76fb-4ab6-005ad0619530@crash.com> Date: Fri, 3 Aug 2018 22:04:11 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (segv.crash.com [72.52.75.15]); Sat, 04 Aug 2018 05:04:20 +0000 (UTC) Archived-At: Subject: Re: [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: Sat, 04 Aug 2018 05:04:22 -0000 It's been quite a while since my last full read-through of the spec, so apologies if I blunder into anything long-settled. And apologies if I'm repeating something from earlier commentary, I'm trying to get in under a very liberal interpretation of the deadline as is... ;) Love the way Section 2 introduces and describes the basics. Section 3.1 - I would suggest "the three header fields /from a particular Internet Mail Handler/ compose a single ARC Set." (Addition in /slashes/.) Best to be explicit that ARC sets are organized by (outdated term) ARC Intermediary. Or "Sealer," but that would be a forward reference... But without this, the reader might be left scratching their head until Section 5.1 makes it clear that an ARC Set is created by a single entity. Section 4.2 - I would suggest "An `ARC Set` is a single collection of three ARC Headers (AAR, AMS, and AS) /from a single ARC Sealer/." Same reasoning as previous. Section 4.3 - Typo, "AS header fields allow messages handlers" - "messages" should lose the trailing "s" (or I suppose it could be modified to "allow a message's handlers" if that's what was intended...) Section 5.2 Step 1 -- Because of the preceding reference to maximum number of ARC Sets, rephrase for clarity at the end, "In the following algorithm, the /highest instance value ("i=") present in the ARC being processed is referred to as `N.`/" That's it. Great work -- what a long way this has come since oar-dev started up in 2014! --Steve. From nobody Sun Aug 5 08:11: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 5F8E6130E5B for ; Sun, 5 Aug 2018 08:11:47 -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 Snuvf4GGVB_I for ; Sun, 5 Aug 2018 08:11:45 -0700 (PDT) Received: from copdcmhout02.cable.comcast.com (copdcmhout02.cable.comcast.com [96.114.158.212]) (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 ABC55130E0F for ; Sun, 5 Aug 2018 08:11:45 -0700 (PDT) X-AuditID: 60729ed4-428c89e000006f94-dd-5b6713b4cb0b Received: from COPDCEX21.cable.comcast.com (copdcmhoutvip.cable.comcast.com [96.114.156.147]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by copdcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id 0C.E9.28564.4B3176B5; Sun, 5 Aug 2018 09:11:48 -0600 (MDT) Received: from COPDCEX19.cable.comcast.com (147.191.124.150) by COPDCEX21.cable.comcast.com (147.191.124.152) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Sun, 5 Aug 2018 09:11:43 -0600 Received: from COPDCEX19.cable.comcast.com ([fe80::3aea:a7ff:fe36:8380]) by COPDCEX19.cable.comcast.com ([fe80::3aea:a7ff:fe36:8380%19]) with mapi id 15.00.1365.000; Sun, 5 Aug 2018 09:11:43 -0600 From: "Brotman, Alexander" To: Barry Leiba , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] WGLC on draft-ietf-dmarc-arc-protocol-16 Thread-Index: AQHUHhT7hZlIgddOOkevjkZe5TQaA6SxT5pg Date: Sun, 5 Aug 2018 15:11:43 +0000 Message-ID: <29acb69012a449ae847a9d80d56e9cd3@COPDCEX19.cable.comcast.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [96.115.73.254] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplleLIzCtJLcpLzFFi42JJKJozWXeLcHq0wZ6V/BaHFl9itVhyaC2j A5NHy6peZo8lS34yBTBFNTDalGQUpSaWuKSmpeYVp9pxKWAAm6TUtPyiVNfEopzKoNSc1ETs ykAqU1JzMstSi/SxGqOP1ZyELqaM/f3z2Aruc1WsX3WVtYHxLUcXIyeHhICJxI49kxm7GLk4 hAR2Mkkc2DeBGcI5yCjx9/AvFgjnBKNE28NjrCAtbAJWEm//tzOD2CICPhIr/+8FiwsLOEns OfGPCSLuLHHv/EkWCNtIYtrveexdjBwcLAIqEsveFoKYvAJeEpM2WYFUCAkESHRdWMIOYnMK BEr8+3GKDcRmFBCT+H5qDdhEZgFxiVtP5jNBHC0gsWTPeWYIW1Ti5eN/rBC2gcTWpftYIGxF iV/zrrBB9OpILNj9CcrWlli28DVYL6+AoMTJmU+g6sUlDh/ZwTqBUXwWknWzkLTPQtI+C0n7 AkaWVYx8lmZ6hoYmeoamFnpGhkabGMGJY96VHYyXp3scYhTgYFTi4Y3hSo8WYk0sK67MPcQo wcGsJML7vyE1Wog3JbGyKrUoP76oNCe1+BCjNAeLkjivpmpStJBAemJJanZqakFqEUyWiYNT qoFxX6neVaXqNeutu5axcHzc8HmnbwTDxZvdnbU+zkrN8fOLzk/9sTb+9j4TV3PJ6Qph/klC sX18HL/Tl4TWc85JURX0vqP3orH1uK75pCZtn7cWDXVN84sClvRY6fB51ls8DzqlxbbG5eDX WNZSt9+q+ebzVe+bf/wdlGpaIOw4v3JxrXC8ixJLcUaioRZzUXEiAIOTv/kYAwAA Archived-At: Subject: Re: [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: Sun, 05 Aug 2018 15:11:47 -0000 Along with notes from others, looks fairly solid. 7.1.2: "Authenticated Received Chains can be used to communicated authentication state between processing tiers." Should likely be "communicate" And seems like "Appendix B" should be completely removed at this point? -- Alex Brotman Sr. Engineer, Anti-Abuse Comcast -----Original Message----- From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Barry Leiba Sent: Tuesday, July 17, 2018 5:27 PM To: dmarc@ietf.org Subject: [dmarc-ietf] WGLC on draft-ietf-dmarc-arc-protocol-16 So begins Working Group Last Call (WGLC) on draft-ietf-dmarc-arc-protocol-1= 6. 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, pleas= e post that as well. If you think your earlier comments have not been addr= essed and should have been, please say so. As you review, keep in mind that the target status is Experimental, and tha= t after we've played with it for a while we'll have another chance to adjus= t it based on that experience. -- Barry, DMARC chair _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From nobody Mon Aug 6 17:46: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 A3111130E74 for ; Mon, 6 Aug 2018 17:46:28 -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 hgzTsJd8Ue8t for ; Mon, 6 Aug 2018 17:46:26 -0700 (PDT) Received: from mail-yw1-xc31.google.com (mail-yw1-xc31.google.com [IPv6:2607:f8b0:4864:20::c31]) (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 9D69D130E04 for ; Mon, 6 Aug 2018 17:46:26 -0700 (PDT) Received: by mail-yw1-xc31.google.com with SMTP id v197-v6so4319356ywg.3 for ; Mon, 06 Aug 2018 17:46:26 -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=rA0xjXcRCyI/HUqEDnV9fbnYoToyWJyOAg2wtA/kbS0=; b=c+u4EpB8BIO6C2trFsfvblljFxay4VlDh+yyAXxu/ZqG9bjVsVcn4tVIMEQNpCH4gW jg1LdXqYn9iJE7jr0DQb2OVDaQ34JwJX/CyhyPZWirMzW/tXcGvTeBZP4+pP6eJMZpY6 P7bUGVv9Ui9HBN6uR0hWuvtRDcQrx7KrW4YZm2XUgkkikxT9Dg99o5vI9cC0+1txW7ry oGC0nuxqkem6XTuL998SCipLjJEKRiHGrkX18u7eSAf5iGMfKuK1jvrIa+6RbgwxQlTe PtwXl9cDnhtAk2GjbhGkep5BxRMyADgzWcn1PTE9+0xHvS4N6z53UXYBiNM2M68aBKFQ P9dg== 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=rA0xjXcRCyI/HUqEDnV9fbnYoToyWJyOAg2wtA/kbS0=; b=Lro89u45XzgGY8xz6iuuuUJKoHVLG0xUcjkc6KHy7IaUvhanFGsnBoc41nI3KTbrBK wHhIvipL64AdDNKpxenSneYyUV7FIeMXL071zwYmDt3xTdGD5cFEds2wY6CAh3FenO32 9sNyRkqiEsA2gq2h4uLscBIoeGBPY7CnpVhztkYDLTD6NpKPy0SqghCMjQqr9Xs/Cy+V CQV/vMaTHbnMBLhRpvs6mCyx7XnTQ2rfMkOI7+/8c0tv1rVECn5fwudjA3m+LvnmeNvE BRzbEd1Zhn66/V5mnQ7hcz0LV6an90jiRCH223b8hYXFAAAldyhrqKBPOVu8bV20xcL2 sxRA== X-Gm-Message-State: AOUpUlHfhjNwY4UmDa2Z15ywDy9BVFwVq5puE1q1aJU3oun1nttU+lf7 U/Nm8W79saekReaDvkWKw685AS39HVpwCopDxdJi X-Google-Smtp-Source: AAOMgpcO/qpKkkvruWfseH/si2EVZAYbMNqifPXxHewRk4jVGHBGmeMdVNVauOl6YN/qTLasa5UnrEM+thmhI2+bzLk= X-Received: by 2002:a0d:d105:: with SMTP id t5-v6mr9066560ywd.449.1533602785293; Mon, 06 Aug 2018 17:46:25 -0700 (PDT) MIME-Version: 1.0 References: <20180730221726.713CE200316625@ary.qy> In-Reply-To: From: Brandon Long Date: Mon, 6 Aug 2018 17:46:11 -0700 Message-ID: To: Seth Blank Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000003f0d4f0572cdb917" 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, 07 Aug 2018 00:46:29 -0000 --0000000000003f0d4f0572cdb917 Content-Type: text/plain; charset="UTF-8" On Fri, Aug 3, 2018, 4:14 PM Seth Blank wrote: > On Fri, Aug 3, 2018 at 11:00 AM, Brandon Long < > blong=40google.com@dmarc.ietf.org> wrote: > >> Currently, we don't do anything with failed chains short of keeping >> stats. Everything we've used the chain for so far has been from passing >> chains. >> > > Especially as an Experiment, I think it's important to sign even failing > chains, especially for the reasons I've already enumerated. Otherwise, the > above scenario - only data from passing chains is usable - is the only > possible scenario. This seems myopic, especially when we don't yet know > what the real world landscape will look like. > Do we actually have consensus on what to do, though? The current proposal seems pretty bad, sign one or all depending on vague things that might be different per impl. > --0000000000003f0d4f0572cdb917 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


= On Fri, Aug 3, 2018, 4:14 PM Seth Blank <seth@sethblank.com> wrote:
On Fri, Aug 3, 2018 at 11:00 AM, Brandon Long <blong=3D40google.com@dmarc.ietf.org> wrote:
Currently, we don't do an= ything with failed chains short of keeping stats.=C2=A0 Everything we'v= e used the chain for so far has been from passing chains.

Especially as an Experiment, I think it's importan= t to sign even failing chains, especially for the reasons I've already = enumerated. Otherwise, the above scenario - only data from passing chains i= s usable - is the only possible scenario. This seems myopic, especially whe= n we don't yet know what the real world landscape will look like.
=

Do we actually have consensus on what to do, though?

The current proposal seems prett= y bad, sign one or all depending on vague things that might be different pe= r impl.
--0000000000003f0d4f0572cdb917-- From nobody Tue Aug 7 08:38:04 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 EFB23130FFF for ; Tue, 7 Aug 2018 08:38:01 -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 YJt11ZaQ1pFZ for ; Tue, 7 Aug 2018 08:38:00 -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 1784D130F6F for ; Tue, 7 Aug 2018 08:38:00 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id p10-v6so13814179ljg.2 for ; Tue, 07 Aug 2018 08:37:59 -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=o2kDc28uq90bMkq/lIi1GFcn6vaYmvGFAp/f8JBdoBs=; b=a/VtefDnZzpJFHM6RlTBFW5neAleMAubtrSLVu38eBr+N+au4eWpfnFRkDmtvCaZKj zvO6NrC3NIL39/Vu6hkqRiuUDV4Xzz8VUlpFwbjJWIz94u/vM1CJzLs8FkFZdMltK9Ms yFLPqfh5dBbgcT5zvjFEFny7XzPy9q6BRBBAM= 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=o2kDc28uq90bMkq/lIi1GFcn6vaYmvGFAp/f8JBdoBs=; b=nbE3ykiTl4wBGtTq8B1tbNSYZrJU+L1utZjBXkanD1Y8DiK2T41yaKIoCbyCQrmEmM EOzT4CONnRT6cy4dvrlhPSsFWNINbp+Nhaatvm/km0FXlXhFpNZeUhZAh0z5t7vEOQot ewlNfOBle75t35sF1WrpnaQqlBn1q+wB28VbYTOPYTQpNLSW7+P/etHE7BwWVton5FU9 vy/1wZ0zzW82xfCkOJIPdhurXnOmaDiksQE2IGMVOlqjb6jAr4GQlYrPkGWXzyS2+OYf uapDg5qAlsy4aAUKiHTPtTOXeOiDSRmqhKCE651QeUxLGgrWHYJZHWM3Rh17iPZGnDiY JMEA== X-Gm-Message-State: AOUpUlHjzYDtvdtSU8SpVqK/LYw44Yg2KrCcz9fIvza+T14c5Yt4fXuQ 4wMawLxUery0/IN1M0S5pSqarQifAl/Zu+K4xDclGw== X-Google-Smtp-Source: AAOMgpetNDHRgwny5Ky700Gxrgy1rY1/4UXZcF7VemUBMccwlY+Sle5p3cFFnKPr+wvhTSSUy4TE+BY2GehN7rmytq0= X-Received: by 2002:a2e:9c0f:: with SMTP id s15-v6mr11190894lji.97.1533656278165; Tue, 07 Aug 2018 08:37:58 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 2002:a19:5943:0:0:0:0:0 with HTTP; Tue, 7 Aug 2018 08:37:57 -0700 (PDT) In-Reply-To: References: <20180730221726.713CE200316625@ary.qy> From: "Kurt Andersen (b)" Date: Tue, 7 Aug 2018 08:37:57 -0700 X-Google-Sender-Auth: UrE48jvBY6zb7b5ddoKBAN7DGpw Message-ID: To: Brandon Long Cc: Seth Blank , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000aafef80572da2dd3" 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, 07 Aug 2018 15:38:02 -0000 --000000000000aafef80572da2dd3 Content-Type: text/plain; charset="UTF-8" On Mon, Aug 6, 2018 at 5:46 PM, Brandon Long < blong=40google.com@dmarc.ietf.org> wrote: > > Do we actually have consensus on what to do, though? > > The current proposal seems pretty bad, sign one or all depending on vague > things that might be different per impl. > It does not seem to me like we have consensus. Can we pick one option for this experimental phase and re-evaluate afterward? For the sake of non-ambiguity, I'd suggest the "sign one" approach. During the experiment we can see how often it has to be invoked and request people to examine those cases for further evaluation. --Kurt --000000000000aafef80572da2dd3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Aug 6, 2018 at 5:46 PM, Brandon Long <blong=3D40goog= le.com@dmarc.ietf.org> wrote:

Do we actually have consensus on what to do, though?

The current proposal seems prett= y bad, sign one or all depending on vague things that might be different pe= r impl.

It does not seem to me = like we have consensus. Can we pick one option for this experimental phase = and re-evaluate afterward? For the sake of non-ambiguity, I'd suggest t= he "sign one" approach. During the experiment we can see how ofte= n it has to be invoked and request people to examine those cases for furthe= r evaluation.

--Kurt=C2=A0

--000000000000aafef80572da2dd3-- From nobody Sat Aug 11 14:20: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 15B1F130FFC for ; Sat, 11 Aug 2018 14:20:14 -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 a9lS0raR15Rc for ; Sat, 11 Aug 2018 14:20:10 -0700 (PDT) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::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 C1AB113110F for ; Sat, 11 Aug 2018 14:20:09 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id p10-v6so9767476ljg.2 for ; Sat, 11 Aug 2018 14:20:09 -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=D6K/3BtNX53A9Xq/DdPJVGxPh2Rz/w+eYT1bq++tu5A=; b=jg2NyQbIATlqB9guQ8SVNRn0KvmO/FYODLlWXSsy4gowxhz6Z3wZrl8Uh5FGbPjGyU T9yteqpm/DSBkxf3DNwX5zeHimQrdSmsdFGAZeEuP5iVft6jEhlI4+gkGTQKvOAt8tLU NHMJONeonBw9yzKUfTnrlO+1w0CRFU78KUl1NEQg4caXdZMdZArv7lc7KZx9ey73EtrR 0/kv2FK6tjys9loirc337x0TqpsL5OITatkqlopOaqUJnSfTB7RDORSJOyVhODBqWnJf aAdJLbzXn5xuAZyF6LZqNU+Yjps+YZMMpjXTxmNQFTrFNhZa/2wl8kUsIUEfGpkE8FfH cTbQ== 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=D6K/3BtNX53A9Xq/DdPJVGxPh2Rz/w+eYT1bq++tu5A=; b=P+1V3NlWxPAaGqw1DPh/7QDi80SSQK5K0pR+awmuNrbXXPRGHkZihMND6ueBLWYrft AEgeitPMjs2fje4Q9rUvLbdpi9zN9ihzk/RQ8xSYJ+b9ta71Pt+60DbowYneO/+GX0IT Dbw5HBSq7RyzpzakNTzjWoF+oqOzKiK9WJm1/qUqZ5dRU54V4OL9RctM7TY7xUyXpanx 2MizBHjz3dTO85LXP3Q9qIvF8l+tl+iJceMY+HnE0fiynyk5h5KaQsH+QS8WroY90AFH oSEkrhk8E787EdZ3mx+wfYIkL7zHRaIRmDee9NFUtVGDMAzYWq/NXy/dS1XN09eTZ5Nx jrgQ== X-Gm-Message-State: AOUpUlE8X45jyzc4EFkRa9UnfMqqc2u/7dFn75dwWWeayIRC+1pcU1k0 o1AGU6nelAGeX9rEI3iVy4/Oi+q9itZqMwIX9JT7DgFj X-Google-Smtp-Source: AA+uWPwSFhMjqgx1RO7IIUfDgIQGxgrh2Id6d+2Jj6GI1yxWXWoH9mtPE4g8w6ZjliLJ04R1hgvPDsiPCJOniktHulY= X-Received: by 2002:a2e:1609:: with SMTP id w9-v6mr7909860ljd.120.1534022407981; Sat, 11 Aug 2018 14:20:07 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:3a13:0:0:0:0:0 with HTTP; Sat, 11 Aug 2018 14:20:07 -0700 (PDT) In-Reply-To: References: <20180730221726.713CE200316625@ary.qy> From: "Murray S. Kucherawy" Date: Sat, 11 Aug 2018 21:20:07 +0000 Message-ID: To: "Kurt Andersen (b)" Cc: Brandon Long , IETF DMARC WG , Seth Blank Content-Type: multipart/alternative; boundary="000000000000b48f0305732f6c0e" 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, 11 Aug 2018 21:20:20 -0000 --000000000000b48f0305732f6c0e Content-Type: text/plain; charset="UTF-8" On Tue, Aug 7, 2018 at 3:37 PM, Kurt Andersen (b) wrote: > On Mon, Aug 6, 2018 at 5:46 PM, Brandon Long ietf.org> wrote: > >> >> Do we actually have consensus on what to do, though? >> >> The current proposal seems pretty bad, sign one or all depending on vague >> things that might be different per impl. >> > > It does not seem to me like we have consensus. Can we pick one option for > this experimental phase and re-evaluate afterward? For the sake of > non-ambiguity, I'd suggest the "sign one" approach. During the experiment > we can see how often it has to be invoked and request people to examine > those cases for further evaluation. > "Sign one" (I think you mean "seal one") remains ambiguous to me, because as Seth said, once I see "cv=fail", I don't care about anything else. Now I have a seal nobody cares about, which means the sealer shouldn't be bothered with generating it, irrespective of what gets fed to the hash. Can we clear that part up? -MSK --000000000000b48f0305732f6c0e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Aug 7, 2018 at 3:37 PM, Kurt Andersen (b) <kboth@d= rkurt.com> wrote:
On Mon, Aug 6, 20= 18 at 5:46 PM, Brandon Long <blong=3D40google.com@dmar= c.ietf.org> wrote:

<= /div>
Do we actually have consensus on what to do, t= hough?

The current propo= sal seems pretty bad, sign one or all depending on vague things that might = be different per impl.

I= t does not seem to me like we have consensus. Can we pick one option for th= is experimental phase and re-evaluate afterward? For the sake of non-ambigu= ity, I'd suggest the "sign one" approach. During the experime= nt we can see how often it has to be invoked and request people to examine = those cases for further evaluation.

"Sign one" (I think you mean "seal one"= ;) remains ambiguous to me, because as Seth said, once I see "cv=3Dfai= l", I don't care about anything else.=C2=A0 Now I have a seal nobo= dy cares about, which means the sealer shouldn't be bothered with gener= ating it, irrespective of what gets fed to the hash.

Can we clear that part up?

-MSK
--000000000000b48f0305732f6c0e-- From nobody Sat Aug 11 14:31: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 DA6F713107A for ; Sat, 11 Aug 2018 14:31:57 -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 gca0AaUtKLJe for ; Sat, 11 Aug 2018 14:31:56 -0700 (PDT) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0: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 1E3BE131010 for ; Sat, 11 Aug 2018 14:31:56 -0700 (PDT) Received: by mail-pg1-x531.google.com with SMTP id x5-v6so5876642pgp.7 for ; Sat, 11 Aug 2018 14:31:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=NIPd0jt/+DKCIWK/d4izi8HMY7z9JuliUbPf22CoyvM=; b=g9eq2nBqEUyCMV+HtYQOwFk1EEfVZtxO6xapUkY4xXN/MWLQcGGrJ61I1Di66UkDwi NvIPV/2H7IcQhQuYtytnlfDqxVSnvW0lyYdRJP2tEvor3kcruwMp0nTrF2bTOfqJRYmn zoniwI+YPnPqHtM4benRfsl7yELvHJXcPUYeZPjV+SsgGBUANwOnDbzg13lf2XkXLtbY Cr1cdx4Bwu3uwfIEUIDNp694Ddv3rkuwCVPY76ulL8+8i8klcduRKRg0jF7PwMQkzVFa MeWfitwxluudEqK6OXn81BguycugbAASeWlUTagKfvAtD2xsaSL6vAwjOeYpGeXuL+B7 K4qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=NIPd0jt/+DKCIWK/d4izi8HMY7z9JuliUbPf22CoyvM=; b=SX+m8OoXlh20/YxYmsxoz2vqTVR24UHMwtBp3MmZIYhCakdAil/p4FhWo2kHHPr5xz zRXfY6h0eMpwID7TOM4wCloUgVx4CsxH14FZ86z/XaMIOP2BiMt/7zW7LeoCT8Tu8gjz aNnfmPwh839CtpOeh1nIoJUrds+QiGQRps8yDwdUzmXr5n63mFVZ23szvUnaSDITAbFp fnMHa2nFtTq7hZJp4ub8bx57ytuXzlZcLPpkPays2/Qrx2kk12r0eVEUkVE67wsHLb/K IKiiEvw4AFt4hHyPuado7QrfvnFmmMbWQQpMHgMILl9GYIym3I1tnJLIBWGlVCnu3Qtc GFMw== X-Gm-Message-State: AOUpUlEtJxjrDE6UHsaFF4m7xdPxmXZ78PMygiyr4+wZ5LaUYPZyl4Zz Y+64ueXKkFEWU+FjLz/Ivyk= X-Google-Smtp-Source: AA+uWPx80dAkzcEfG1+FZERyakiNsAhwDEfgnwo/m+Q9q1NsE+qoo/FgfWxK0MtpzH0lUugcaACarg== X-Received: by 2002:aa7:800f:: with SMTP id j15-v6mr12590157pfi.174.1534023115519; Sat, 11 Aug 2018 14:31:55 -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 g7-v6sm15852524pfi.175.2018.08.11.14.31.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 11 Aug 2018 14:31:54 -0700 (PDT) To: "Murray S. Kucherawy" , "Kurt Andersen (b)" Cc: IETF DMARC WG , Brandon Long , Seth Blank References: <20180730221726.713CE200316625@ary.qy> From: Dave Crocker Message-ID: Date: Sat, 11 Aug 2018 14:31:52 -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] 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, 11 Aug 2018 21:31:58 -0000 On 8/11/2018 2:20 PM, Murray S. Kucherawy wrote: > Sign one" (I think you mean "seal one") remains ambiguous to me, because > as Seth said, once I see "cv=fail", I don't care about anything else. > Now I have a seal nobody cares about, which means the sealer shouldn't > be bothered with generating it, irrespective of what gets fed to the hash. > +1*10**inf. There has been a persistent desire to find a way to continue to process an ARC sequence that is broken, as if that will somehow make it unbroken or, at least, /less/ broken. It won't. As soon as a broken ARC chain is detected, ARC is -- or at least should be -- finished. ARC-aware not should stop processing ARC for that message. Completely stop. If there is a clear and compelling counter-argument of clear benefit that can be achieved, will be achieved, and is desired by receivers, what is it? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Aug 14 20:59:21 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 85B93130EDE for ; Tue, 14 Aug 2018 20:59:19 -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 59AwGLXoBQHD for ; Tue, 14 Aug 2018 20:59:17 -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 01A0C130ED9 for ; Tue, 14 Aug 2018 20:59:16 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id k12-v6so37589500oiw.8 for ; Tue, 14 Aug 2018 20:59:16 -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=hFBBjBgObtrfRNRtTDx9Oq1allKC63qY1x3LK/mHCn0=; b=HjCUKp5rcbDIVxFTxAFf4iaP23q6GXweD39a1ypsQdTHx0kz7Vsg6A3OdSEOJWndfB IY158MDBxlG2nvcDnBC6AQ/HIgAerJPyUvz4cvYfW1IMonRiQgPAWjSW1UYkN+SpXeAy t/JhaO31bnAmYE61Fh6iwMoCRjrpH1VAl0dcB5av/Fag+rn4EayCFl9a7cbHvv6Z8yTP jtMsM5WmrlcglxeaUzoICzEvdMZZhAmFCnvwyFu3lzZfwkodxuGzeEjJrerjDt/AW4nJ oFoQqH41qrxS0msSBugxA/DcuPmxpjYo9rdtR5CbcVj0WeTOIsieE/Y2VueHgaWaB43f S08Q== 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=hFBBjBgObtrfRNRtTDx9Oq1allKC63qY1x3LK/mHCn0=; b=UdYlvrpijFiuLHTMjBCW5YCwxg6OlmR6DyrzwP2/eswgQ70T3pTUOhHMm2EiDc+Ewj SsFSPPxQTNyEvF7TsnY1fXH6ILfn8WsIOaJFbj82rEbnJJr9EDOe8TDCbZuNBZVLzT1l 5IIdIYEZsef/vhyyv5ncG+Eavo64cTt5IGJsj8wWjDDZRcHK1QWmlLZvsOsbCNUe+2e9 Qth/WgvV5faH5qfReXYo51Lw9ivd6abgvJVeayFDS86GJqfZIxVgb7Sn4vfmRQGszyK/ gXZNJwYi9FH6WOTpI4iQVB079L7bPTQ3CThXE5+RkfYTSFrRFFOPCorZTNlK/eBNS3uI dY1g== X-Gm-Message-State: AOUpUlGkK9Nmnp8d7dQZ5HzGADq5eXsvrclspvPYP6SVioEhcjUiKR/2 f+Lc/wB6Y3iQoJE5l5vp9xzd7F8P+WKxhHF1+6I55qcdkCk= X-Google-Smtp-Source: AA+uWPyJLQdKlAYXmx4TnpihpzpVPqMl5fnz3EVBvz5NgsrLZG/BUqlH66UNOC0grtpf6pWGiRUsqgTFXCQ6tZeU7WY= X-Received: by 2002:aca:3d83:: with SMTP id k125-v6mr23389221oia.86.1534305555946; Tue, 14 Aug 2018 20:59:15 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:2646:0:0:0:0:0 with HTTP; Tue, 14 Aug 2018 20:58:55 -0700 (PDT) In-Reply-To: References: <20180730221726.713CE200316625@ary.qy> From: Seth Blank Date: Tue, 14 Aug 2018 20:58:55 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000a3baf005737159b8" 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, 15 Aug 2018 03:59:20 -0000 --000000000000a3baf005737159b8 Content-Type: text/plain; charset="UTF-8" On Sat, Aug 11, 2018 at 2:31 PM, Dave Crocker wrote: > If there is a clear and compelling counter-argument of clear benefit that > can be achieved, will be achieved, and is desired by receivers, what is it? There are THREE consumers of ARC data (forgive me for the names, they're less specific than I'd like): 1) The ARC Validator. When the Validator sees a cv=fail, processing stops, the chain is dead, and shall never be less dead. What is Sealed is irrelevant. 2) The Receiver. An initial design decision inherent in the protocol is that excess trace information will be collected, as it's unclear what will actually be useful to receivers. 11.3.3 calls this out in detail. Without Sealing the entire chain when attaching a cv=fail verdict, none of the trace information is authenticatable to a receiver (see earlier message in this thread as to why), which is the exact opposite of the design decision the entire protocol is built on. To guarantee this trace information can be authenticated, the Seal that contains cv=fail must include the entire chain in its scope. This is where this thread started. 3) The receiver of reports that provide ARC data. For a domain owner to get a report with ARC information in it, there needs to be some level of trust in the information reported back. When a Chain passes, all the intermediaries' header field signatures can be authenticated, and the mailflow can be cleanly reported back. When a Chain fails, that is important information to a domain owner (where is my mailflow failing me, how can I figure this out so I can fix it?). Again, without Sealing over the entire Chain when a failure is detected, this information is unauthenticatable (and worse, totally forgeable now without even needing a valid Chain to replay), and nothing of substance can be reported back. Sealing the Chain when a cv=fail is determined blocks forgery as a vector to report bogus information, and allows authenticatable information to be reported back. So to recap: Yes, when you hit cv=fail the chain is dead and shall never be less dead. But to preserve trace information as was the initial design decision, and make sure report data is meaningful and cannot be forged, when a cv=fail verdict is attached the Seal must cover the entire chain in its scope. And to be even clearer: what is Sealed when cv=fail is reached (itself, the entire chain, or nothing at all) DOES NOT AFFECT INTEROPERABILITY. But it does effect preserving trace information and preventing forged data from being reportable. This is my very strong INDIVIDUAL opinion. But I'm fine if the group sees differently, as this could be investigated as part of the experiment (i.e. do any of the above points matter in the real world? I say they do, hence the strong opinion.). As an editor, I'll make sure whatever the consensus of the group is is reflected in the document. --000000000000a3baf005737159b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= at, Aug 11, 2018 at 2:31 PM, Dave Crocker <dcrocker@gmail.com> wrote:
If there is a clear and compel= ling counter-argument of clear benefit that can be achieved, will be achiev= ed, and is desired by receivers, what is it?

There are THREE consumers of ARC data (forgive me for the names, they'= ;re less specific than I'd like):

1) The ARC V= alidator. When the Validator sees a cv=3Dfail, processing stops, the chain = is dead, and shall never be less dead. What is Sealed is irrelevant.
<= div>
2) The Receiver. An initial design decision inherent in = the protocol is that excess trace information will be collected, as it'= s unclear what will actually be useful to receivers. 11.3.3 calls this out = in detail. Without Sealing the entire chain when attaching a cv=3Dfail verd= ict, none of the trace information is authenticatable to a receiver (see ea= rlier message in this thread as to why), which is the exact opposite of the= design decision the entire protocol is built on. To guarantee this trace i= nformation can be authenticated, the Seal that contains cv=3Dfail must incl= ude the entire chain in its scope. This is where this thread started.
=

3) The receiver of reports that provide ARC data. For a= domain owner to get a report with ARC information in it, there needs to be= some level of trust in the information reported back. When a Chain passes,= all the intermediaries' header field signatures can be authenticated, = and the mailflow can be cleanly reported back. When a Chain fails, that is = important information to a domain owner (where is my mailflow failing me, h= ow can I figure this out so I can fix it?). Again, without Sealing over the= entire Chain when a failure is detected, this information is unauthenticat= able (and worse, totally forgeable now without even needing a valid Chain t= o replay), and nothing of substance can be reported back. Sealing the Chain= when a cv=3Dfail is determined blocks forgery as a vector to report bogus = information, and allows authenticatable information to be reported back.

So to recap: Yes, when you hit cv=3Dfail the chain i= s dead and shall never be less dead. But to preserve trace information as w= as the initial design decision, and make sure report data is meaningful and= cannot be forged, when a cv=3Dfail verdict is attached the Seal must cover= the entire chain in its scope.

And to be even cle= arer: what is Sealed when cv=3Dfail is reached (itself, the entire chain, o= r nothing at all) DOES NOT AFFECT INTEROPERABILITY. But it does effect pres= erving trace information and preventing forged data from being reportable.<= /div>

This is my very strong INDIVIDUAL opinion. But I&#= 39;m fine if the group sees differently, as this could be investigated as p= art of the experiment (i.e. do any of the above points matter in the real w= orld? I say they do, hence the strong opinion.). As an editor, I'll mak= e sure whatever the consensus of the group is is reflected in the document.=
--000000000000a3baf005737159b8-- From nobody Tue Aug 14 22:28: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 CA884130E43 for ; Tue, 14 Aug 2018 22:28: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, 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 WsZl0GyBCSQx for ; Tue, 14 Aug 2018 22:28:40 -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 2D6B8130DDD for ; Tue, 14 Aug 2018 22:28:40 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id p10-v6so103000ljg.2 for ; Tue, 14 Aug 2018 22:28:40 -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=iqs+kiVOc+1u9peDadC4pfMC+SkJnfVPRC2KTsoT5SI=; b=b1xBS24P33XkSZs7Ib34hQL2JwCrHqDPrVy4F0WfAZBETfoOokwRwIfGYUVfhEmwOt ju69a5HTytM6JjQJCvkhzR76yA4Ni0s2rsfp348OjGkQ+87oM51Bl7pmHQrkhNXeeZnY +fvRR6GGUV9UX4UPkFjtBEeDe7GZDrF2tgSAA= 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=iqs+kiVOc+1u9peDadC4pfMC+SkJnfVPRC2KTsoT5SI=; b=splrkV2wC7b4V7CrS0vU7ENav0tjs6o6NbU2fUx1+Oo3+4fVXeNzmr/94EBwPxqwKz w1TWwiPIFw9o8vARK0rHmWaJ1wbtgKgqLRD9VgRE2V7OIHuu2HP33MyYj4W/9dwkPq5A dXbu6n++JTLeR2Dhh/ehr58+3TxzYl5JzvyfEh+KYSmOW7o5fORDwsIemJym/Eic+mqy e5XBS9OEfueC7a9csbi9pI68Axy+nHNV12lfJFSBCtslQZrjNxd83pq99LQEBr6GJ3oL LttBEuGDvIqhdup4C4SYW6m4pRZM4akZPi3j+FhpswqFw93GirzwleO+HHwlDnUUOxSj q38w== X-Gm-Message-State: AOUpUlFBBFZ6FH30snvYQcjB6T5bRGdm+Lr/8ugz76zc0SGM2yEM0peU d+awLmmRoFVVzN1+7on3v+LJYJSw2nyZhoBLmW/Q6Q== X-Google-Smtp-Source: AA+uWPzIIBWu8IDbR7NMw9OaZBDQg4/3E9fvSL6nwy0tDuXGb1VHsEG9X8B4xVLUhGN3ryZi1CJ5v0/yDXpkeUo0K5o= X-Received: by 2002:a2e:9c0f:: with SMTP id s15-v6mr808398lji.97.1534310918108; Tue, 14 Aug 2018 22:28:38 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 2002:a19:5943:0:0:0:0:0 with HTTP; Tue, 14 Aug 2018 22:28:36 -0700 (PDT) In-Reply-To: References: <20180730221726.713CE200316625@ary.qy> From: "Kurt Andersen (b)" Date: Tue, 14 Aug 2018 22:28:36 -0700 X-Google-Sender-Auth: Dw4ReH7htdnzHxW4KSh8Lu0XMUM Message-ID: To: Dave Crocker Cc: "Murray S. Kucherawy" , IETF DMARC WG , Brandon Long , Seth Blank Content-Type: multipart/alternative; boundary="0000000000003fc6f40573729947" 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, 15 Aug 2018 05:28:43 -0000 --0000000000003fc6f40573729947 Content-Type: text/plain; charset="UTF-8" On Sat, Aug 11, 2018 at 2:31 PM, Dave Crocker wrote: > On 8/11/2018 2:20 PM, Murray S. Kucherawy wrote: > >> Sign one" (I think you mean "seal one") remains ambiguous to me, because >> as Seth said, once I see "cv=fail", I don't care about anything else. Now >> I have a seal nobody cares about, which means the sealer shouldn't be >> bothered with generating it, irrespective of what gets fed to the hash. >> >> > +1*10**inf. > > There has been a persistent desire to find a way to continue to process an > ARC sequence that is broken, as if that will somehow make it unbroken or, > at least, /less/ broken. > > It won't. > > As soon as a broken ARC chain is detected, ARC is -- or at least should be > -- finished. ARC-aware not should stop processing ARC for that message. > Completely stop. > > If there is a clear and compelling counter-argument of clear benefit that > can be achieved, will be achieved, and is desired by receivers, what is it? Looking at how ARC chains can fail through the lens of the the validation protocol ( https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-15#section-5.2): 1. steps 1-3 are all pre-crypto structural checks. Most of the discussion and concern has been in regard to these sorts of structural failures being introduced by broken implementations or mis-behaving MTAs in the intermediary stages. Up through version 4, we designated such structural failures with a "cv=invalid" flag and A-R(arc)=unknown so that no one would waste further time or resources looking at them; 2. step 4 validates the most recent AMS. If it is broken, then we know nothing about the content being conveyed so "cv=fail" + A-R(arc)=fail makes sense or we could get more specific with A-R(arc-ams)=fail (not currently a defined designation); 3. step 8 (should be 6 if the sub-items had been properly indented) validates the sequence of AS header values. If those do not validate, then the integrity of the chain itself is unfounded. We currently also designate this with "cv=fail" and A-R(arc)=fail but we could distinguish it from failure mode 2 with A-R(arc-as)=fail instead. The only reason to affix a seal with "cv=fail" on the end of an ARC chain is to spare all subsequent handlers from having to venture past step 2 in the validation process. Without that, every intermediary and the final receiver (at least those which validate ARC) will have to repeat the entire sequence of validation up to whatever point in the process a failure is determined. If we want (for some reason that I still don't understand) to have a broken chain "preserved" for hypothetical forensics, we can't do it under conditions of malformation because we have no deterministic list of ARC header fields *to* seal. We could do something defined for failure cases 2 and 3 and some structural violations, but not for all structural violations. That's why I remain convinced that what is currently called for in the spec is the only workable approach. --Kurt --0000000000003fc6f40573729947 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= at, Aug 11, 2018 at 2:31 PM, Dave Crocker <dcrocker@gmail.com> wrote:
On 8/11/2018 2:20 PM, Murray S. Kucherawy wrote:
Sign one" (I think you mean "seal one") remains ambiguous to= me, because as Seth said, once I see "cv=3Dfail", I don't ca= re about anything else.=C2=A0 Now I have a seal nobody cares about, which m= eans the sealer shouldn't be bothered with generating it, irrespective = of what gets fed to the hash.


 +1*10**inf.

There has been a persistent desire to find a way to continue to process an = ARC sequence that is broken, as if that will somehow make it unbroken or, a= t least, /less/ broken.

It won't.

As soon as a broken ARC chain is detected, ARC is -- or at least should be = -- finished.=C2=A0 ARC-aware not should stop processing ARC for that messag= e.=C2=A0 Completely stop.

If there is a clear and compelling counter-argument of clear benefit that c= an be achieved, will be achieved, and is desired by receivers, what is it?<= /blockquote>

Looking at how ARC chains can fail through = the lens of the the validation protocol (https://tools.ietf.org/h= tml/draft-ietf-dmarc-arc-protocol-15#section-5.2):
  1. = =C2=A0steps 1-3 are all pre-crypto structural checks.=C2=A0 Most of the dis= cussion and concern has been in regard to these sorts of structural failure= s being introduced by broken implementations or mis-behaving MTAs in the in= termediary stages. Up through version 4, we designated such structural fail= ures with a "cv=3Dinvalid" flag and A-R(arc)=3Dunknown so that no= one would waste further time or resources looking at them;
  2. ste= p 4 validates the most recent AMS. If it is broken, then we know nothing ab= out the content being conveyed so "cv=3Dfail" + A-R(arc)=3Dfail m= akes sense or we could get more specific with A-R(arc-ams)=3Dfail (not curr= ently a defined designation);
  3. step 8 (should be 6 if the sub-items = had been properly indented) validates the sequence of AS header values. If = those do not validate, then the integrity of the chain itself is unfounded.= We currently also designate this with "cv=3Dfail" and A-R(arc)= =3Dfail but we could distinguish it from failure mode 2 with A-R(arc-as)=3D= fail instead.
The only reason to affix a seal with "cv= =3Dfail" on the end of an ARC chain is to spare all subsequent handler= s from having to venture past step 2 in the validation process. Without tha= t, every intermediary and the final receiver (at least those which validate= ARC) will have to repeat the entire sequence of validation up to whatever = point in the process a failure is determined. If we want (for some reason t= hat I still don't understand) to have a broken chain "preserved&qu= ot; for hypothetical forensics, we can't do it under conditions of malf= ormation because we have no deterministic list of ARC header fields *to* se= al. We could do something defined for failure cases 2 and 3 and some struct= ural violations, but not for all structural violations. That's why I re= main convinced that what is currently called for in the spec is the only wo= rkable approach.

--Kurt
--0000000000003fc6f40573729947-- From nobody Wed Aug 15 02:58: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 74658130F56 for ; Wed, 15 Aug 2018 02:58: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 qMcc-xhZ_Vbr for ; Wed, 15 Aug 2018 02:58:21 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::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 09E56130F53 for ; Wed, 15 Aug 2018 02:58:21 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id l2-v6so12618335wme.1 for ; Wed, 15 Aug 2018 02:58: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=99//cwMc5f09tTQMCKBQlReuN5SiOAULNP+xwQBQx74=; b=iN4BGfrIfvWqVISb3muBaAifKUAnbUqWhyXEhFTmmy9hWnKtcuncorYVsestRQXCy4 Tyw4KZIYmnHSZDidf4ldUfSVGrt7wzc2F8s5fKAX05zJDCKNWZTASNsyU79xMnDzcVBy CothyAm7Hmq3hO5HKFk4ObXuUIDlsbKV2C+ubYsLXd2GWR9XtH0bvKJBOBgxhXGFGYAJ B5CeuCVMzfwg816pdpP6YQ05UwxhZmS454yXv7JRgyRAYqBcfzYtyIqsMKpMxzJI370o lQN5GTPLA0JPvwxCjzOjYl5qj33htxEMwrjONKkQZx5tMMj1bhIOKTJnG1WkeHYldob8 1lVA== 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=99//cwMc5f09tTQMCKBQlReuN5SiOAULNP+xwQBQx74=; b=sCaCU6HSDMuSIepR3C48bUWp20MaYgyekItirAjOdvrEz79VAbiVkDB1PXV+ga3jJt s2L97MWQ8Zgb0Ym8ga5Kwt3OjyDuaK5kJxedjZwPV3ciKzqTeO58ndZQEblctlNN8YTi XBwbRPNscRiwjjdokJTP5rtONBWHHwImGNlXpw/tBBQGN37KUX8L0LpoulQ46eCvmo9X xrTtOziRVbzmV9OFUKS2kzGUwm3501JuWSwbGy9SUjDONtVC+MbsBzYyEEWyK32MH51P i3lOWc+TRz+Fk9kv/jod524AUl6oxdfjYxJDEnETgiZ0A5iAJJ2yq8nGn650Um9a09aY kRRg== X-Gm-Message-State: AOUpUlHmBWpREc2DEI8QKlPsiEQeVE5eaxeDRkypqOlBiAV6znok9mGN X0x4XAgvhyrfLb3qPVX5IUJOTT06M2pgOPbn2YLGdQ== X-Google-Smtp-Source: AA+uWPyp1DGZlqb0uRS/UK95wnfD5gfYBV4x+386jr8pM26ZqWuMm+s+tRXHorlb2rHiDRsWG8UsMJAd14qUEKHfWtc= X-Received: by 2002:a1c:1f10:: with SMTP id f16-v6mr13800886wmf.112.1534327099428; Wed, 15 Aug 2018 02:58:19 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:adf:8367:0:0:0:0:0 with HTTP; Wed, 15 Aug 2018 02:58:18 -0700 (PDT) In-Reply-To: References: <20180730221726.713CE200316625@ary.qy> From: Dotzero Date: Wed, 15 Aug 2018 05:58:18 -0400 Message-ID: To: "Kurt Andersen (b)" Cc: Dave Crocker , IETF DMARC WG , "Murray S. Kucherawy" , Brandon Long , Seth Blank Content-Type: multipart/alternative; boundary="000000000000bb14960573765d6e" 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, 15 Aug 2018 09:58:24 -0000 --000000000000bb14960573765d6e Content-Type: text/plain; charset="UTF-8" On Wed, Aug 15, 2018 at 1:28 AM, Kurt Andersen (b) wrote: > On Sat, Aug 11, 2018 at 2:31 PM, Dave Crocker wrote: > >> On 8/11/2018 2:20 PM, Murray S. Kucherawy wrote: >> >>> Sign one" (I think you mean "seal one") remains ambiguous to me, because >>> as Seth said, once I see "cv=fail", I don't care about anything else. Now >>> I have a seal nobody cares about, which means the sealer shouldn't be >>> bothered with generating it, irrespective of what gets fed to the hash. >>> >>> >> +1*10**inf. >> >> There has been a persistent desire to find a way to continue to process >> an ARC sequence that is broken, as if that will somehow make it unbroken >> or, at least, /less/ broken. >> >> It won't. >> >> As soon as a broken ARC chain is detected, ARC is -- or at least should >> be -- finished. ARC-aware not should stop processing ARC for that >> message. Completely stop. >> >> If there is a clear and compelling counter-argument of clear benefit that >> can be achieved, will be achieved, and is desired by receivers, what is it? > > > Looking at how ARC chains can fail through the lens of the the validation > protocol (https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol- > 15#section-5.2): > > 1. steps 1-3 are all pre-crypto structural checks. Most of the > discussion and concern has been in regard to these sorts of structural > failures being introduced by broken implementations or mis-behaving MTAs in > the intermediary stages. Up through version 4, we designated such > structural failures with a "cv=invalid" flag and A-R(arc)=unknown so that > no one would waste further time or resources looking at them; > 2. step 4 validates the most recent AMS. If it is broken, then we know > nothing about the content being conveyed so "cv=fail" + A-R(arc)=fail makes > sense or we could get more specific with A-R(arc-ams)=fail (not currently a > defined designation); > 3. step 8 (should be 6 if the sub-items had been properly indented) > validates the sequence of AS header values. If those do not validate, then > the integrity of the chain itself is unfounded. We currently also designate > this with "cv=fail" and A-R(arc)=fail but we could distinguish it from > failure mode 2 with A-R(arc-as)=fail instead. > > The only reason to affix a seal with "cv=fail" on the end of an ARC chain > is to spare all subsequent handlers from having to venture past step 2 in > the validation process. Without that, every intermediary and the final > receiver (at least those which validate ARC) will have to repeat the entire > sequence of validation up to whatever point in the process a failure is > determined. If we want (for some reason that I still don't understand) to > have a broken chain "preserved" for hypothetical forensics, we can't do it > under conditions of malformation because we have no deterministic list of > ARC header fields *to* seal. We could do something defined for failure > cases 2 and 3 and some structural violations, but not for all structural > violations. That's why I remain convinced that what is currently called for > in the spec is the only workable approach. > > --Kurt > > +1. I understand the desire for more but I agree with Kurt. Michael Hammer --000000000000bb14960573765d6e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Aug 15, 2018 at 1:28 AM, Kurt Andersen (b) <kboth@drkurt.com> wrote:
On Sat, Aug 11= , 2018 at 2:31 PM, Dave Crocker <dcrocker@gmail.com> wrote:=
On 8/11/2018 2:20 PM, Murray= S. Kucherawy wrote:
Sign one" (I think you mean "seal one") remains ambiguous to= me, because as Seth said, once I see "cv=3Dfail", I don't ca= re about anything else.=C2=A0 Now I have a seal nobody cares about, which m= eans the sealer shouldn't be bothered with generating it, irrespective = of what gets fed to the hash.


 +1*10**inf.

There has been a persistent desire to find a way to continue to process an = ARC sequence that is broken, as if that will somehow make it unbroken or, a= t least, /less/ broken.

It won't.

As soon as a broken ARC chain is detected, ARC is -- or at least should be = -- finished.=C2=A0 ARC-aware not should stop processing ARC for that messag= e.=C2=A0 Completely stop.

If there is a clear and compelling counter-argument of clear benefit that c= an be achieved, will be achieved, and is desired by receivers, what is it?<= /blockquote>

Looking at how ARC chains can fail t= hrough the lens of the the validation protocol (https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-15#sec= tion-5.2):
  1. =C2=A0steps 1-3 are all pre-crypto structu= ral checks.=C2=A0 Most of the discussion and concern has been in regard to = these sorts of structural failures being introduced by broken implementatio= ns or mis-behaving MTAs in the intermediary stages. Up through version 4, w= e designated such structural failures with a "cv=3Dinvalid" flag = and A-R(arc)=3Dunknown so that no one would waste further time or resources= looking at them;
  2. step 4 validates the most recent AMS. If it i= s broken, then we know nothing about the content being conveyed so "cv= =3Dfail" + A-R(arc)=3Dfail makes sense or we could get more specific w= ith A-R(arc-ams)=3Dfail (not currently a defined designation);
  3. step= 8 (should be 6 if the sub-items had been properly indented) validates the = sequence of AS header values. If those do not validate, then the integrity = of the chain itself is unfounded. We currently also designate this with &qu= ot;cv=3Dfail" and A-R(arc)=3Dfail but we could distinguish it from fai= lure mode 2 with A-R(arc-as)=3Dfail instead.
The only reason = to affix a seal with "cv=3Dfail" on the end of an ARC chain is to= spare all subsequent handlers from having to venture past step 2 in the va= lidation process. Without that, every intermediary and the final receiver (= at least those which validate ARC) will have to repeat the entire sequence = of validation up to whatever point in the process a failure is determined. = If we want (for some reason that I still don't understand) to have a br= oken chain "preserved" for hypothetical forensics, we can't d= o it under conditions of malformation because we have no deterministic list= of ARC header fields *to* seal. We could do something defined for failure = cases 2 and 3 and some structural violations, but not for all structural vi= olations. That's why I remain convinced that what is currently called f= or in the spec is the only workable approach.

--Kurt
=


+1. I understand the desire for more b= ut I agree with Kurt.

Michael Hammer
--000000000000bb14960573765d6e-- From nobody Wed Aug 15 06:33: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 15EC3130F73 for ; Wed, 15 Aug 2018 06:33: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, 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 Do1ADX_W2QIs for ; Wed, 15 Aug 2018 06:33:50 -0700 (PDT) Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (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 60CA7130F4A for ; Wed, 15 Aug 2018 06:33:50 -0700 (PDT) Received: by mail-pf1-x42f.google.com with SMTP id j26-v6so513195pfi.10 for ; Wed, 15 Aug 2018 06:33:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=SkILELobu088wFV+CZujaetNU2ysB6+NeMoLKqsRHXk=; b=CxzSWLsdyBKGPKBnb0BVuZwCGjQcPfA8R2OLALVRE/mZBavlOfFdGxdZ0UlyDmpQdv K1dlxOIBaFmGhdweZX/HZJD5wg59/5m3GHixdxbJl08zeRGjC+kaIIN69RCJCwEmwAXc XakgvQGd2dUrAYVq/LQd4ICDjgwojGSpaqxaZL1/xcqm/Mo3e4UKQLWaql99T6khNpFV RHTnmtHRcSQeNzQE4BJwiZLcmlAu1L/7yYO5ynehX11SAEgCGMekdFviNcPQsMFXnyrT CyXakTKT9TxKJk6j4+J30ahBdvrMJAUQhzzl1M98iyCbaTAYdZZ9u5az4P4nH2FVxPtj 3x9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=SkILELobu088wFV+CZujaetNU2ysB6+NeMoLKqsRHXk=; b=fxfx0WMu3TxRPGPyqY10J8DMMRQZreR67idpoE9NhD81eKf4eGj1N1RQwmrgA2ufHi BaDOhE+y0B276KcrefrymOsvyV0IQdQNGh3tXcTBz/NTLpQnWvkyJTMxGePeERRCXvkv Ra3LyUR8Zmr9LiQp+51lE8XSHkXlAQVdIYZk/RjNHgyw5lwP4y23BHIlyi5jSVS41w1o mzS0B1T7VteOCrXZfBx65sE+n1Xtz92zbuW786jQL3X+NRzirn2TuHbAb6zKQSENuCFd MO0Pu9xP08Dn0PqKk0lpz3agtn07Ah6nTUzlIep2rktB2J2kYxtBIMyw2YNONPQ5eCw9 Avew== X-Gm-Message-State: AOUpUlG3HBYrp8bmx6PYefcBF/04ACCsLnn4SzBKj/e7e3rXUBbpNvvb 3J8H4Zjioqs6AxlaN4WeBGA= X-Google-Smtp-Source: AA+uWPzSHpL/+pyAdhVGTIHIDp1MXTd4+6vwz422diCeSMmVAMUsHhi6AixvtXtzxLyHanr6mVP1aw== X-Received: by 2002:a62:858c:: with SMTP id m12-v6mr27981214pfk.173.1534340029822; Wed, 15 Aug 2018 06:33:49 -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 q81-v6sm37046842pfd.15.2018.08.15.06.33.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Aug 2018 06:33:48 -0700 (PDT) To: "Kurt Andersen (b)" Cc: "Murray S. Kucherawy" , IETF DMARC WG , Brandon Long , Seth Blank References: <20180730221726.713CE200316625@ary.qy> From: Dave Crocker Message-ID: <799c2b18-97fe-6e22-f2cf-49245ae9c65e@gmail.com> Date: Wed, 15 Aug 2018 06:33:46 -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] 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, 15 Aug 2018 13:33:52 -0000 On 8/14/2018 10:28 PM, Kurt Andersen (b) wrote: > The only reason to affix a seal with "cv=fail" on the end of an ARC > chain is to spare all subsequent handlers from having to venture past > step 2 in the validation process. Without that, every intermediary and > the final receiver (at least those which validate ARC) will have to > repeat the entire sequence of validation up to whatever point in the > process a failure is determined. So the extra mechanism is intended an efficiency hack. 1. The processing being saved is merely normal processing that they'd be expected to do for a valid message. 2. I hope we are assuming that failure is not a typical condition 3. In order to save some occasional processing in some cases, we are adding mechanism to all implementations everywhere. This doesn't sound like compelling benefit, which is why I suggest removing it. Absent compelling benefit, simpler specifications is to be preferred, IMO. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Aug 15 07:30: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 2CBC3130F7C for ; Wed, 15 Aug 2018 07:30:09 -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 nmsTV-4NGaq5 for ; Wed, 15 Aug 2018 07:30: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 6B9181277D2 for ; Wed, 15 Aug 2018 07:30:02 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id s198-v6so2208123oih.11 for ; Wed, 15 Aug 2018 07:30: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=R8JziYCYhYFvkUY98SyI1FkwKED2+KMybAmZJlwldw8=; b=iAlAJ4CMGicSe0dWwXVDe8HT7sDWlC+Hzg9ZML2OagRMQqcMjowk5MYtnQ5MQDZmPj G+sfl2ktQDvs/dFKBy/LX2dPqeam5XV2bhbO3ClmJaVLcXX/X/eSCXJw+R53NrCoNAed EyyqMHLcrWPUIEdYFUN9WC1bMJ/J1RJn+SO6957S4c0om3FkL6eTg0kewVodl/SnZE42 7Q9ECFnqo0ykaQkm0EN/fnwGQ7V48PGNdWtiFP5XDQl7eNoUKmrIC0gaJW2sJ+vPjiwg 4COaJ68J/0jwaydcmqVRMODiffLiHFsu3JdmxEenZatx6cqwVmFcFjTEequpYLT3SRkj AJZQ== 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=R8JziYCYhYFvkUY98SyI1FkwKED2+KMybAmZJlwldw8=; b=SrYDksPzXBgi8JF2BdPNHjOaUQHsFoYw42s0EAH4BPaLjEpBZS3S2mwLe61HcmnekM 3Tj1c2vPDSfeXflNk+JYybR+R2p4eUGoMEOdaJuMgORsdd0Vi38VEgTTZ2O2KTJmhKOu BtnT5FnswNth7o3qZ7Zk/RtjRIZ8tamoPFh5kdqTOhq2Kt65SfYS9l+Ytjj2Ky+jTc+B bakO6wSEBrmPPkkfUVjKTvC/8dYta5D/uzs/bU8npYL6sCW435JwFtdlpyCGQEX/oWzZ OUtyFu7/r87VcoQU3IhxbgK95drLecPWYNouD5avvTwQyma4Xk2RQvTi+pCRjdTlUgzt nQFQ== X-Gm-Message-State: AOUpUlGHoYDzV49/aoTeL9kVLDAEl77SA0ffgqi979pZFUNfY4EUkvTN LDnsFUjRi1yGFQ1/N7KCiA0akzh9YpGDuEvho2270KoGm7RUgg== X-Google-Smtp-Source: AA+uWPyhGtGMoCPac9Ct9LgCs4p9X38h+rTUAdjcVdL3qSsQ/WKeKW8PMAEPfRsRqX7xEeZC4162s6rhXBEsGGQiiUY= X-Received: by 2002:aca:d088:: with SMTP id j8-v6mr27592372oiy.276.1534343401190; Wed, 15 Aug 2018 07:30:01 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:2646:0:0:0:0:0 with HTTP; Wed, 15 Aug 2018 07:29:40 -0700 (PDT) In-Reply-To: <799c2b18-97fe-6e22-f2cf-49245ae9c65e@gmail.com> References: <20180730221726.713CE200316625@ary.qy> <799c2b18-97fe-6e22-f2cf-49245ae9c65e@gmail.com> From: Seth Blank Date: Wed, 15 Aug 2018 07:29:40 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000064591d05737a29e6" 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, 15 Aug 2018 14:30:09 -0000 --00000000000064591d05737a29e6 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 15, 2018 at 6:33 AM, Dave Crocker wrote: > > This doesn't sound like compelling benefit, which is why I suggest > removing it. Absent compelling benefit, simpler specifications is to be > preferred, IMO. Absolutely agreed on simplifying the spec, but the above conversation misses the points in the email I sent an hour or two earlier. In particular, there was a design decision made at the genesis of ARC to store excess trace information that receivers could use to further analyze the Chains on the receipt. This is well documented in 11.3.3, as part of the experiment is looking into what trace information is actually valuable. As I've mentioned previously several times in this thread, without the Seal that affixes cv=fail to the message including all the ARC header fields in its scope, this trace information is no longer authenticatable and therefore cannot be trusted. This is a violation of the explicit design decision this protocol was built up from. But to also reiterate: what is Sealed when cv=fail is attested to (itself, the entire chain, or nothing at all) DOES NOT AFFECT INTEROPERABILITY. What it does effect are preserving trace information and preventing forged data from being reportable. This seems deeply valuable to me. --00000000000064591d05737a29e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Aug 15, 2018 at 6:33 AM, Dave Crocker <dcrocker@gmail.com> wrote:
This doesn't sound like compelling benefit, which is why I suggest remo= ving it.=C2=A0 Absent compelling benefit, simpler specifications is to be p= referred, IMO.

Absolutely agreed on simplif= ying the spec, but the above conversation misses the points in the email I = sent an hour or two earlier.

In particular, there = was a design decision made at the genesis of ARC to store excess trace info= rmation that receivers could use to further analyze the Chains on the recei= pt. This is well documented in 11.3.3, as part of the experiment is looking= into what trace information is actually valuable.

As I've mentioned previously several times in this thread, without the= Seal that affixes cv=3Dfail to the message including all the ARC header fi= elds in its scope, this trace information is no longer authenticatable and = therefore cannot be trusted. This is a violation of the explicit design dec= ision this protocol was built up from.

But to also= reiterate: what is Sealed when cv=3Dfail is attested to (itself, the entir= e chain, or nothing at all) DOES NOT AFFECT INTEROPERABILITY. What it does = effect are preserving trace information and preventing forged data from bei= ng reportable. This seems deeply valuable to me.
--00000000000064591d05737a29e6-- From nobody Wed Aug 15 11:30: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 A0CAF130DF3 for ; Wed, 15 Aug 2018 11:30:24 -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, 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 IwmzljWvw9SL for ; Wed, 15 Aug 2018 11:30: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 2E8A3130DEA for ; Wed, 15 Aug 2018 11:30:23 -0700 (PDT) Received: (qmail 68752 invoked from network); 15 Aug 2018 18:30:22 -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; 15 Aug 2018 18:30:22 -0000 Received: by ary.qy (Postfix, from userid 501) id 09ED420038205D; Wed, 15 Aug 2018 14:30:21 -0400 (EDT) Date: 15 Aug 2018 14:30:21 -0400 Message-Id: <20180815183022.09ED420038205D@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: dcrocker@gmail.com In-Reply-To: <799c2b18-97fe-6e22-f2cf-49245ae9c65e@gmail.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] 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, 15 Aug 2018 18:30:25 -0000 In article <799c2b18-97fe-6e22-f2cf-49245ae9c65e@gmail.com> you write: >So the extra mechanism is intended an efficiency hack. No, it also documents the fact that the chain was broken when it arrived at the cv=fail signer. Without it, a subsequent hop can't tell. It probably won't make much difference to spam filters, but it could be useful if you're trying to find and fix forwarders that make gratuitous changes. I think there's a modest benefit to signing with cv=fail, and since you can't count on having a chain (even an invalid one) signing as if it were cv=none seems reasonable. R's, John PS: Once there is a cv=fail seal, there doesn't seem to be any point to adding any more seals in later hops. It's dead, Jim. From nobody Wed Aug 15 11:41: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 E54EA130DF2 for ; Wed, 15 Aug 2018 11:41:41 -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 UoYZ7qGiHnxp for ; Wed, 15 Aug 2018 11:41:39 -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 A9ACC130DE1 for ; Wed, 15 Aug 2018 11:41:39 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id w126-v6so3628262oie.7 for ; Wed, 15 Aug 2018 11:41:39 -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=Fvg4BP7NQ3RnXy5vrRLYfuOlkWwbr6aTFRC/GOVufJU=; b=epOAuYJYcgVhbnD5hvFTTvLov3u8nMfkmzTxGD9YrMXlgH3cKPQ3Ltdxm+WQWNSgQf suupUekKaVZS9MnjF+uiYXLaJz8dNxmHMNa4rizYt0Q4iYvegAD0qdnZAL5I5Nqkj0se 3aWF0e3LpdEF9bZPhG9TZ+wpOakpm19PRJRwPJko1dKTkx+pXiToxIQ+bWw0lc6nV2Ul BJyo3zs4OKJicxzTziS8NQNUHG8OtCHQprLn7IqpZyaHyrpsNdSwALZRVnJaiyV4frq1 cEU3cEFs6MMbcW8QVFuZSpht97Y8uNTJfPBnBN5CaKv+fhN1YHlPYKslBRn2MltLguWm D+Yg== 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=Fvg4BP7NQ3RnXy5vrRLYfuOlkWwbr6aTFRC/GOVufJU=; b=ZJz6ojt/dNk7Q9w6Y4MUarkoXmsEddUpIARtJcHeBHcIk0clYwc5zbGodEKSPKnAlf nN99V/wJ7IzNLdCnnNKzO6ovfuH17lutay5wLO0wIEpxQHPEfsqpJaUO6aMxRMYzbYbt u81vwj0YVB09f/gL3QCPzwBG5l1jz8jiJ1XodNphmzwrilgG5CtME1Nc+08hUUmKaQO2 /PP3pV8gwvXDP7WxChOkyflueXyIPYEhD6uvLFogpeqxBgrHl+8T4iKEiEhgTvMEXoiE lR42jC3d0WZUNjE6e/3J8w5/6O/i7CPlHTRV1WPHRol2gA63qUNvrH7jYC43+O4c9/2x fq8w== X-Gm-Message-State: AOUpUlEFY9my6IwaL48p8+zySaLpdW7+huQvfrUqxa45sACrgfVkncsn UQissRXMTtRR50xf7CEevIPslNI0vXYgri8IeMk2iw== X-Google-Smtp-Source: AA+uWPyIByoDmvZAEAdQYoMTr+QgFe8xBV7OTpxxmrd8MSxGbEA2HjDCkPgjcNzzObOlvGWqWkl6do1Hgv6KDvYStqk= X-Received: by 2002:aca:d9c5:: with SMTP id q188-v6mr26110051oig.239.1534358498909; Wed, 15 Aug 2018 11:41:38 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:2646:0:0:0:0:0 with HTTP; Wed, 15 Aug 2018 11:41:18 -0700 (PDT) In-Reply-To: <20180815183022.09ED420038205D@ary.qy> References: <799c2b18-97fe-6e22-f2cf-49245ae9c65e@gmail.com> <20180815183022.09ED420038205D@ary.qy> From: Seth Blank Date: Wed, 15 Aug 2018 11:41:18 -0700 Message-ID: To: John Levine Cc: IETF DMARC WG , Dave Crocker Content-Type: multipart/alternative; boundary="0000000000004933fd05737dadd9" 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, 15 Aug 2018 18:41:42 -0000 --0000000000004933fd05737dadd9 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 15, 2018 at 11:30 AM, John Levine wrote: > In article <799c2b18-97fe-6e22-f2cf-49245ae9c65e@gmail.com> you write: > >So the extra mechanism is intended an efficiency hack. > > No, it also documents the fact that the chain was broken when it > arrived at the cv=fail signer. Without it, a subsequent hop can't > tell. It probably won't make much difference to spam filters, but > it could be useful if you're trying to find and fix forwarders > that make gratuitous changes. > Exactly. > I think there's a modest benefit to signing with cv=fail, and since > you can't count on having a chain (even an invalid one) signing as > if it were cv=none seems reasonable. > It's this, as well as what I outlined in my previous message. > PS: Once there is a cv=fail seal, there doesn't seem to be any point > to adding any more seals in later hops. It's dead, Jim. > Absolutely, and the spec very clearly said this prior to the -15 reorg, but it appears that has disappeared. Fixed. --0000000000004933fd05737dadd9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Aug 15, 2018 at 11:30 AM, John Levine <johnl@taugh.com> wr= ote:
In article <799c2b18-97fe= -6e22-f2cf-49245ae9c65e@gmail.com> you write:
>So the extra mechanism is intended an efficiency hack.

No, it also documents the fact that the chain was broken when it
arrived at the cv=3Dfail signer.=C2=A0 Without it, a subsequent hop can'= ;t
tell.=C2=A0 It probably won't make much difference to spam filters, but=
it could be useful if you're trying to find and fix forwarders
that make gratuitous changes.

Exactly.<= /div>
=C2=A0
I think there's a modest benefit to signing with cv=3Dfail, and since you can't count on having a chain (even an invalid one) signing as
if it were cv=3Dnone seems reasonable.

= It's this, as well as what I outlined in my previous message.
=C2=A0
PS: Once there is a cv=3Dfail s= eal, there doesn't seem to be any point
to adding any more seals in later hops.=C2=A0 It's dead, Jim.

Absolutely, and the spec very clearly said this = prior to the -15 reorg, but it appears that has disappeared. Fixed.
--0000000000004933fd05737dadd9-- From nobody Wed Aug 15 11:48: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 022F2130DFB for ; Wed, 15 Aug 2018 11:48: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, 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 oGHF_qXrKSDK for ; Wed, 15 Aug 2018 11:48:44 -0700 (PDT) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0: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 268D2130DF2 for ; Wed, 15 Aug 2018 11:48:44 -0700 (PDT) Received: by mail-pg1-x52c.google.com with SMTP id w10-v6so889088pgv.2 for ; Wed, 15 Aug 2018 11:48:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=fMrWb7T7I/tyLhJwpMZURrrHP2/Ipql45iW9V0xihzo=; b=b6nu01f2NZngJxLgdNelS8Hz/WaSen7+02fBsrAro9DNtOH1O7ipoDnOmfjuwkgJG7 yMF3Pych2vORpIyY5k69FAkJ8DhdGl7Q8PJCcNgQ2rgBuLrrMuSSrwmK3y+mxennuebg IsFKi2PxRp8b4TOdY5AWBcfOt7Z3Xpc6q3ryxwAdYZ34dqb7mve7AoTRIoRwXart34QJ ewaVnoy2TxVFZ9Gbn0K2g4TChQ5cs05CHUNFvJIO8MprlegnNPBYvXK2ML1YgnmnbhwQ o/nl2epi7BYB3AysY9ldPsITtggcs7jHSjSpD8aHmmTYbwbw6sP4V3Fdt0bnuZ+43CnM Mhmg== 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:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=fMrWb7T7I/tyLhJwpMZURrrHP2/Ipql45iW9V0xihzo=; b=oj789pail8Zo61g5ENOmePtVBSQP7D8cqVF7XoxWniYe2p2dXIiZJG22hP/r8F5bzo Cw0xLQcuC0iZ91CoK6RvNRiG82DdGQBU7Xumz0xgmHDD5onP3mvkiGAVeeT+OBkOwYOt YabftMalWJJRRUBdpL3Go6myiFI8CrcUMZ/uVZEcBX2saQIeZgzNDDlsvOLWWq1wmaNN B7csyO1MKezshqLHU4mjLn8F5ypm2Mc8rVwRDokiZLUd1Wg9SbEv9sv3X7lOBKT+N1X3 GOFie7HbWjjiwoAENk+gpUyIzatKh5sTLtB2UygfTSQtHVJWWntCwzW/6N4doi+u9E64 BXmg== X-Gm-Message-State: AOUpUlGJKsx+tY2WFtaDxOuOYWmAmcsaabdazZiNKYClSUejZJ20R/8Y TC8RKHTSpZAdon23iDimSVACkwIx X-Google-Smtp-Source: AA+uWPy5efcx063JrKe/TU6OxKsKlz35uh9U8L6zS4N+Lu131cXRRx6aOS/xb6YV7zc6BI+xEQ/BnA== X-Received: by 2002:a62:6b44:: with SMTP id g65-v6mr28782929pfc.226.1534358923233; Wed, 15 Aug 2018 11:48:43 -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 y27-v6sm59900763pff.181.2018.08.15.11.48.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Aug 2018 11:48:42 -0700 (PDT) To: John Levine , dmarc@ietf.org References: <20180815183022.09ED420038205D@ary.qy> From: Dave Crocker Message-ID: <5a48a9af-1dc7-92dd-eaa8-c1df09ae26cf@gmail.com> Date: Wed, 15 Aug 2018 11:48:39 -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: <20180815183022.09ED420038205D@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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, 15 Aug 2018 18:48:46 -0000 On 8/15/2018 11:30 AM, John Levine wrote: > In article <799c2b18-97fe-6e22-f2cf-49245ae9c65e@gmail.com> you write: >> So the extra mechanism is intended an efficiency hack. > > No, it also documents the fact that the chain was broken when it > arrived at the cv=fail signer. Without it, a subsequent hop can't > tell. It probably won't make much difference to spam filters, but > it could be useful if you're trying to find and fix forwarders > that make gratuitous changes. > > I think there's a modest benefit to signing with cv=fail, and since > you can't count on having a chain (even an invalid one) signing as > if it were cv=none seems reasonable. Modest, indeed. Also unknown. This is building in a permanent behavior, for a use that is, at best, vague conjecture. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Aug 15 11:53: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 BE0F6130E31 for ; Wed, 15 Aug 2018 11:53:10 -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 9GWpZvNSNt2K for ; Wed, 15 Aug 2018 11:53:09 -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 B9CB9130E1F for ; Wed, 15 Aug 2018 11:53:08 -0700 (PDT) Received: (qmail 80895 invoked from network); 15 Aug 2018 18:53:07 -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; 15 Aug 2018 18:53:07 -0000 Date: 15 Aug 2018 14:53:07 -0400 Message-ID: From: "John R Levine" To: "Dave Crocker" Cc: dmarc@ietf.org In-Reply-To: <5a48a9af-1dc7-92dd-eaa8-c1df09ae26cf@gmail.com> References: <20180815183022.09ED420038205D@ary.qy> <5a48a9af-1dc7-92dd-eaa8-c1df09ae26cf@gmail.com> 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: Wed, 15 Aug 2018 18:53:11 -0000 On Wed, 15 Aug 2018, Dave Crocker wrote: > Modest, indeed. Also unknown. > > This is building in a permanent behavior, for a use that is, at best, vague conjecture. Well, sure, but we could say that about all of ARC. As far as I know nobody has any rules yet for evaluating ARC chains beyond "if it was originally from us and the chain is good, it's probably OK." The cost of adding the cv=fail signature is pretty low, and I don't see any way that it would make things worse. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed Aug 15 12:02: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 F28C01310F1 for ; Wed, 15 Aug 2018 12:02:04 -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 MLLRGjADYQxb for ; Wed, 15 Aug 2018 12:02:02 -0700 (PDT) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 2117313109F for ; Wed, 15 Aug 2018 12:01:51 -0700 (PDT) Received: by mail-pg1-x52f.google.com with SMTP id r1-v6so883328pgp.11 for ; Wed, 15 Aug 2018 12:01:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=DxssPzZOAKuPVZSI/ZX7zgw98pMT0Qq+YgRH1wQe3yQ=; b=XO934sllNiQbkVYlhktCDAHrm+6T/G1hCUsVmZhAJFYb6dysEx/wZpTInlp7LSvyTS splcOrRM5mNS5tsjQpkhEg+Z3JhCm+ljUpFvddWFekK5mTMECrqhHUky65oUqADfyecN GeNqsU3rxZ8LegAPzVu+LDG8K57WJANqDtVOVLNLZF+Q9mZmpKTSdAtfYUex41G+WKw1 fBOipJ5iWzwN1DBGxLGY8/S2d/hIjWJf95rmU3eZ+DazbgGDw0ba9i5LdWS++0t8hA6N osoNeYo1xAs1CN2FgksrjqMFI3CA5OXQCUcqXuP0NIoTLEb5g8vWcXXUdYjWCjQkK5x0 9/bQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=DxssPzZOAKuPVZSI/ZX7zgw98pMT0Qq+YgRH1wQe3yQ=; b=MAyRCwmlib7xmef2ki/DsxKKr7Y0QTTVrJdyiMMrleEkj29EhWlr0feJXqTnljRtAQ 2jg2YQZLjC7yOZXet4cStaa8XAvtxom8QM9LP1Pe6HsMfutZQl7+AFsUxzcdebCB+1bO gitACQYQeXLByxmQXlJAIYdPpPZOvlTwryTlAbc31t2E4/2yQ2JrrwmFzGrx+xArQjF6 6wy4EK73bXJFO/oW0MyxTgCh1kcZv237CZeFnEI2xXnMuWrbq7hVkgBxJfKrtjDr6SUm Rac+Y2KPLnaWuvnbdGnoeKplQ0m60sZPpImdyhAcoLhrh8ZX6yyrSnTZPzxgsbeQP+MV tWIQ== X-Gm-Message-State: AOUpUlFV+jMdliKWOKnsecMc8zd0PkXe5uYcW3+jtA5i6f2gbMZtZ4MB /NX6Uti/E/Xw/c6Wu9vaw2yUr09D X-Google-Smtp-Source: AA+uWPx6YFUp3J/ZXGMSRhdBM7XIX0trEuWywIawFsAyVYgIg6AEgO7oHo1ljDQU9xjp8JKtsaO4sw== X-Received: by 2002:a63:dd09:: with SMTP id t9-v6mr26186274pgg.370.1534359710090; Wed, 15 Aug 2018 12:01:50 -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 p19-v6sm36904760pgh.60.2018.08.15.12.01.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Aug 2018 12:01:47 -0700 (PDT) To: John R Levine Cc: dmarc@ietf.org References: <20180815183022.09ED420038205D@ary.qy> <5a48a9af-1dc7-92dd-eaa8-c1df09ae26cf@gmail.com> From: Dave Crocker Message-ID: Date: Wed, 15 Aug 2018 12:01:45 -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: 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: Wed, 15 Aug 2018 19:02:13 -0000 On 8/15/2018 11:53 AM, John R Levine wrote: > On Wed, 15 Aug 2018, Dave Crocker wrote: >> Modest, indeed.  Also unknown. >> >> This is building in a permanent behavior, for a use that is, at best, >> vague conjecture. > > Well, sure, but we could say that about all of ARC. No we can't. This is a very different kind and degree of vague (and without precedent, I believe (unless someone can point to operational experience on the net that is similar?) d/ ps. Hmmm. Unfortunately, this exchange does highlight that the considerable complexity of ARC is not really built upon any clear model of how all its provided information is expected to be used... -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Aug 15 12:54: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 C5B401310ED for ; Wed, 15 Aug 2018 12:54:24 -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 a7cEpZHGBq9n for ; Wed, 15 Aug 2018 12:54: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 D3278131071 for ; Wed, 15 Aug 2018 12:54:22 -0700 (PDT) Received: (qmail 11820 invoked from network); 15 Aug 2018 19:54: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; 15 Aug 2018 19:54:21 -0000 Date: 15 Aug 2018 15:54:21 -0400 Message-ID: From: "John R Levine" To: "Dave Crocker" Cc: dmarc@ietf.org In-Reply-To: References: <20180815183022.09ED420038205D@ary.qy> <5a48a9af-1dc7-92dd-eaa8-c1df09ae26cf@gmail.com> 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: 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, 15 Aug 2018 19:54:32 -0000 On Wed, 15 Aug 2018, Dave Crocker wrote: > This is a very different kind and degree of vague (and without precedent, I > believe (unless someone can point to operational experience on the net that > is similar?) I believe there are lots of trace fields that don't have a concrete use. I am not familiar with any standardized use of the values in the ID field in Received headers, although they're often handy in practice to track down the details of what happened to a message. Can you explain in words the damage that cv=fail signatures will cause, and a rough idea of the cost to ARC signers and verifiers? To me the answers are none, and trivial. R's, John From nobody Wed Aug 15 13:13: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 EDF4F131071 for ; Wed, 15 Aug 2018 13:13:48 -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 iklyICihZOQ6 for ; Wed, 15 Aug 2018 13:13:47 -0700 (PDT) Received: from mail-pl0-x22b.google.com (mail-pl0-x22b.google.com [IPv6:2607:f8b0:400e:c01::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 52A56130DE3 for ; Wed, 15 Aug 2018 13:13:47 -0700 (PDT) Received: by mail-pl0-x22b.google.com with SMTP id g6-v6so924403plq.9 for ; Wed, 15 Aug 2018 13:13:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=unQ6MY/r0HqAMHvKyIqHIYULCn+N2qkwcP1kr2SXt3A=; b=DQg7tyBzRjj713uxgc1ebpIndUw0T89svkxSVrI4PVQBpGJi3BDUzH0BnhQGNUvYHI AS93ZWPh9K+v+NooqDjZrJbnntU9U9jc20MIEzQ3sOehi+StUeJiQqDZ5FIFhQZVpQUf UNjLxy+WwsvNRCJdxzX7FES/pyZewXy1ghYrB4/N7W8z+n5MofRC2Qw0dsJcjFfDHVwU JV286DOa6OVXU8nl3MnnN7XQV96SO4lKs8Ipbsl98zVO1h+w6GgXoAULM0D1zJ5YSr6S hUE33o7j6fhOsgQrLYJrwI1gxTi9jLlQV0vRmal8yT3ZyzRgqA1hBdc+Esf04UqJKKos biyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=unQ6MY/r0HqAMHvKyIqHIYULCn+N2qkwcP1kr2SXt3A=; b=c9XClZjVWyogAAntLqawLxsCRaoaVmNt8xZ09ojObC6dUla+VtipOFk3qJdIs5dQhq h7sgzgTpW+caoQB5vfM/l/O6/LenK+lFycRLKC5f27kLMDYoQ5vyPW+oVFe3U4Msv7Y3 gPFPc9suUNhVKsKPI+iHONZyZy0FjbaIdaZeVaESpUOtpB7tqXBQxb4q/lKodmIemO+2 F9ciho+ri2WaEaaxU/peskt2Hy5HlrZBptJ0+/sJ0aKQgHKiAioNhHCa7Sg5KcZjhH+v sg4KCklQ/ugjIdQ0mH0Z7mPwprMSPDpikQ7tjkQ1vJbHV5EmINQSpP+OC8yFPQ53NPYj 5x3g== X-Gm-Message-State: AOUpUlEPCTfg1vdr1LDb+clyJsHMKG6f4LiULngt7r0tgBc25lf1eaG7 V91a0D+OrjtClyt+xVkDCo8s9vUd X-Google-Smtp-Source: AA+uWPwsDxX5vmajbV0DurXuMG06ssuWAbNizSjv3RC9terAGUlfLnM6yMcCJeVj6k0tMy54sRNq6g== X-Received: by 2002:a17:902:7446:: with SMTP id e6-v6mr26094411plt.161.1534364026435; Wed, 15 Aug 2018 13:13:46 -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 s73-v6sm35308801pfi.154.2018.08.15.13.13.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Aug 2018 13:13:45 -0700 (PDT) To: John R Levine Cc: dmarc@ietf.org References: <20180815183022.09ED420038205D@ary.qy> <5a48a9af-1dc7-92dd-eaa8-c1df09ae26cf@gmail.com> From: Dave Crocker Message-ID: <75b6e888-43fa-af1d-32ca-c16f54b35b7b@gmail.com> Date: Wed, 15 Aug 2018 13:13:43 -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: 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: Wed, 15 Aug 2018 20:13:49 -0000 On 8/15/2018 12:54 PM, John R Levine wrote: > Can you explain in words the damage that cv=fail signatures will cause, > and a rough idea of the cost to ARC signers and verifiers?  To me the > answers are none, and trivial. You have the obligations reversed. When adding things -- which adds overhead and makes the system more complicated and increase the likelihood of bugs -- the affirmative obligation is on folk advocating the addition. As for the fact that there are other mechanisms of limited or unknown benefit that we've had, possibly for a long time, everything about ARC is significantly more complicated, including this failure add-on. And the add-on is of especially unclear benefit. It has intuitive appeal, which seems to get in the way of being able to clearly address actual need and benefit. At any rate, I've expressed my concerns more than amply and don't feel the need of arguing my position further. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Aug 17 12:47: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 436A7130E6A for ; Fri, 17 Aug 2018 12:47:42 -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 YKU3adpV-HOC for ; Fri, 17 Aug 2018 12:47:40 -0700 (PDT) Received: from copdcmhout02.cable.comcast.com (copdcmhout02.cable.comcast.com [96.114.158.212]) (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 36FB9130E06 for ; Fri, 17 Aug 2018 12:47:40 -0700 (PDT) X-AuditID: 60729ed4-428c89e000006f94-81-5b77265fb84c Received: from COPDCEX17.cable.comcast.com (copdcmhoutvip.cable.comcast.com [96.114.156.147]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by copdcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id AE.E9.28564.F56277B5; Fri, 17 Aug 2018 13:47:43 -0600 (MDT) Received: from COPDCEX19.cable.comcast.com (147.191.124.150) by COPDCEX17.cable.comcast.com (147.191.124.148) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Fri, 17 Aug 2018 13:43:19 -0600 Received: from COPDCEX19.cable.comcast.com ([fe80::3aea:a7ff:fe36:8380]) by COPDCEX19.cable.comcast.com ([fe80::3aea:a7ff:fe36:8380%19]) with mapi id 15.00.1365.000; Fri, 17 Aug 2018 13:43:19 -0600 From: "Brotman, Alexander" To: John R Levine , Dave Crocker CC: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily Thread-Index: AQHUJF9Ldn72CSr8lEOjExnNeb0DeaSjl8WAgAAC4YCAAB2VAIAAAlYAgACZmoCAAXoUgIABbUuAgAFBbACAACwMgIAAGQSAgAAiTYCAAAYRAIAFzxSAgAAISoCAAAHBAIAAV5aAgATQz4CAAPkpgIAGqO2AgAADSACABTwxAIAAh44AgABS3YCAAAUdgIAAAUCAgAACaYCAAA6ygIACunHg Date: Fri, 17 Aug 2018 19:43:18 +0000 Message-ID: References: <20180815183022.09ED420038205D@ary.qy> <5a48a9af-1dc7-92dd-eaa8-c1df09ae26cf@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [96.114.156.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLKsWRmVeSWpSXmKPExsWSUDRnsm68Wnm0wZ/lQhadv3cwWiw5tJbR 4nTPGiYHZo+ds+6yeyxZ8pPJ496W0ADmqAZGm5KMotTEEpfUtNS84lQ7LgUMYJOUmpZflOqa WJRTGZSak5qIXRlIZUpqTmZZapE+VmP0sZqT0MWU0f/9BmvBeZ6KVTtOsjQwTubqYuTkkBAw kTi9dTEriC0ksJNJ4tCE+C5GLiD7EKPEz437GSGck4wSHevegFWxCVhJvP3fzgxiiwi4SfS+ v8ECYjMLqErcv3AfLC4sEC/x/toFqJoEiaOf7rCDDBIReMYo8WPVTCaQBAtQw9rWCWDNvAJe Et8vT2KG2PaNUeLzlatgRZwClhKzuk6xg9iMAmIS30+tYYLYJi5x68l8JogfBCSW7DnPDGGL Srx8/I8VwjaQ2Lp0HwuErSDRM2E6M0SvjsSC3Z/YIGxtiWULXzNDHCEocXLmE6h6cYnDR3aw TmCUmIVk3Swk7bOQtM9C0r6AkWUVI5+lmZ6hoYmeoamFnpGh0SZGcKKZd2UH4+XpHocYBTgY lXh4S5XLo4VYE8uKK3OBoc3BrCTCG7m8LFqINyWxsiq1KD++qDQntfgQozQHi5I47+OJpdFC AumJJanZqakFqUUwWSYOTqkGxvDHv2r+pRYHXuJRcrZ1s5j2m8fg6KXA1imbHs6Q+v2c8+SV xHSB+03ffePdPTkV9Dc06LUL+bNPvJk4NTdVJv+t5AwJ6cWRV9q0is8UCuRsdNr9+MsxCb84 0/3NIa+23Nwo++mOtOHc5u65jW12pf195uoXwzgUDs+0a+K6UXWvam6Pq5C1EktxRqKhFnNR cSIAfhiPSTADAAA= 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, 17 Aug 2018 19:47:42 -0000 I'd say that I agree with John (and Seth) on this one. I'm not sure if a c= onsensus was reached, though it doesn't appear so. I think the idea that b= eing able to have trust in the broken chain information potentially sent ba= ck to us as a report has value. It's hard to be sure that the value will o= verride the cost of the signature, but as John suggested below, I can't ima= gine the cost to be very high. -- Alex Brotman Sr. Engineer, Anti-Abuse Comcast -----Original Message----- From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of John R Levine Sent: Wednesday, August 15, 2018 3:54 PM To: Dave Crocker Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=3Dfail = should sign greedily On Wed, 15 Aug 2018, Dave Crocker wrote: > This is a very different kind and degree of vague (and without=20 > precedent, I believe (unless someone can point to operational=20 > experience on the net that is similar?) I believe there are lots of trace fields that don't have a concrete use.=20 I am not familiar with any standardized use of the values in the ID field i= n Received headers, although they're often handy in practice to track down = the details of what happened to a message. Can you explain in words the damage that cv=3Dfail signatures will cause, a= nd a rough idea of the cost to ARC signers and verifiers? To me the answer= s are none, and trivial. R's, John _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From nobody Fri Aug 17 14:30: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 4C83D130FC2 for ; Fri, 17 Aug 2018 14:30:05 -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 eaNiagk2PP8a for ; Fri, 17 Aug 2018 14:30:03 -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 954DA130FBB for ; Fri, 17 Aug 2018 14:30:02 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id f18-v6so6860761lfc.2 for ; Fri, 17 Aug 2018 14:30:02 -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=8dMPXaPYGhwSF4RZDGlCoXg1ddWyy0Qi8YgVNKucV7M=; b=YK6Hih5IqU/smucodrWBRVFPW8bn77jWA1V19lJGIhgU+PrcOavvM2DdAn8AKhX8/6 drhErusLa6JJvCl0NjEo41KcaIY2BgVJx/0O8pnnfOnw8YeXRckpgcnUf0z1BLXOY9XT Jj9/OSKM17LFGlbc0vUmU92zvGLXRSI9X4N7w= 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=8dMPXaPYGhwSF4RZDGlCoXg1ddWyy0Qi8YgVNKucV7M=; b=TQqukcxJ4kBiikObbZ1UyUFxzjLWvSPq35f3lPfCuHhRnHnfdXqSj3dE49ue4JxnGx YqcdVYccfhzocVJTMcIsE8/EzKDiNkq8hN/Jrf4Iz2wyOHo9GCyMASh4w2jpcy9P2DDf eq2gEOjYcNrbApEWKUrDO1TEGzyktvSHO2s5ArGeVLVYPxKvC6dhB8SN4w29cqYvI+mf xw7+39rKSVWgjNzbJ+vGiL31qhFTP9RgRrCkcgZe+y866wEQ2ou4W69QBjBl6Iq4hRfc xvVIcNKN9XiYzFpSvkG0tkq7Xwe7Z34qAMdc31Sg5fee72tvm+Rh57rJgEhc52bVxnH8 ltWw== X-Gm-Message-State: AOUpUlF5LanAc1o3HufBhdqiv3tZ/38svCd3+vwdWcDEfdYWPhszrrxy 6yxNMswF1I3I8DsgfVpcg+o+LGkm6ALUbG+oFAU77g== X-Google-Smtp-Source: AA+uWPzsv0w94KWsTjhf2cIN7lGMDomY00GIWYW0KSNv4kXz1WVle1HxkMF+SD+Ib2QXfEnZZjTPCi/mFooYHB0eZuY= X-Received: by 2002:a19:8f10:: with SMTP id r16-v6mr8642493lfd.1.1534541400781; Fri, 17 Aug 2018 14:30:00 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 2002:a19:5943:0:0:0:0:0 with HTTP; Fri, 17 Aug 2018 14:29:59 -0700 (PDT) In-Reply-To: References: <20180815183022.09ED420038205D@ary.qy> <5a48a9af-1dc7-92dd-eaa8-c1df09ae26cf@gmail.com> From: "Kurt Andersen (b)" Date: Fri, 17 Aug 2018 14:29:59 -0700 X-Google-Sender-Auth: mTBzq-9UPmhaomR7VEeF3_ekXho Message-ID: To: "Brotman, Alexander" Cc: John R Levine , Dave Crocker , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000164c4d0573a843d5" 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, 17 Aug 2018 21:30:05 -0000 --000000000000164c4d0573a843d5 Content-Type: text/plain; charset="UTF-8" I'm still at a bit of a loss as to how one can effectively do a "greedy" seal over a broken chain in a deterministic fashion. I'm also not sure why one would report much of anything (back to the hypothetical sending domain) from a broken chain, given that it has no validity. --Kurt On Fri, Aug 17, 2018 at 12:43 PM, Brotman, Alexander < Alexander_Brotman@comcast.com> wrote: > I'd say that I agree with John (and Seth) on this one. I'm not sure if a > consensus was reached, though it doesn't appear so. I think the idea that > being able to have trust in the broken chain information potentially sent > back to us as a report has value. It's hard to be sure that the value will > override the cost of the signature, but as John suggested below, I can't > imagine the cost to be very high. > > -- > Alex Brotman > Sr. Engineer, Anti-Abuse > Comcast > > > -----Original Message----- > From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of John R Levine > Sent: Wednesday, August 15, 2018 3:54 PM > To: Dave Crocker > Cc: dmarc@ietf.org > Subject: Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail > should sign greedily > > On Wed, 15 Aug 2018, Dave Crocker wrote: > > This is a very different kind and degree of vague (and without > > precedent, I believe (unless someone can point to operational > > experience on the net that is similar?) > > I believe there are lots of trace fields that don't have a concrete use. > I am not familiar with any standardized use of the values in the ID field > in Received headers, although they're often handy in practice to track down > the details of what happened to a message. > > Can you explain in words the damage that cv=fail signatures will cause, > and a rough idea of the cost to ARC signers and verifiers? To me the > answers are none, and trivial. > > R's, > John > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000164c4d0573a843d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm still at a bit of a loss as to how one can effecti= vely do a "greedy" seal over a broken chain in a deterministic fa= shion. I'm also not sure why one would report much of anything (back to= the hypothetical sending domain) from a broken chain, given that it has no= validity.

--Kurt
=
On Fri, Aug 17, 2018 at 12:43 PM, Brotman, A= lexander <Alexander_Brotman@comcast.com> wrote:<= br>
I'd say that I agree with John (and S= eth) on this one.=C2=A0 I'm not sure if a consensus was reached, though= it doesn't appear so.=C2=A0 I think the idea that being able to have t= rust in the broken chain information potentially sent back to us as a repor= t has value.=C2=A0 It's hard to be sure that the value will override th= e cost of the signature, but as John suggested below, I can't imagine t= he cost to be very high.

--
Alex Brotman
Sr. Engineer, Anti-Abuse
Comcast


-----Original Message-----
From: dmarc [mailto:dmarc-bounces= @ietf.org] On Behalf Of John R Levine
Sent: Wednesday, August 15, 2018 3:54 PM
To: Dave Crocker <dcrocker@gmail.c= om>
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=3Dfail = should sign greedily

On Wed, 15 Aug 2018, Dave Crocker wrote:
> This is a very different kind and degree of vague (and without
> precedent, I believe (unless someone can point to operational
> experience on the net that is similar?)

I believe there are lots of trace fields that don't have a concrete use= .
I am not familiar with any standardized use of the values in the ID field i= n Received headers, although they're often handy in practice to track d= own the details of what happened to a message.

Can you explain in words the damage that cv=3Dfail signatures will cause, a= nd a rough idea of the cost to ARC signers and verifiers?=C2=A0 To me the a= nswers are none, and trivial.

R's,
John

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

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

--000000000000164c4d0573a843d5-- From nobody Fri Aug 17 15:13: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 8C765130FCB for ; Fri, 17 Aug 2018 15:13:38 -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 RLL--lr1Ol6m for ; Fri, 17 Aug 2018 15:13:36 -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 9EF65130E15 for ; Fri, 17 Aug 2018 15:13:36 -0700 (PDT) Received: (qmail 70693 invoked from network); 17 Aug 2018 22:13:34 -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; 17 Aug 2018 22:13:34 -0000 Date: 17 Aug 2018 18:13:33 -0400 Message-ID: From: "John R Levine" To: "Kurt Andersen (b)" Cc: "dmarc@ietf.org" In-Reply-To: References: <20180815183022.09ED420038205D@ary.qy> <5a48a9af-1dc7-92dd-eaa8-c1df09ae26cf@gmail.com> 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: Fri, 17 Aug 2018 22:13:39 -0000 > I'm still at a bit of a loss as to how one can effectively do a "greedy" > seal over a broken chain in a deterministic fashion. I've been discussing this with Seth. Particularly once we start doing parallel chains for different algorithms, different implementations will disagree about what's a broken chain, so I'd just as soon not try. If the previous seal was good, add cv=fail only signing your own seal. If the previous seal was cv=fail, don't sign. 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 Aug 20 03:28: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 CA817130EBC for ; Mon, 20 Aug 2018 03:28: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, 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 0pYneoshZ5lp for ; Mon, 20 Aug 2018 03:28:44 -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 82212128BAC for ; Mon, 20 Aug 2018 03:28:43 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id u7-v6so11185334lji.3 for ; Mon, 20 Aug 2018 03:28: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=cvoN4behNjokY7jCOI04eVibZKD9fflnJ0gbkyld5KY=; b=iTG0nBuAt7jE3Q5z7dT5H+2uziTkI/WWdYRMjdCgcwG4te6Ewsv9Y6jytYSEPW5gZw MjeRe4I8f0Zd38/J3QPKQQeAzWymsa6dhz3XnU+6WVoUmu6xb3qjg43Vqf6MkNxXfpZl Wf6xbSySPDs01eKqldM+fzqfzg5TxyGQOZOV+Ge1EfOCOmaCkNlSq2350X8nSkfU62pj I2yXI69Upg7fvCufelrEK0pvLhdwB1UAmGCz1LdEmvE6data6GkdFofvU7xt/TYgfFRh xIbbT4yBxYeBdX41837+pmsXnL7ELt4b9IOyqJeYmBB8Km+9M8xW9LdsIYx+hAOlxIuD iwRw== 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=cvoN4behNjokY7jCOI04eVibZKD9fflnJ0gbkyld5KY=; b=BoByvcKslWo9kshm2MLPMkf1ZxsvKx/T8aA5GBIoUFNEXMhleFUYnA37ERMdowb1yq 736mW29QT8iCo0924T9THJAWQbCwp0rHAQbuX1ABdhrBLwNIx79h83KOG/SrlNFMeIqG x0phMqfFE0OMB2wzgekfSVuOts/Ku2vwFyJ72lTcmt42DKoHa5imw8XRv5fRhBkR735s Mmg9iyD019oukcgr3dpXzXI5rEDUhyCgE2puRiDE6I6U4jQe91wx0dylHZfaoDprrVbi CREuOMLYN17IwQPkiK517n/OKp9fbXDSGKL0G3bBzAtpsOG57GUVl6GBt/HQlm1UQm7I UHwQ== X-Gm-Message-State: AOUpUlEw+qDNWkrHmV1hZKgvM1b9DlIWr68ZK3L9VeE2HAn+S6UFLM7f hCuxzKZHs5ugfedTORI9jTFCoQyfcUXW0HuSFYY= X-Google-Smtp-Source: AA+uWPxGvIBX5zfZqdJsVaZVYPRxDRes9NzsHwNSK+RkgKce0Clyij6pGCokyb7n9nsSbWVezo99YyIeY3E78+FkwHo= X-Received: by 2002:a2e:4357:: with SMTP id q84-v6mr14176696lja.13.1534760921661; Mon, 20 Aug 2018 03:28:41 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:3a13:0:0:0:0:0 with HTTP; Mon, 20 Aug 2018 03:28:40 -0700 (PDT) In-Reply-To: References: <20180730221726.713CE200316625@ary.qy> From: "Murray S. Kucherawy" Date: Mon, 20 Aug 2018 03:28:40 -0700 Message-ID: To: Seth Blank Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000008d06010573db5f20" 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, 20 Aug 2018 10:28:46 -0000 --0000000000008d06010573db5f20 Content-Type: text/plain; charset="UTF-8" (back from vacation and catching up) On Tue, Aug 14, 2018 at 8:58 PM, Seth Blank wrote: > There are THREE consumers of ARC data (forgive me for the names, they're > less specific than I'd like): > > 1) The ARC Validator. When the Validator sees a cv=fail, processing stops, > the chain is dead, and shall never be less dead. What is Sealed is > irrelevant. > Right. 2) The Receiver. An initial design decision inherent in the protocol is > that excess trace information will be collected, as it's unclear what will > actually be useful to receivers. 11.3.3 calls this out in detail. Without > Sealing the entire chain when attaching a cv=fail verdict, none of the > trace information is authenticatable to a receiver (see earlier message in > this thread as to why), which is the exact opposite of the design decision > the entire protocol is built on. To guarantee this trace information can be > authenticated, the Seal that contains cv=fail must include the entire chain > in its scope. This is where this thread started. > I see two possible workflows here: (1) Verifier (to use the DKIM term) detects "cv=fail" and stops, because there's nothing more to do. But the Receiver now has no ARC information except a raw "cv=fail" to relay via A-R or whatever. But this, as you point out, flies in the face of the notion of giving receivers details about the message. The Receiver now has to implement ARC to get whatever details might be prudent from the message. (2) Verifier sees "cv=fail" but will still attempt to verify it and maybe extract other salient details to add to an A-R. When you say "you see cv=fail and stop", I think of the first thing, which is alarming layer mush, and is also ambiguous in that if the Verifier stops dead at seeing "cv=fail", it doesn't matter at all what content got sealed. So if you mean the second thing, part of my issue goes away. 3) The receiver of reports that provide ARC data. For a domain owner to get > a report with ARC information in it, there needs to be some level of trust > in the information reported back. When a Chain passes, all the > intermediaries' header field signatures can be authenticated, and the > mailflow can be cleanly reported back. When a Chain fails, that is > important information to a domain owner (where is my mailflow failing me, > how can I figure this out so I can fix it?). Again, without Sealing over > the entire Chain when a failure is detected, this information is > unauthenticatable (and worse, totally forgeable now without even needing a > valid Chain to replay), and nothing of substance can be reported back. > Sealing the Chain when a cv=fail is determined blocks forgery as a vector > to report bogus information, and allows authenticatable information to be > reported back. > I think we're talking about distinct failure modes. I totally agree with you in the case where the chain has failed because content was altered. But doesn't your assertion here presuppose an at least syntactically intact chain? If the chain is damaged to the point where it cannot be deterministically interpreted, the sealer adding the "cv=fail" might add a seal that a downstream verifier cannot correctly interpret. I understand what you're after but I also understand the intent behind 5.1.2, which is to produce something unambiguous. My problem with 5.1.2 as it stands is that a verifier now has to try verifying the "cv=fail" two ways (one with everything, one with just the last instance), and at least one of them has to work. We've cornered ourselves here by rejecting "cv=invalid". > > And to be even clearer: what is Sealed when cv=fail is reached (itself, > the entire chain, or nothing at all) DOES NOT AFFECT INTEROPERABILITY. But > it does effect preserving trace information and preventing forged data from > being reportable. > I disagree, as stated above; a mangled chain cannot be sealed in a way guaranteed to interoperate. This is my very strong INDIVIDUAL opinion. But I'm fine if the group sees > differently, as this could be investigated as part of the experiment (i.e. > do any of the above points matter in the real world? I say they do, hence > the strong opinion.). As an editor, I'll make sure whatever the consensus > of the group is is reflected in the document. > I've no objection to collecting superfluous trace information to support the experiment. What I'm concerned about is the introduction of weird protocol artifacts or ambiguities that could get baked in and hard to remove later. -MSK --0000000000008d06010573db5f20 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(back from vacation and catching up)

On Tue, Aug 14, 2018 at 8:58 P= M, Seth Blank <seth@sethblank.com> wrote:
There are THREE consumers of ARC data = (forgive me for the names, they're less specific than I'd like):
1) The ARC Validator. When the Validator sees a cv=3Dfail,= processing stops, the chain is dead, and shall never be less dead. What is= Sealed is irrelevant.

<= div>Right.

2) The Rece= iver. An initial design decision inherent in the protocol is that excess tr= ace information will be collected, as it's unclear what will actually b= e useful to receivers. 11.3.3 calls this out in detail. Without Sealing the= entire chain when attaching a cv=3Dfail verdict, none of the trace informa= tion is authenticatable to a receiver (see earlier message in this thread a= s to why), which is the exact opposite of the design decision the entire pr= otocol is built on. To guarantee this trace information can be authenticate= d, the Seal that contains cv=3Dfail must include the entire chain in its sc= ope. This is where this thread started.

I see two possible workflows here:

(= 1) Verifier (to use the DKIM term) detects "cv=3Dfail" and stops,= because there's nothing more to do.=C2=A0 But the Receiver now has no = ARC information except a raw "cv=3Dfail" to relay via A-R or what= ever.=C2=A0 But this, as you point out, flies in the face of the notion of = giving receivers details about the message.=C2=A0 The Receiver now has to i= mplement ARC to get whatever details might be prudent from the message.
=
(2) Verifier sees "cv=3Dfail" but will still attem= pt to verify it and maybe extract other salient details to add to an A-R.

When you say "you see cv=3Dfail and stop"= , I think of the first thing, which is alarming layer mush, and is also amb= iguous in that if the Verifier stops dead at seeing "cv=3Dfail", = it doesn't matter at all what content got sealed.

<= div>So if you mean the second thing, part of my issue goes away.
<= br>
3) The receiver of reports that provide = ARC data. For a domain owner to get a report with ARC information in it, th= ere needs to be some level of trust in the information reported back. When = a Chain passes, all the intermediaries' header field signatures can be = authenticated, and the mailflow can be cleanly reported back. When a Chain = fails, that is important information to a domain owner (where is my mailflo= w failing me, how can I figure this out so I can fix it?). Again, without S= ealing over the entire Chain when a failure is detected, this information i= s unauthenticatable (and worse, totally forgeable now without even needing = a valid Chain to replay), and nothing of substance can be reported back. Se= aling the Chain when a cv=3Dfail is determined blocks forgery as a vector t= o report bogus information, and allows authenticatable information to be re= ported back.

I thin= k we're talking about distinct failure modes.=C2=A0 I totally agree wit= h you in the case where the chain has failed because content was altered.= =C2=A0 But doesn't your assertion here presuppose an at least syntactic= ally intact chain?=C2=A0 If the chain is damaged to the point where it cann= ot be deterministically interpreted, the sealer adding the "cv=3Dfail&= quot; might add a seal that a downstream verifier cannot correctly interpre= t.

I understand what you're after but I also understand the intent behi= nd 5.1.2, which is to produce something unambiguous.=C2=A0 My problem with = 5.1.2 as it stands is that a verifier now has to try verifying the "cv= =3Dfail" two ways (one with everything, one with just the last instanc= e), and at least one of them has to work.=C2=A0 We've cornered ourselve= s here by rejecting "cv=3Dinvalid".
=C2=A0
And to be even clearer: what is Sea= led when cv=3Dfail is reached (itself, the entire chain, or nothing at all)= DOES NOT AFFECT INTEROPERABILITY. But it does effect preserving trace info= rmation and preventing forged data from being reportable.
=

I disagree, as stated above; a mangled cha= in cannot be sealed in a way guaranteed to interoperate.

This is my very strong INDIVIDUAL opinio= n. But I'm fine if the group sees differently, as this could be investi= gated as part of the experiment (i.e. do any of the above points matter in = the real world? I say they do, hence the strong opinion.). As an editor, I&= #39;ll make sure whatever the consensus of the group is is reflected in the= document.

I've= no objection to collecting superfluous trace information to support the ex= periment.=C2=A0 What I'm concerned about is the introduction of weird p= rotocol artifacts or ambiguities that could get baked in and hard to remove= later.

-MSK
--0000000000008d06010573db5f20-- From nobody Mon Aug 20 07:03: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 CE27A130E41 for ; Mon, 20 Aug 2018 07:03: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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=jvrlJcCg; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=z0J2qvEb 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 I1S5Tql6X0_y for ; Mon, 20 Aug 2018 07:03:00 -0700 (PDT) Received: from mail.santronics.com (groups.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id A6845126BED for ; Mon, 20 Aug 2018 07:02:59 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=6824; t=1534773772; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=2dxg8QDPpS/zn+3+uvtAWqrnNJk=; b=jvrlJcCg1D3aEqO6GfEfPYj4nsx6uoOHK19YckTXHjkZdcx/cQU2vWSKeCZuR9 oiBlM71UkTMAR0P15Dw2K6QbcwF/GQ4vKHYUY2DlFoVGkvC2ekPRZyuck+jVRaKR QdgtW9kQXto4+ojOGj8vWewQs00D0Vd30zPwiAJD/Bf8E= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Mon, 20 Aug 2018 10:02:52 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 3167402158.1.7328; Mon, 20 Aug 2018 10:02:51 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=6824; t=1534773115; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=ZWfJRxT dddaRyFDO87MSHD9tajBbtLtfrFtPhZrUIPk=; b=z0J2qvEbb7MvueK2e7ph+BB ikkmIMsgn3JSgBmWqKxkUjhYrYSrehSP6WrhFN9nm55qi5y0gHYlnNs+wkjoV6K5 JHJQIP3JXw92IVKcDgyrKw3QdsUt+ugpARSpby9p509h5ipNzDbX6tA3QFJ3FCxp bVosuvauOhUlgZ0R4kwQ= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Mon, 20 Aug 2018 09:51:55 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 757458454.9.191264; Mon, 20 Aug 2018 09:51:54 -0400 Message-ID: <5B7ACA08.1010201@isdg.net> Date: Mon, 20 Aug 2018 10:02:48 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: "Murray S. Kucherawy" , Seth Blank CC: IETF DMARC WG References: <20180730221726.713CE200316625@ary.qy> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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, 20 Aug 2018 14:03:04 -0000 Hi, I agree with your comments. My input. Keep in mind, that ignorant (non-supportive) ARC nodes will continue to process all DKIM-signature(s) found, such as what I see with your message: Authentication-Results: dkim.winserver.com; dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org; adsp=none author.d=gmail.com signer.d=ietf.org; dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org; adsp=none author.d=gmail.com signer.d=ietf.org; dkim=fail (DKIM_BODY_HASH_MISMATCH) header.d=gmail.com header.s=20161025 header.i=gmail.com; adsp=none author.d=gmail.com signer.d=gmail.com; That should be the first consideration and understanding in the pre-ARC DKIM world, i.e. how things are done now. The order of the DKIM-signatures is generaly important here since the typical scenario (with a list) is: 1) Good 1st original Author Domain signature is submitted, 2) 1st signature invalidated at middle ware (LIST), 3) Good 2nd Signature (resign) for LIST distribution 4) MDA see failed original AUTHOR ADSP/DMARC Policy. Overall, the MDA has no explicit 3rd party trust/policy knowledge of LIST or signatures beyond the 1st Author Domain (now broken) signature. That's the basic issue and 12+ years old DKIM Policy model protocol dilemma. I suppose there could be more middle ware, nodes, etc during the transport, but the First and Final processing nodes should be the essential protocol consideration. If there is an cv=fail at #2, does that mean the resigning at #3 is invalidated as well? We never really cared what happens in between during the transport, but with ARC it appears to be a major consideration to better understand transport paths. How ARC will turn all this around, it remains to be be seen. I wish to understand this complex protocol first before justifying the massive overhead and experimentation cost being asked of SMTP/Email developers. Thanks Hector Santos, CTO Santronics Software, Inc. On 8/20/2018 6:28 AM, Murray S. Kucherawy wrote: > (back from vacation and catching up) > > On Tue, Aug 14, 2018 at 8:58 PM, Seth Blank > wrote: > > There are THREE consumers of ARC data (forgive me for the names, > they're less specific than I'd like): > > 1) The ARC Validator. When the Validator sees a cv=fail, > processing stops, the chain is dead, and shall never be less dead. > What is Sealed is irrelevant. > > > Right. > > 2) The Receiver. An initial design decision inherent in the > protocol is that excess trace information will be collected, as > it's unclear what will actually be useful to receivers. 11.3.3 > calls this out in detail. Without Sealing the entire chain when > attaching a cv=fail verdict, none of the trace information is > authenticatable to a receiver (see earlier message in this thread > as to why), which is the exact opposite of the design decision the > entire protocol is built on. To guarantee this trace information > can be authenticated, the Seal that contains cv=fail must include > the entire chain in its scope. This is where this thread started. > > > I see two possible workflows here: > > (1) Verifier (to use the DKIM term) detects "cv=fail" and stops, > because there's nothing more to do. But the Receiver now has no ARC > information except a raw "cv=fail" to relay via A-R or whatever. But > this, as you point out, flies in the face of the notion of giving > receivers details about the message. The Receiver now has to > implement ARC to get whatever details might be prudent from the message. > > (2) Verifier sees "cv=fail" but will still attempt to verify it and > maybe extract other salient details to add to an A-R. > > When you say "you see cv=fail and stop", I think of the first thing, > which is alarming layer mush, and is also ambiguous in that if the > Verifier stops dead at seeing "cv=fail", it doesn't matter at all what > content got sealed. > > So if you mean the second thing, part of my issue goes away. > > 3) The receiver of reports that provide ARC data. For a domain > owner to get a report with ARC information in it, there needs to > be some level of trust in the information reported back. When a > Chain passes, all the intermediaries' header field signatures can > be authenticated, and the mailflow can be cleanly reported back. > When a Chain fails, that is important information to a domain > owner (where is my mailflow failing me, how can I figure this out > so I can fix it?). Again, without Sealing over the entire Chain > when a failure is detected, this information is unauthenticatable > (and worse, totally forgeable now without even needing a valid > Chain to replay), and nothing of substance can be reported back. > Sealing the Chain when a cv=fail is determined blocks forgery as a > vector to report bogus information, and allows authenticatable > information to be reported back. > > > I think we're talking about distinct failure modes. I totally agree > with you in the case where the chain has failed because content was > altered. But doesn't your assertion here presuppose an at least > syntactically intact chain? If the chain is damaged to the point > where it cannot be deterministically interpreted, the sealer adding > the "cv=fail" might add a seal that a downstream verifier cannot > correctly interpret. > > I understand what you're after but I also understand the intent behind > 5.1.2, which is to produce something unambiguous. My problem with > 5.1.2 as it stands is that a verifier now has to try verifying the > "cv=fail" two ways (one with everything, one with just the last > instance), and at least one of them has to work. We've cornered > ourselves here by rejecting "cv=invalid". > > And to be even clearer: what is Sealed when cv=fail is reached > (itself, the entire chain, or nothing at all) DOES NOT AFFECT > INTEROPERABILITY. But it does effect preserving trace information > and preventing forged data from being reportable. > > > I disagree, as stated above; a mangled chain cannot be sealed in a way > guaranteed to interoperate. > > This is my very strong INDIVIDUAL opinion. But I'm fine if the > group sees differently, as this could be investigated as part of > the experiment (i.e. do any of the above points matter in the real > world? I say they do, hence the strong opinion.). As an editor, > I'll make sure whatever the consensus of the group is is reflected > in the document. > > > I've no objection to collecting superfluous trace information to > support the experiment. What I'm concerned about is the introduction > of weird protocol artifacts or ambiguities that could get baked in and > hard to remove later. > > -MSK > From nobody Mon Aug 20 12:48: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 3B906127148 for ; Mon, 20 Aug 2018 12:48:22 -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 19oU60X1hp3j for ; Mon, 20 Aug 2018 12:48:20 -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 40E89130DC6 for ; Mon, 20 Aug 2018 12:48:20 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id f8-v6so12526573ljk.1 for ; Mon, 20 Aug 2018 12:48:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=En6UKHLc01EUIy4udtoYSEXFVssPIkh+CSFFAth8N0w=; b=WhtNmgtLopau/DSspsa5eWT3Pzrscytg2FiBTW2uDiFQSbNkr1hE5TE116cy5RFvfb AtGyWzhXiCcUiwCQx8f2W3DEMxcbKM1isMLmgGxMnbGAxTcXVX1tz7I1IguR/T3trHVJ kWePP6IruosPx1U4k0+PeoCrkAEiFWq2XuakA= 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=En6UKHLc01EUIy4udtoYSEXFVssPIkh+CSFFAth8N0w=; b=mg4hH+ZNm63bdNv4CpQIUR9jLnhEn9KTklEqtF2GxOzSlazJuHVXwnthQ2dumWFESS Iwmx3ymjeoG1xvF/1zDYQe4p1gJN7Txpu7+s90KAD+saD+YrJAG20Mczj623iIw83yJg aIdcVnozJ1Jg90Ruz82F93CPGiukeysztWbKBwk7Yj/kB2oWoParX3Aj8ZfuFAoeXMvw //cDCYznF3KmP707uQBKNx5FAnc7nOPdW3vcwl5oINcPyCTYO9SttG8AgCm8tj54Qmq0 4lc9on0C5Ct6pV25KFh5qjlskiJOJXWc9mAWL4xVrv5Ko8xmE/KKUHRpmUjOvqISk0Sj VtPQ== X-Gm-Message-State: AOUpUlH+LWfbufk1/tcD0L4vwcnlMIrmYVFGQXAKPhpGdXPuVY4Hud8M k5xcXVUZsvgnKx3Guj2drf2GSqdObaTUAQg5RBx5nSbXHas= X-Google-Smtp-Source: AA+uWPzeBwF0F2OieJ5o4tLxkRB2jAga8e6Ht3sIdJppUGZAT0PdC4DcZCbtNmgg8bdG3gXwGJjdyEl3kJavJqvXH0w= X-Received: by 2002:a2e:9f4d:: with SMTP id v13-v6mr31257298ljk.42.1534794497971; Mon, 20 Aug 2018 12:48:17 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 2002:a19:5943:0:0:0:0:0 with HTTP; Mon, 20 Aug 2018 12:48:17 -0700 (PDT) From: "Kurt Andersen (b)" Date: Mon, 20 Aug 2018 12:48:17 -0700 X-Google-Sender-Auth: 5gbCwDYoROyximZrEOSAQLPw2b4 Message-ID: To: IETF DMARC WG Cc: Seth Blank Content-Type: multipart/alternative; boundary="000000000000daf80e0573e33065" 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, 20 Aug 2018 19:48:22 -0000 --000000000000daf80e0573e33065 Content-Type: text/plain; charset="UTF-8" Seth and I discussed this topic today and I think that the central problem that is being debated has to do with *generating* the DMARC report content. Almost everyone agrees that a broken chain is broken and unredeemable - whether that breakage is structural or whether it is because of non-validating signatures. There are three possible levels of processing to be considered: 1. validating a particular individual message for delivery to the recipient - this is easy: a broken chain conveys no useful information for local policy determination 2. feeding ARC information into some larger reputation/ML system in order to provide (what I'll call) a third order policy influence - this one depends on whether the reputation system can make any useful conclusions on the basis of the broken chain. In some cases (where a signature fails to verify) it seems possible, but in many others it seems a bit doubtful 3. generating the DMARC report data pertinent to this individual message - this is where I think that the problem lies. There is a natural desire on the part of senders and report processors to want all the data that they can possibly get; however, it is easy to devise attack scenarios which heavily contaminate the reports if one were to take the content of the entire broken ARC chain into the report My contention to Seth is that in a multi-hop scenario, the *only* report with meaningful data will be the one from the handler who made the "fail" determination and any subsequent reports are untrustworthy. If we are not concerned with "downstream" handlers of a message with a broken ARC chain, then there is no point in attempting to seal the entirety of a failed ARC chain. Do the other folks on this thread agree that our main point of contention has to do with the ability to generate the DMARC report (or the data scoping thereof)? --Kurt --000000000000daf80e0573e33065 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Seth and I discussed this topic= today and I think that the central problem that is being debated has to do= with *generating* the DMARC report content. Almost everyone agrees that a = broken chain is broken and unredeemable - whether that breakage is structur= al or whether it is because of non-validating signatures. There are three p= ossible levels of processing to be considered:
  1. validating a particular individual message for delivery to the = recipient - this is easy: a broken chain conveys no useful information for = local policy determination
  2. feeding ARC information into some larger= reputation/ML system in order to provide (what I'll call) a third orde= r policy influence - this one depends on whether the reputation system can = make any useful conclusions on the basis of the broken chain. In some cases= (where a signature fails to verify) it seems possible, but in many others = it seems a bit doubtful
  3. generating the DMARC report data pertinent = to this individual message - this is where I think that the problem lies. T= here is a natural desire on the part of senders and report processors to wa= nt all the data that they can possibly get; however, it is easy to devise a= ttack scenarios which heavily contaminate the reports if one were to take t= he content of the entire broken ARC chain into the report
My = contention to Seth is that in a multi-hop scenario, the *only* report with = meaningful data will be the one from the handler who made the "fail&qu= ot; determination and any subsequent reports are untrustworthy.
<= br>
If we are not concerned with "downstream" handlers = of a message with a broken ARC chain, then there is no point in attempting = to seal the entirety of a failed ARC chain.

Do the= other folks on this thread agree that our main point of contention has to = do with the ability to generate the DMARC report (or the data scoping there= of)?

--Kurt
--000000000000daf80e0573e33065-- From nobody Mon Aug 20 12:53:08 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 B7087130DCE for ; Mon, 20 Aug 2018 12:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 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_10_20=0.093, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 DBPjntg_vP6I for ; Mon, 20 Aug 2018 12:53:05 -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 51361130DC6 for ; Mon, 20 Aug 2018 12:53:05 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id s12-v6so12542497ljj.0 for ; Mon, 20 Aug 2018 12:53:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:from:date:message-id:subject:to; bh=0mhs4ItLE7AE9VQYAncj/dZqVHT/sCAaKkXLL5gYN9A=; b=Qeve569VmrblH8Pkli+cr+HvT2aDYFq4zdXKz8e6wK0er954R6VmoprgNW50CN+4SS rbetSsQSf0zZbzAaENpq0Qj9T1CjI9DTNwghdyuZl+1d/gbx8zO/WJhRwu+d5yDxBebg w4dH+5nng1aYq8PN19/luaMkCbsMCI82pXY9U= 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=0mhs4ItLE7AE9VQYAncj/dZqVHT/sCAaKkXLL5gYN9A=; b=XXpGIbkh3DGfR43ThnA6xnxoW6jtIv0zSB/Jqa1q22HydVk9AU45Aj3sdoLbGUpNTe SXQHDQ2u3K5Rp0/tTnHU7tqMqaEZBHT2fMPlTWSsEpnO3WIIIUN3bhdi9qhQJMPFcM4E W2+yo6H1RAXoLwRabuRtAN/WREj3nhIgWgHdBeHLQebRNnCbVmuS9Oo6joJbi7/7WHLr cCLyDYETggoHlDoftTULfxdPlH7C9C3I6FLvK2f9sC0MclFrD1HeZeMP2hE1pfAiH7Dz 5pYnwwEh/OnW7fkxkbTIKcaonNx+TepTdXh6QHL3wSJpQ+KKZ173wclhO+zB7RMivM/+ PwlQ== X-Gm-Message-State: AOUpUlGaQr4O4H34/7H4ZEoRfW58WxxYgKdRMWG+Ugr0K7tLRcpvZ6Dw 2GuiTM0+zEXD5UMvNaZYcv+LyRj+PHBXtAhM8tY3do36ZHSCog== X-Google-Smtp-Source: AA+uWPxCSd5RgvJ8+yz6r2tNjGquPUoEEpiLb5+nwZF+iN6vKbpC7t2D1FH11j7/saqdMg/uil28X2Iccb6ahU3wphI= X-Received: by 2002:a2e:971a:: with SMTP id r26-v6mr1230745lji.30.1534794783496; Mon, 20 Aug 2018 12:53:03 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:5943:0:0:0:0:0 with HTTP; Mon, 20 Aug 2018 12:53:02 -0700 (PDT) From: Kurt Andersen Date: Mon, 20 Aug 2018 12:53:02 -0700 Message-ID: To: ARC Discussion , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000dfb0d50573e3419c" Archived-At: Subject: [dmarc-ietf] Reminder: next ARC interop testing on October 12 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, 20 Aug 2018 19:53:07 -0000 --000000000000dfb0d50573e3419c Content-Type: text/plain; charset="UTF-8" We are planning the next in-person ARC interop day on Friday, 2018-10-12 (the Friday following the Brooklyn M3AAWG meeting). For people attending in person, the meeting will be hosted at the Empire State Building. More details are still being finalized, but if you are coming to the M3AAWG meeting, please plan to stay for Friday's interop. You can express your interest (yes, no, maybe) at http://bit.ly/arc -09-interest (thank you to the 12 people who signed up earlier - no need to re-up). --Kurt --000000000000dfb0d50573e3419c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We are plannin= g the next in-person=C2=A0ARC=C2=A0<= /span>interop=C2=A0day on Friday, 2018-10-= 12 (the Friday following the Brooklyn M3AAWG meeting). For people attending= in person, the meeting will be hosted at the Empire State Building.=C2=A0<= /span>

More details are still be= ing finalized, but if you are coming to the M3AAWG meeting, please plan to = stay for Friday's=C2=A0interop.

You can express your= interest (yes, no, maybe) at=C2=A0http://bit.ly/arc-09-interest=C2=A0(thank you to the 12 pe= ople who signed up earlier - no need to re-up).

<= /div>
--Kurt

--000000000000dfb0d50573e3419c-- From nobody Mon Aug 20 19:18:51 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 87025130E48 for ; Mon, 20 Aug 2018 19:18:49 -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, 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 5jqtvAIABYCF for ; Mon, 20 Aug 2018 19:18:47 -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 A3E00130E1F for ; Mon, 20 Aug 2018 19:18:47 -0700 (PDT) Received: (qmail 70121 invoked from network); 21 Aug 2018 02:18:44 -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; 21 Aug 2018 02:18:44 -0000 Received: by ary.qy (Postfix, from userid 501) id 1DE842003B88CA; Mon, 20 Aug 2018 22:18:43 -0400 (EDT) Date: 20 Aug 2018 22:18:43 -0400 Message-Id: <20180821021844.1DE842003B88CA@ary.qy> 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] 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, 21 Aug 2018 02:18:50 -0000 In article you write: >My contention to Seth is that in a multi-hop scenario, the *only* report >with meaningful data will be the one from the handler who made the "fail" >determination and any subsequent reports are untrustworthy. Assuming that "subsequent" means earlier in the chain, I agree. >Do the other folks on this thread agree that our main point of contention >has to do with the ability to generate the DMARC report (or the data >scoping thereof)? Yes. I understand what to do with "here's a valid chain" and "it was broken when I got it", but not "here's a broken chain you may or may not be able to reconstruct." R's, John From nobody Mon Aug 20 22:40: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 823BF130FB7 for ; Mon, 20 Aug 2018 22:39:48 -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 1Dq3GzTzqvnK for ; Mon, 20 Aug 2018 22:39:43 -0700 (PDT) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 80F20130F7C for ; Mon, 20 Aug 2018 22:39:43 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id q13-v6so5186010lfc.2 for ; Mon, 20 Aug 2018 22:39: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=DGBfWHlBNFDS08PSMfBaIk/LtIJ+6lZqPBeeMDT0b4E=; b=WyZibcgwdmDwbx+bXRpw3oaOCL+7+yUqCK/XJiLASogRWFwo0dYx6R4DsBM5cVCH9U i18LBZhdr2azT8Qea8CeBxkietYF7FpuD8BJNZRSzoyogkI9Ejo4miDmBr3mq22pEJjj h1HiT7++1ksX2uFxLlnEgLbtCRUvBKDES2ug0= 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=DGBfWHlBNFDS08PSMfBaIk/LtIJ+6lZqPBeeMDT0b4E=; b=G+5Rha5LNcI12jGMUCnIFe7vGfOc9vE29GrKVvlhjSqEbm0pM6yCC9NnGH8fYyNUh/ oHZtvJ7rLcGFwiPHHGvz/RaMKXrLeO2vVroi5tWuN7ZmUQWiPToxlpoZkpVckRoJXabD 9eyuB7XApuRaA+Wf6jqVm0WZjaVREskQ1uyaS39TPmN3Aj/5/00ClE2TMVTJrgoFuvsI R03z1cfaeNhyyGbvbTteaNyYgPdMww1XCl0mmK7vzFnswQzNCIduh33Fm2wcbw3blCdy JLRkfeJWFhegATUPNIUmEuX0VY7nB+5D+4XPz1o6A1f6LalGvOxtR7psdvoHxb4J0yb1 WyNg== X-Gm-Message-State: AOUpUlENJt7xISAURVd2J91rqJsbO9Pyp1Y3rZjLDHlA7QnMcdZDecQK nxO7jHCi3MBhDB/mVR1yqjbT2RliaBn9dNGPDcpW56sRedA= X-Google-Smtp-Source: AA+uWPx5zQeTLfO3+cvTgeGI16ZHjLUg740oxgd4lJ0xQll/sbXzz25J6y3mJ6IWxwFqv/PqTlGMQhTsDMzjYbIa7rk= X-Received: by 2002:ac2:420c:: with SMTP id y12-v6mr30190006lfh.123.1534829981461; Mon, 20 Aug 2018 22:39:41 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 2002:a19:5943:0:0:0:0:0 with HTTP; Mon, 20 Aug 2018 22:39:40 -0700 (PDT) In-Reply-To: <20180821021844.1DE842003B88CA@ary.qy> References: <20180821021844.1DE842003B88CA@ary.qy> From: "Kurt Andersen (b)" Date: Mon, 20 Aug 2018 22:39:40 -0700 X-Google-Sender-Auth: PAmNAjMl8TRYltsYqnEcNpw-TNQ Message-ID: To: John Levine Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d6026f0573eb7351" 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, 21 Aug 2018 05:39:59 -0000 --000000000000d6026f0573eb7351 Content-Type: text/plain; charset="UTF-8" On Mon, Aug 20, 2018 at 7:18 PM, John Levine wrote: > In article gmail.com> you write: > >My contention to Seth is that in a multi-hop scenario, the *only* report > >with meaningful data will be the one from the handler who made the "fail" > >determination and any subsequent reports are untrustworthy. > > Assuming that "subsequent" means earlier in the chain, I agree. > No, by subsequent I mean intermediaries who handle the message after the point of initial "oh, this is broken" determination. So if I'm the 5th intermediary (let's assume that all are ARC participating for this discussion), and the chain on the message that I receive does not pass the validation checks (for any of the three possible reasons), then my report is meaningful to the sender but reports from 6, 7, 8, etc are not. --Kurt --000000000000d6026f0573eb7351 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Aug 20, 2018 at 7:18 PM, John Levine <johnl@taugh.com> wro= te:
In article <CABuGu1qZY2PtLJG+A-1aHDKiKY_1VHRPZ5aNJ1ans4pHnczrzQ@mail.= gmail.com> you write:
>My contention to Seth is that in a multi-hop scenario, the *only* repor= t
>with meaningful data will be the one from the handler who made the &quo= t;fail"
>determination and any subsequent reports are untrustworthy.

Assuming that "subsequent" means earlier in the chain, I a= gree.
=C2=A0
No, by subsequent I mean interm= ediaries who handle the message after the point of initial "oh, this i= s broken" determination. So if I'm the 5th intermediary (let's= assume that all are ARC participating for this discussion), and the chain = on the message that I receive does not pass the validation checks (for any = of the three possible reasons), then my report is meaningful to the sender = but reports from 6, 7, 8, etc are not.

--Kurt

--000000000000d6026f0573eb7351-- From nobody Tue Aug 21 07:46:08 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 20F51130EF6 for ; Tue, 21 Aug 2018 07:46:06 -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 V1iQ0gCCtefE for ; Tue, 21 Aug 2018 07:46: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 3394A128B14 for ; Tue, 21 Aug 2018 07:46:03 -0700 (PDT) Received: (qmail 33743 invoked from network); 21 Aug 2018 14:46:02 -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; 21 Aug 2018 14:46:02 -0000 Date: 21 Aug 2018 10:46:01 -0400 Message-ID: From: "John R Levine" To: "Kurt Andersen (b)" Cc: "dmarc@ietf.org" In-Reply-To: References: <20180821021844.1DE842003B88CA@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, 21 Aug 2018 14:46:06 -0000 On Mon, 20 Aug 2018, Kurt Andersen (b) wrote: > No, by subsequent I mean intermediaries who handle the message after the > point of initial "oh, this is broken" determination. So if I'm the 5th > intermediary (let's assume that all are ARC participating for this > discussion), and the chain on the message that I receive does not pass the > validation checks (for any of the three possible reasons), then my report > is meaningful to the sender but reports from 6, 7, 8, etc are not. Ah, that. You're right. One the chain is broken, we have no idea where the message came from and it's just another bit of spam bouncing around the net. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed Aug 22 11:02:42 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 C0878130E40; Wed, 22 Aug 2018 11:02:34 -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.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dmarc@ietf.org Message-ID: <153496095473.20964.18389016884787513989@ietfa.amsl.com> Date: Wed, 22 Aug 2018 11:02:34 -0700 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-rfc7601bis-03.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: Wed, 22 Aug 2018 18:02:35 -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 : Message Header Field for Indicating Message Authentication Status Author : Murray S. Kucherawy Filename : draft-ietf-dmarc-rfc7601bis-03.txt Pages : 48 Date : 2018-08-22 Abstract: This document specifies a message header field called Authentication- Results for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmarc-rfc7601bis-03 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-rfc7601bis-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-rfc7601bis-03 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 Wed Aug 22 16:40:04 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 07898130DFE; Wed, 22 Aug 2018 16:40:03 -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 4VgQsQFMA10a; Wed, 22 Aug 2018 16:40:01 -0700 (PDT) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 C2DE3130DF7; Wed, 22 Aug 2018 16:40:00 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id j8-v6so2683632lfb.4; Wed, 22 Aug 2018 16:40:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Oqw2k5/ii+/DWEuNHaspnqxSM2IOX9C7dLPdrnE5skQ=; b=e6hFR2RR2HUYJ3mutDIH7UY49aaB2l40tw2egHh2EvOYepEuFuwBD3CFs2BOOpYKfU vXt6wTzqOL/TGwFHrg0P0qUcDMcWOYwKGzfiPC6P4xwUJk04cZootJfNU+K23m/gimAg RvJn/R+hD+bBpLwlu4On2quuVrO8JrVpckcr2K/QTKoWAcMQQY4VwDBqCHBOYhSR6kKq P7TJlptKjJI4snOKuPXDXfwjCd4F1FmqJqckRisWYVNc4r5uGk86sC8LQRz0PcUybBF2 BExF2ZDGCT9uASIS+3nN0urWMR6mDIdoqDDaJktzxYGW5GLlBar0ESC7Pq9hR466JoxG CONQ== 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=Oqw2k5/ii+/DWEuNHaspnqxSM2IOX9C7dLPdrnE5skQ=; b=gGblRG/UX4Ahw9DWWjeJKjgDwzQ7drs4BQe3lnCB/tk3NjGlWdTq1Jk2hsUl2dj+6w AdpvHlCHsGi3HJLi2KTGYSx6Gkx3hkiLsGraftQ8NlbgFet57KxT4ypDNYmiy77BkJ3I NmGULfsKSPOl5P5/cmI5aqgXRH6xbsaLlWdV/hHCJbt+wKfhQTNM+9MQsw/8DkuL+9dL itutBaqskdciexVS1fu8jLnVnojNvf9SDhPvyMLGBvne1MzF+jsdStmeJyMCIGc+9FXp zgE3c9BLnaRdJJr6Lsm8HUbdQQ7aJ4l4rtsJdBoBNWCrqbe+iu4Q852L9bvao2iGL/O+ HLOA== X-Gm-Message-State: AOUpUlFgc4DhdqtHb3lDtNL7IifQ5r0Squ4nCe85HhKiRABojEw/i5jz 5ePbooIy6W6CDHrSAbyWkOv/Mt3/oDVjTKLgASl6Zg== X-Google-Smtp-Source: AA+uWPyjnNne+AQDMMTrydG3oU6hPPL/FlECoyp6k+hXSd/+fTc0ZHZm8xvPDlQeao4LefWF1ia+2++VKestWrFDm4g= X-Received: by 2002:a19:e307:: with SMTP id a7-v6mr35615749lfh.125.1534981198635; Wed, 22 Aug 2018 16:39:58 -0700 (PDT) MIME-Version: 1.0 References: <153496095473.20964.18389016884787513989@ietfa.amsl.com> In-Reply-To: <153496095473.20964.18389016884787513989@ietfa.amsl.com> From: "Murray S. Kucherawy" Date: Wed, 22 Aug 2018 23:39:45 +0000 Message-ID: To: internet-drafts@ietf.org, IETF DMARC WG Cc: i-d-announce@ietf.org Content-Type: multipart/alternative; boundary="00000000000014e6cc05740ea9c4" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-rfc7601bis-03.txt 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, 22 Aug 2018 23:40:03 -0000 --00000000000014e6cc05740ea9c4 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 22, 2018 at 6:03 PM wrote: > > 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 : Message Header Field for Indicating Message > Authentication Status > Author : Murray S. Kucherawy > Filename : draft-ietf-dmarc-rfc7601bis-03.txt > Pages : 48 > Date : 2018-08-22 > > Abstract: > This document specifies a message header field called Authentication- > Results for use with electronic mail messages to indicate the results > of message authentication efforts. Any receiver-side software, such > as mail filters or Mail User Agents (MUAs), can use this header field > to relay that information in a convenient and meaningful way to users > or to make sorting and filtering decisions. > This is the WGLC result. Tim sent me privately a large number of edits which I cherry picked for things that were broken or obviously wrong and punted on stuff that seemed less than that. Tim, feel free to argue harder for anything I passed over for inclusion. Apart from that, I think this is good to go; everything else that appeared to meet consensus was included. -MSK --00000000000014e6cc05740ea9c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Aug 22, 2018 at 6:03 PM <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Domain-based Message Authentication, Repor= ting & Conformance WG of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Message Header Field for Indicating Message Authentication Status
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Murr= ay S. Kucherawy
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-dmarc-rfc7601bis-03.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 48
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-08-22

Abstract:
=C2=A0 =C2=A0This document specifies a message header field called Authenti= cation-
=C2=A0 =C2=A0Results for use with electronic mail messages to indicate the = results
=C2=A0 =C2=A0of message authentication efforts.=C2=A0 Any receiver-side sof= tware, such
=C2=A0 =C2=A0as mail filters or Mail User Agents (MUAs), can use this heade= r field
=C2=A0 =C2=A0to relay that information in a convenient and meaningful way t= o users
=C2=A0 =C2=A0or to make sorting and filtering decisions.

This is the WGLC result.=C2=A0 Tim sent me privately a la= rge number of edits which I cherry picked for things that were broken or ob= viously wrong and punted on stuff that seemed less than that.=C2=A0 Tim, fe= el free to argue harder for anything I passed over for inclusion.

Apart from that, I think this is good to go; everything els= e that appeared to meet consensus was included.

-MSK
--00000000000014e6cc05740ea9c4-- From nobody Sat Aug 25 00:24: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 6C71812F18C for ; Sat, 25 Aug 2018 00:24:34 -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=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 LvRGsoP99l_S for ; Sat, 25 Aug 2018 00:24:32 -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 8B544130DD6 for ; Sat, 25 Aug 2018 00:24:32 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id t68-v6so7902828oie.12 for ; Sat, 25 Aug 2018 00:24:32 -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=4UO9JrCG5pkaKHJnyS8DvTM0689QSgN4ubWtWVgHxTA=; b=I2PJlkyHr6PhYSs96b88To07WIapN+WcLNeIf0eY1xIx2XWwZhT8bP5Cf8TPdkXsTc 5Ii2OPc4x1kKVKzSGXZg03tLzpRzX0ySr6CYEBe0EnGfPtCN65fB769XaiTMV2PWujDW 1j0q4UoF7b8Yo3158+3GIhy5q20m/f4TGBp04= 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=4UO9JrCG5pkaKHJnyS8DvTM0689QSgN4ubWtWVgHxTA=; b=CDKqRkDQ7AOiU2nZ1jg8Z34QBZo58sUjgWwH5F07EYWy0r7mxZPkr+XoPcorLpjU1x mYRljYVQMKX4iJfGlltNhh5L84RwCWyTcNkWXAO0AShksngduEKVqSD4JEsPZ+Q49hV8 ql/XlMNVcDjpBuZTKoVuiqsBKlxfKtX40BThB+tFdgMtiKnwQ4McJQLEDALx7yEJ7XmH nJzxV2PKy7hK+DBK1SUfNLyujudhP2vAx4xbVNQx2tWya2llG7ca08jZrCDCEapnV8i5 ttkgYMVXGOCaZ5jjsTSt/lT3CX0El23ahS8+PaIBsRF0k7tcwNnZruAtrU4mV6k1Fu4i 8nOA== X-Gm-Message-State: APzg51DxK0eR1baB+I3seYSMgqpCqCngUC6c3jL4A6KF0Q92UCxt4up8 b9QzPkvOJGE4xhiKNDDhcHHmTq0pbIg= X-Google-Smtp-Source: ANB0VdYkeEKoNyi4fsvKPD8rwThJaA0S5RtiguNOeM7BqqM/iHi2cr/mSOgfWNGrRmsm4aQ/wsAiWg== X-Received: by 2002:aca:ef02:: with SMTP id n2-v6mr4073562oih.291.1535181871332; Sat, 25 Aug 2018 00:24:31 -0700 (PDT) Received: from [100.170.247.156] ([172.56.6.128]) by smtp.gmail.com with ESMTPSA id l195-v6sm6487722oib.17.2018.08.25.00.24.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Aug 2018 00:24:30 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Tim Draegen X-Mailer: iPhone Mail (15G77) In-Reply-To: Date: Sat, 25 Aug 2018 10:24:26 +0300 Cc: IETF DMARC WG Content-Transfer-Encoding: quoted-printable Message-Id: <1A563C02-A7CF-4745-BADD-8F52DBCF7EE7@eudaemon.net> References: <153496095473.20964.18389016884787513989@ietfa.amsl.com> To: "Murray S. Kucherawy" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-rfc7601bis-03.txt 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, 25 Aug 2018 07:24:34 -0000 > On Aug 23, 2018, at 2:39 AM, Murray S. Kucherawy wro= te: >=20 > This is the WGLC result. Tim sent me privately a large number of edits wh= ich I cherry picked for things that were broken or obviously wrong and punte= d on stuff that seemed less than that. Tim, feel free to argue harder for a= nything I passed over for inclusion. >=20 > Apart from that, I think this is good to go; everything else that appeared= to meet consensus was included. Righto! Thank you Murray for the attention to detail. I=E2=80=99ll will not be arguing for additional changes. Onward with shepher= ding.. =3D- Tim