From nobody Thu Mar 2 17:11:24 2017 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 70EAD129655 for ; Thu, 2 Mar 2017 17:11:23 -0800 (PST) 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_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.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 j87IUhpaCVut for ; Thu, 2 Mar 2017 17:11:22 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C93D129450 for ; Thu, 2 Mar 2017 17:11:21 -0800 (PST) Received: from kitterma-e6430.localnet (unknown [166.170.29.104]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 7E369C4017C for ; Thu, 2 Mar 2017 19:11:20 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1488503480; bh=3d5JdZmDO+mo6xJaoFEodfJZiEiECTlU0T56BOtOF6Y=; h=From:To:Subject:Date:In-Reply-To:References:From; b=qKInHlxTpGpsVGn8kXYIScq1ZGjiW85wLGD2o8L1MuzY5sadHqUB6Zx/VWZ9qkDpN Vh0kOaZA4PlDUAs9YmgE9RLAG8mATGPoKaTXoheqkJ7S5ZIi5kEQQCW8hlpD5YJBnz AXr3X09g2GqsE9LTrcBtdhkKmMmC11afWD3EreRw= From: Scott Kitterman To: dmarc@ietf.org Date: Thu, 02 Mar 2017 20:11:19 -0500 Message-ID: <2779809.iH6HErIZAf@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-108-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <148287719018.14245.10945455255001709040.idtracker@ietfa.amsl.com> References: <148287719018.14245.10945455255001709040.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-usage-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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 Mar 2017 01:11:23 -0000 On Tuesday, December 27, 2016 02:19:50 PM internet-drafts@ietf.org 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 of the IETF. > > Title : Recommended Usage of the Authenticated Received > Chain (ARC) Authors : Steven Jones > John Rae-Grant > Trent Adams > Kurt Andersen > Filename : draft-ietf-dmarc-arc-usage-01.txt > Pages : 15 > Date : 2016-12-27 ... Another update for you: Currently there is section 9.3. dkimpy patch. This should be replaced with the following since it's no longer a separate patch. 9.3. dkimpy Organization: dkimpy developers Description: Python DKIM package Status of Operation: Production Coverage: The internal test suite is incomplete, but the command line developmental version of validator was demonstrated to interoperate with the Google and AOL implementations during the interop on 2016-06-17 and the released version passes the tests in https://github.com/ValiMail/arc_test_suite with both python and python3. Licensing: Open/Other (same as dkimpy package) Contact Info: https://launchpad.net/dkimpy It would be nice to see a revision with this and the updates for key length and signing algorithm published. Scott K From nobody Tue Mar 7 15:37:38 2017 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 0C2E41295B7 for ; Tue, 7 Mar 2017 15:37:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.018 X-Spam-Level: X-Spam-Status: No, score=-1.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RDNS_DYNAMIC=0.982, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=regumi.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 j_4FMBJq0L0e for ; Tue, 7 Mar 2017 15:37:36 -0800 (PST) Received: from mx01.regumi.net (153-149-28-102.compute.jp-e1.cloudn-service.com [153.149.28.102]) by ietfa.amsl.com (Postfix) with ESMTP id CDB18127601 for ; Tue, 7 Mar 2017 15:37:35 -0800 (PST) Received: from zcs03.regumi.org (v-182-163-50-23.ub-freebit.net [182.163.50.23]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx01.regumi.net (Postfix) with ESMTPS id EF8A42322 for ; Wed, 8 Mar 2017 08:37:31 +0900 (JST) DKIM-Filter: OpenDKIM Filter v2.10.3 mx01.regumi.net EF8A42322 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=regumi.net; s=s161204a; t=1488929852; bh=t9YEtKkiepvg4SS2iKozbgJnj79i/Ns4tOCO3LEGhg4=; h=Date:From:To:In-Reply-To:References:Subject:From; b=R9pT0A5jVGqNajgspVMZ/oc19sn1kLNcV3ovLWsFfs/HabuqvzBk5+kJMX4hYaVt7 PBEXyxmkipsfghyP8SO1sqkFzZJLHhA7LmAeUIEKoD9px11kzSah2zG3Sm2aI2u5Uv EMlckVqjfBHL2hIFT0ZA7deqeEjMoOW1+BE5n+4E= Received: from localhost (localhost.localdomain [127.0.0.1]) by zcs03.regumi.org (Postfix) with ESMTP id 1DF0F121E0019 for ; Wed, 8 Mar 2017 08:37:31 +0900 (JST) X-Virus-Scanned: amavisd-new at regumi.net Received: from zcs03.regumi.org ([127.0.0.1]) by localhost (zcs03.regumi.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DH91JMZDrL_x for ; Wed, 8 Mar 2017 08:37:31 +0900 (JST) Received: from zcs03.regumi.org (zcs03.regumi.org [182.163.50.23]) by zcs03.regumi.org (Postfix) with ESMTP id 87E26121E0018 for ; Wed, 8 Mar 2017 08:37:29 +0900 (JST) Date: Tue, 7 Mar 2017 23:37:29 +0000 (GMT) From: Takehito Akagiri To: dmarc Message-ID: <1484314381.1911.1488929849396.JavaMail.zimbra@regumi.net> In-Reply-To: <397429547.874.1488161406775.JavaMail.zimbra@regumi.net> References: <147444383872.26699.16623751845390083865.idtracker@ietfa.amsl.com> <397429547.874.1488161406775.JavaMail.zimbra@regumi.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [60.41.228.55] X-Mailer: Zimbra 8.6.0_GA_1153 (ZimbraWebClient - GC56 (Mac)/8.6.0_GA_1153) Thread-Topic: I-D Action: draft-akagiri-dmarc-virtual-verification-01.txt Thread-Index: SE6J5LOKldZ9ps3wgI35QXDYt96NbukX/0Tm Archived-At: Subject: Re: [dmarc-ietf] Fwd: I-D Action: draft-akagiri-dmarc-virtual-verification-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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 Mar 2017 23:37:37 -0000 Daisuke,=20 Many thanks. Choose log from one MTA for 1 day, that should be enough for this kind of s= tats at first. Also I focused only on "strict" pattern. After that, simply do. In my case, I made a csv file from logs =20 - queueID, spf result, EnvFrom domain, DKIM result, d=3D, RFC5322.From doma= in Then get DMARC from TXT RR for RFC5322.From if the message was "align". Best, --Takehito > Hi Takehito, > > Thank you for your information. This is good! > I would like to research my mail servers, too. >=20 > Please tell me how to make data more easily. > > Daisuke. > >> Regarding draft-akagiri-dmarc-virtual-verification-01.txt, I got statist= ics to show effect of "Virtual DAMRC" in corporation with some Japanese ISP= s. >> >>I prepared very simple page for it. Please find it on the URL as bellow. >>https://www.vdmarc.dmarc.jp/?p=3D122 >> >>Any comments will be appreciated. >> >>Best regards, >>--Takehito Akagiri ----- =E5=85=83=E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8 ----- =E5=B7=AE=E5=87=BA=E4=BA=BA: "=E5=A3=AE=E4=BA=BA =E8=B5=A4=E6=A1=90" =E5=AE=9B=E5=85=88: "dmarc" =E9=80=81=E4=BF=A1=E6=B8=88=E3=81=BF: 2017=E5=B9=B42=E6=9C=8827=E6=97=A5, = =E6=9C=88=E6=9B=9C=E6=97=A5 =E5=8D=88=E5=89=8D 11:10:06 =E4=BB=B6=E5=90=8D: Re: [dmarc-ietf] Fwd: I-D Action: draft-akagiri-dmarc-v= irtual-verification-01.txt Regarding draft-akagiri-dmarc-virtual-verification-01.txt, I got statistics= to show effect of "Virtual DAMRC" in corporation with some Japanese ISPs. I prepared very simple page for it. Please find it on the URL as bellow. https://www.vdmarc.dmarc.jp/?p=3D122 Any comments will be appreciated. Best regards, --Takehito Akagiri ----- =E5=85=83=E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8 ----- =E5=B7=AE=E5=87=BA=E4=BA=BA: "Kouji Okada" =E5=AE=9B=E5=85=88: "dmarc" Cc: "Kouji Okada" =E9=80=81=E4=BF=A1=E6=B8=88=E3=81=BF: 2016=E5=B9=B49=E6=9C=8821=E6=97=A5, = =E6=B0=B4=E6=9B=9C=E6=97=A5 =E5=8D=88=E5=BE=8C 5:10:55 =E4=BB=B6=E5=90=8D: [dmarc-ietf] Fwd: I-D Action:=09draft-akagiri-dmarc-vir= tual-verification-01.txt We have submitted new version of draft-akagiri-dmarc-virtual-verification The diffs from 00 are listed below. * Removed Roadmap section * Added focus of document to Introduction and Problem Statement * Added Use cases section Any comments will be appreciated. Best regards, Kouji Okada > =E8=BB=A2=E9=80=81=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=83=E3=82=BB= =E3=83=BC=E3=82=B8=EF=BC=9A >=20 > =E5=B7=AE=E5=87=BA=E4=BA=BA: internet-drafts@ietf.org > =E4=BB=B6=E5=90=8D: I-D Action: draft-akagiri-dmarc-virtual-verification-= 01.txt > =E6=97=A5=E4=BB=98: 2016=E5=B9=B49=E6=9C=8821=E6=97=A5 16:43:58 JST > =E5=AE=9B=E5=85=88: > =E8=BF=94=E4=BF=A1=E5=85=88: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 >=20 > Title : DMARC verification without record definitions > Authors : Genki Yasutaka > Takehito Akagiri > Masaki Kase > Kouji Okada > Kaoru Maeda > =09Filename : draft-akagiri-dmarc-virtual-verification-01.txt > =09Pages : 9 > =09Date : 2016-09-21 >=20 > Abstract: > While DMARC is a powerful architecture to protect email users from > malicious email activities, its deployment is still a work in > progress. To encourage further adoption of DMARC, in this draft we > propose an incremental deployment procedure. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-akagiri-dmarc-virtual-verification= / >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-akagiri-dmarc-virtual-verification-01 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-akagiri-dmarc-virtual-verificat= ion-01 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ 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 From nobody Tue Mar 7 17:07:23 2017 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 7A06D1294AE for ; Tue, 7 Mar 2017 17:07:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_MIMEOLE=1.899, RP_MATCHES_RCVD=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nifty.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 7wqhC5-mxfH3 for ; Tue, 7 Mar 2017 17:07:20 -0800 (PST) Received: from conwmuserg-03.nifty.com (conwmuserg-03.nifty.com [210.131.2.102]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB461129470 for ; Tue, 7 Mar 2017 17:07:19 -0800 (PST) Received: from aps-02 ([10.126.10.35])by conwmuserg-03.nifty.com with ESMTP id v281719U015166; Wed, 8 Mar 2017 10:07:01 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conwmuserg-03.nifty.com v281719U015166 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com; s=dec2015msa; t=1488935221; bh=ejUUmNbq2+y1+ICHGt5D/e+iAy4y6UppOCgjLJ76rko=; h=Date:From:To:Subject:Cc:In-Reply-To:References:From; b=00HutmSc2eIWAdac8gyIydjr+S/xDcXqekhwyYJmn6WljHoPCwybxtVwqNNgw7yvf wlMxMSsenE+qGayZT/Ok1Wqs0erE4L6FG8qBMK9x27lQ/ixSgC+kjNZxw4oe+m0yuA SvMfgQXyW3Q8uV/tVtP7dBkgwKjJcRtjnO475LfGv/Q6wKohllrmEmTNvHI/VtO7h2 CW+UpdgB8gVxfaFeQsw6K6VchS3BRu8PxdtYdtueWte+iQi/QI6c8leuy8XroCMndT zYQ4UCqJyH/M7E3txstJyNXsFPpcU1vWEMt2y39JfbtRlD78rHLgVl72bXsu2RclDe M36YQZN+mIvMA== X-Nifty-SrcIP: [10.126.10.35] Message-ID: <1779738375.94601488935221002.softest@nifty.com> Date: Wed, 8 Mar 2017 10:07:01 +0900 (JST) From: =?ISO-2022-JP?B?GyRCMkNAJUA1PHkbKEI=?= To: Takehito Akagiri In-Reply-To: <1484314381.1911.1488929849396.JavaMail.zimbra@regumi.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Priority: normal X-Mailer: @nifty Webmail References: <1484314381.1911.1488929849396.JavaMail.zimbra@regumi.net> <147444383872.26699.16623751845390083865.idtracker@ietfa.amsl.com> <397429547.874.1488161406775.JavaMail.zimbra@regumi.net> Archived-At: Cc: dmarc Subject: Re: [dmarc-ietf] Fwd: I-D Action: draft-akagiri-dmarc-virtual-verification-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 08 Mar 2017 01:07:22 -0000 Hi Daisuke, Takehito, Perhaps, we would be able to calculate the rate: 1. Survey the emails passed ADSP. 2. Survey the emails passed SPF. And exclude the emails passed ADSP. And exclude the emails have no same domain about RFC5321.From and RFC5322.From. The sum of the result 1. and 2. is the rate we'd expect. Best regards, ----- Original Message ----- >Date: Tue, 7 Mar 2017 23:37:29 +0000 (GMT) >From: Takehito Akagiri >To: dmarc >Subject: Re: [dmarc-ietf] Fwd: I-D Action: > draft-akagiri-dmarc-virtual-verification-01.txt > > >Daisuke, > >Many thanks. > >Choose log from one MTA for 1 day, that should be enough for this kind of sta ts at first. >Also I focused only on "strict" pattern. >After that, simply do. > >In my case, I made a csv file from logs >- queueID, spf result, EnvFrom domain, DKIM result, d=, RFC5322.From domain >Then get DMARC from TXT RR for RFC5322.From if the message was "align". > >Best, >--Takehito > > > > >> Hi Takehito, >> >> Thank you for your information. This is good! >> I would like to research my mail servers, too. >> >> Please tell me how to make data more easily. >> >> Daisuke. >> >>> Regarding draft-akagiri-dmarc-virtual-verification-01.txt, I got statistic s to show effect of "Virtual DAMRC" in corporation with some Japanese ISPs. >>> >>>I prepared very simple page for it. Please find it on the URL as bellow. >>>https://www.vdmarc.dmarc.jp/?p=122 >>> >>>Any comments will be appreciated. >>> >>>Best regards, >>>--Takehito Akagiri > > >----- $B85$N%a%C%;!<%8(J ----- >$B:9=P?M(J: "$BAT?M(J $B@V6M(J" >$B08@h(J: "dmarc" >$BAw?.:Q$_(J: 2017$BG/(J2$B7n(J27$BF|(J, $B7nMKF|(J $B8aA0(J 11:10:06 >$B7oL>(J: Re: [dmarc-ietf] Fwd: I-D Action: draft-akagiri-dmarc-virtual-verificat ion-01.txt > >Regarding draft-akagiri-dmarc-virtual-verification-01.txt, I got statistics t o show effect of "Virtual DAMRC" in corporation with some Japanese ISPs. > >I prepared very simple page for it. Please find it on the URL as bellow. >https://www.vdmarc.dmarc.jp/?p=122 > >Any comments will be appreciated. > >Best regards, >--Takehito Akagiri > > > >----- $B85$N%a%C%;!<%8(J ----- >$B:9=P?M(J: "Kouji Okada" >$B08@h(J: "dmarc" >Cc: "Kouji Okada" >$BAw?.:Q$_(J: 2016$BG/(J9$B7n(J21$BF|(J, $B?eMKF|(J $B8a8e(J 5:10:55 >$B7oL>(J: [dmarc-ietf] Fwd: I-D Action: draft-akagiri-dmarc-virtual-verification- 01.txt > >We have submitted new version of draft-akagiri-dmarc-virtual-verification > >The diffs from 00 are listed below. > >* Removed Roadmap section >* Added focus of document to Introduction and Problem Statement >* Added Use cases section > >Any comments will be appreciated. > >Best regards, >Kouji Okada > >> $BE>Aw$5$l$?%a%C%;!<%8!'(J >> >> $B:9=P?M(J: internet-drafts@ietf.org >> $B7oL>(J: I-D Action: draft-akagiri-dmarc-virtual-verification-01.txt >> $BF|IU(J: 2016$BG/(J9$B7n(J21$BF|(J 16:43:58 JST >> $B08@h(J: >> $BJV?.@h(J: internet-drafts@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts director ies. >> >> >> Title : DMARC verification without record definitions >> Authors : Genki Yasutaka >> Takehito Akagiri >> Masaki Kase >> Kouji Okada >> Kaoru Maeda >> Filename : draft-akagiri-dmarc-virtual-verification-01.txt >> Pages : 9 >> Date : 2016-09-21 >> >> Abstract: >> While DMARC is a powerful architecture to protect email users from >> malicious email activities, its deployment is still a work in >> progress. To encourage further adoption of DMARC, in this draft we >> propose an incremental deployment procedure. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-akagiri-dmarc-virtual-verification/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-akagiri-dmarc-virtual-verification-01 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-akagiri-dmarc-virtual-verification- 01 >> >> >> Please note that it may take a couple of minutes from the time of submissio n >> 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/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >_______________________________________________ >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 > >_______________________________________________ >dmarc mailing list >dmarc@ietf.org >https://www.ietf.org/mailman/listinfo/dmarc ================================== $B2C@%@5 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 4AEBE129C66 for ; Wed, 15 Mar 2017 16:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=linkedin.com header.b=BYS+Dnzu; dkim=pass (1024-bit key) header.d=linkedin.com header.b=B1xkTYp9 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 WYeJrpmc_B4I for ; Wed, 15 Mar 2017 16:18:27 -0700 (PDT) Received: from mail522.linkedin.com (mail522.linkedin.com [108.174.6.122]) (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 2F5C0129C70 for ; Wed, 15 Mar 2017 16:18:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; s=proddkim1024; t=1489619895; bh=YEwPz2zJixpFpF7BfmmyfAyeU3grRwYFTdvOLOlbfxo=; h=MIME-Version:From:Date:Subject:To:Content-Type; b=BYS+DnzudB1gcrK4J9qEbcOEl6GjQVRnAXKIq2JmF9odumLCtQs6sohS3PIyiw+fe 75BKkI4Z4vq+ijZy+cdskBSVOlmMe3bH/+XFui+JZ6UrI2X6qSkmhUKONp+zxExjCr /08htoDqtJTfkyCttAcTIsCno9gM/l/uK7cS3EvE= Authentication-Results: mail522.prod.linkedin.com x-tls.subject="/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com"; auth=pass (cipher=ECDHE-RSA-AES128-GCM-SHA256) Authentication-Results: mail522.prod.linkedin.com; iprev=pass policy.iprev="2607:f8b0:400e:c00::245"; spf=softfail smtp.mailfrom="kandersen@linkedin.com" smtp.helo="mail-pf0-x245.google.com"; dkim=pass header.d=linkedin.com; tls=pass (verified) key.ciphersuite="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256" key.length="128" tls.v="tlsv1.2" cert.client="C=US,ST=California,L=Mountain View,O=Google Inc,CN=smtp.gmail.com" cert.clientissuer="C=US,O=Google Inc,CN=Google Internet Authority G2" Received: from [2607:f8b0:400e:c00::245] ([2607:f8b0:400e:c00::245.33721] helo=mail-pf0-x245.google.com) by mail522.prod.linkedin.com (envelope-from ) (ecelerity 3.6.21.53563 r(Core:3.6.21.0)) with ESMTPS (cipher=ECDHE-RSA-AES128-GCM-SHA256 subject="/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com") id 76/A6-11995-5BBC9C85; Wed, 15 Mar 2017 23:18:13 +0000 Received: by mail-pf0-x245.google.com with SMTP id c23so53974101pfj.0 for ; Wed, 15 Mar 2017 16:18:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=YEwPz2zJixpFpF7BfmmyfAyeU3grRwYFTdvOLOlbfxo=; b=B1xkTYp9L5Vl14ncy0m2dMVWc5uuOFoz40sPGNkSAjk9ufxudfRThy+Ea7drVAOubj RbbkAHCBFkgVmm7fPYADylFhmTfCPuAKz6z1wrovpOQ3mjwIBy/Jew2jDHyUWo8GOfHH PpI38iCfmK42jXZOeembtdYu695ZAjuzapELo= 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=YEwPz2zJixpFpF7BfmmyfAyeU3grRwYFTdvOLOlbfxo=; b=lvHBi5F5zeFj1b8PJSWF9vZarchwQqMdnPArhQhvk0pY875rgdV/pBe4yVc0A6uwu9 Lftvp9bgCRvGH+SJMu/E37dRlUEspV73fNUTdkr8eVjZ/HuuFX57iD5Md3xG3K2aP55R mUvZBNuTiA9zQZaNUCvYDFUPANOSWWqkOijdmM5Pbll5c7JSshs8/8SjpZYOMMJeBisM Q7xtue8SDvSDDXoCKHZvYWwERioiYE1yjggw7UWrnRlv/MATeAqKvfAfGJNN6fppd0tE wC7KWK1ks/IbveZkjzHPnnszdQ3weOHA/pZhAqAIwdJxF3LTwD+axMQn4agOYlRn3Dot dSSQ== X-Gm-Message-State: AFeK/H36I2yNUmZbA64CuNhnDa7DdbOypoKBgpMxwa/3P/1Ks3uHG2y3HHRVg/rVjdmotgQ9BzrjSreug5aZEDTS7FfxonA1Bo7v4V7v2yvXCWb6rrX25MPRbbUjZQZ3ZBwPkO7nkF0yPRFYY5TFhrSop1HL X-Received: by 10.84.131.130 with SMTP id d2mr8001114pld.103.1489619892510; Wed, 15 Mar 2017 16:18:12 -0700 (PDT) X-Received: by 10.84.131.130 with SMTP id d2mr8001072pld.103.1489619892025; Wed, 15 Mar 2017 16:18:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.149.15 with HTTP; Wed, 15 Mar 2017 16:18:11 -0700 (PDT) From: Kurt Andersen Date: Wed, 15 Mar 2017 16:18:11 -0700 Message-ID: To: dmarc@ietf.org, "Murray S. Kucherawy" , seth@valimail.com, Steve Jones , Barry Leiba Content-Type: multipart/alternative; boundary=94eb2c18745683e656054acd287d Archived-At: Subject: [dmarc-ietf] "Missed it by *that* much". . . X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2017 23:18:29 -0000 --94eb2c18745683e656054acd287d Content-Type: text/plain; charset=UTF-8 I discovered today as I attempted to submit the ARC protocol update that I've been working on, that the submission system closed about 40 hours earlier - sigh. Since I'm headed to Ecuador for a three week vacation with unknown and/or unlikely Internet access, I have created a git repo and posted the source (kramdown) and rendered xml, txt, html versions for both the protocol and usage documents at https://github.com/kurta/arc-docs Once the submissions system opens and I have internet access, I will get the official submission completed; but until then, you can see the updates at: http://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-dmarc-arc-protocol-01.txt&url2=https://raw.githubusercontent.com/kurta/arc-docs/master/dmarc-arc-protocol-02.txt (obviously the date will have to change further) Here are the key changes I added (based on input from the list and discussion during the interop in February): 1) Removed the attempts to repair any problems in the ARC chain beyond simple ordering problems, added cv=invalid 2) Added section 5.4 to discuss phases for transitioning signature algorithms 3) Updated length of chain? (section 5.1.1.1.1) at least 10, may be up to 50; may mark invalid above that Also as discussed in the interop, I did not add any additional requirements in ARC regarding key lengths. I will be submitting an update to the DKIM spec itself to fork both the key length and signing algorithms into a registry which can then be managed without requiring further spec updates. --Kurt --94eb2c18745683e656054acd287d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I discovered today as I attempted to submit the ARC protoc= ol update that I've been working on, that the submission system closed = about 40 hours earlier - sigh.

Since I'm headed to E= cuador for a three week vacation with unknown and/or unlikely Internet acce= ss, I have created a git repo and posted the source (kramdown) and rendered= xml, txt, html versions for both the protocol and usage documents at=C2=A0= https://github.com/kurta/arc-= docs

Once the submissions system opens and I h= ave internet access, I will get the official submission completed; but unti= l then, you can see the updates at:


(obviously the date will have to= change further)

Here are the key changes I added = (based on input from the list and discussion during the interop in February= ):

1) Removed the attempts to repair any problems in the ARC chain beyond= simple ordering problems, added cv=3Dinvalid=C2=A0
2) Added sect= ion 5.4 to discuss phases for transitioning signature algorithms
= 3) Updated length of chain? (section 5.1.1.1.1) at least 10, may be up to 5= 0; may mark invalid above that=C2=A0

Also as= discussed in the interop, I did not add any additional requirements in ARC= regarding key lengths. I will be submitting an update to the DKIM spec its= elf to fork both the key length and signing algorithms into a registry whic= h can then be managed without requiring further spec updates.
--Kurt
--94eb2c18745683e656054acd287d-- From nobody Thu Mar 16 06:11:07 2017 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 DF7F9129496; Thu, 16 Mar 2017 06:11:00 -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.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148966986084.14257.14367435061294663998@ietfa.amsl.com> Date: Thu, 16 Mar 2017 06:11:00 -0700 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-02.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 16 Mar 2017 13:11:01 -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 of the IETF. Title : Authenticated Received Chain (ARC) Protocol Authors : Kurt Andersen Brandon Long Steven Jones Filename : draft-ietf-dmarc-arc-protocol-02.txt Pages : 45 Date : 2017-03-16 Abstract: Authenticated Received Chain (ARC) permits an organization which is creating or handling email to indicate its involvement with the handling process. It defines a set of cryptographically signed header fields in a manner analagous to that of DKIM. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Changes in the message that might break DKIM can be identified through the ARC set of header fields. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-protocol-02 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 Fri Mar 17 00:43:31 2017 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 60ECA124D6C for ; Fri, 17 Mar 2017 00:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 KI_iaak7y0ka for ; Fri, 17 Mar 2017 00:43:27 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 591C11243FE for ; Fri, 17 Mar 2017 00:43:27 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id d188so36600173vka.0 for ; Fri, 17 Mar 2017 00:43:27 -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=oSGxHxHHz8uODD4Tf4a/FSplmQN94icQeuS0o+HbDjU=; b=hE5X32z8+99ra/QLVX/Q0Pmn13v0T/Y4Vef/o+jZBm7rnIgv7aFYZeDnrxGed1D8IH 1aTAL+yuuMrQiNqm5APBt0d8RHH+9uzaRZmpJ0GxQ3BbEbnIAvV8lZzwTZOkIhKxvvyv x1q6AD9phh/NEAaWbgH6qBAc4YtCupVsu6ReBsnOh7Nu4s/ZMRdlYdM9AKJFMk2L5fu7 HVZBz7tV12TBQZWdTEr8fs6GrjBKPDqLWw5fA/qP05jFu19ddDH1DtwheuTa6axBZGCa iukg/g9FluEzQ4B0xQIJsIN6FhKUEqqd/YfeDt3PgnILny+kBO1g0lJZVItXI9aHPBjn kDXA== 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=oSGxHxHHz8uODD4Tf4a/FSplmQN94icQeuS0o+HbDjU=; b=O717VCJvdK7VZc23V7gQSgf5MSzOSVd97B/fTpHzE6OJpVS5Ak+eea/Uk5wJjzO3uw meAeQIZg/Hn35gcoWASG3tJ6ivaHznJUW8dops0Q3oo66qmHsKfsdkV5CUGthFIgDdVk AREUMY0YVg+9WkSfpJvu76rAQnjXPeTANVhnZ0NwlkbUV6AJEXg+mIjX5V7TSeJNlaaz NT6pFXzglCehqCTBtSUXr+/UH7Oa7p+erjDm0ZqUu3QtOqVt8zN0JR8maZ5+bG2K/Fje 30fzpKx863rJz7loK/x7Ae7b8f5fPshFOmMjdacUyfCdn/+NR6WJVk+3Pn9DfhujFt1E f/9w== X-Gm-Message-State: AFeK/H2r9ZPhxuIo8Bd0BBDDnDu/ZsmZl/QahEhtera0k1r+LnWOipgO8BTs0yDpFX8qH3/RDTUV4jQim8j4Dg== X-Received: by 10.31.33.75 with SMTP id h72mr5285311vkh.26.1489736606466; Fri, 17 Mar 2017 00:43:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.147.13 with HTTP; Fri, 17 Mar 2017 00:43:25 -0700 (PDT) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Fri, 17 Mar 2017 00:43:25 -0700 Message-ID: To: Kurt Andersen Cc: "dmarc@ietf.org" , Seth Blank , Steve Jones , Barry Leiba Content-Type: multipart/alternative; boundary=001a11c01bca3cf79f054ae85591 Archived-At: Subject: Re: [dmarc-ietf] "Missed it by *that* much". . . X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2017 07:43:29 -0000 --001a11c01bca3cf79f054ae85591 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 15, 2017 at 4:18 PM, Kurt Andersen wrote: > I discovered today as I attempted to submit the ARC protocol update that > I've been working on, that the submission system closed about 40 hours > earlier - sigh. > > Since I'm headed to Ecuador for a three week vacation with unknown and/or > unlikely Internet access, I have created a git repo and posted the source > (kramdown) and rendered xml, txt, html versions for both the protocol and > usage documents at https://github.com/kurta/arc-docs > Thanks, I'll take a run at it soon, especially during Chicago. > Also as discussed in the interop, I did not add any additional > requirements in ARC regarding key lengths. I will be submitting an update > to the DKIM spec itself to fork both the key length and signing algorithms > into a registry which can then be managed without requiring further spec > updates. There's already registries for DKIM key types and hash algorithms, so no need to create any: https://www.iana.org/assignments/dkim-parameters/dkim-parameters.xhtml I'm not sure how you could go about registering key lengths. What do you have in mind? -MSK --001a11c01bca3cf79f054ae85591 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 15, 2017 at 4:18 PM, Kurt Andersen <ka= ndersen@linkedin.com> wrote:
=
I discovered today as I attempted to submit the ARC protoc= ol update that I've been working on, that the submission system closed = about 40 hours earlier - sigh.

Since I'm headed to E= cuador for a three week vacation with unknown and/or unlikely Internet acce= ss, I have created a git repo and posted the source (kramdown) and rendered= xml, txt, html versions for both the protocol and usage documents at=C2=A0= https://git= hub.com/kurta/arc-docs

Thanks, I'll take a run at it soon, especially during Chicago.
=C2= =A0
Also as disc= ussed in the interop, I did not add any additional requirements in ARC rega= rding key lengths. I will be submitting an update to the DKIM spec itself t= o fork both the key length and signing algorithms into a registry which can= then be managed without requiring further spec updates.

There's already regis= tries for DKIM key types and hash algorithms, so no need to create any:
= https://www.iana.org/assignments/dkim-parameters/dkim-parameters.xh= tml

I'm not sure how you could go about registering key leng= ths.=C2=A0 What do you have in mind?

-MSK
<= br>
--001a11c01bca3cf79f054ae85591-- From nobody Fri Mar 17 06:55:07 2017 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 EC9E3129432 for ; Fri, 17 Mar 2017 06:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.852 X-Spam-Level: X-Spam-Status: No, score=-0.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGIs0lynrIJN for ; Fri, 17 Mar 2017 06:55:05 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFCB0129421 for ; Fri, 17 Mar 2017 06:55:04 -0700 (PDT) Received: (qmail 69908 invoked from network); 17 Mar 2017 13:55:03 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 17 Mar 2017 13:55:03 -0000 Date: 17 Mar 2017 00:23:15 -0000 Message-ID: <20170317002315.50000.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org Cc: superuser@gmail.com In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] "Missed it by *that* much". . . X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2017 13:55:06 -0000 In article you write: >I'm not sure how you could go about registering key lengths. What do you >have in mind? Come to DISPATCH and learn all about it. The general point is that DKIM's key advice is kind of stale -- 512 bit keys are too short, 1024 keys are OK now, but within the likely lifetime of this spec we'll need longer keys. The obvious suggestion is 2048 except they don't fit in a single TXT record string, and way too much DNS web crudware(tm) doesn't handle multiple strings. Oh, and elliptic curve. R's, John From nobody Fri Mar 17 15:22:31 2017 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 A05C412962E for ; Fri, 17 Mar 2017 15:22:29 -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 AHad4Ctsl0LM for ; Fri, 17 Mar 2017 15:22:28 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::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 CC0C112962D for ; Fri, 17 Mar 2017 15:22:27 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id f54so51799314uaa.1 for ; Fri, 17 Mar 2017 15:22:27 -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=j7wKHMHg4D7YQEoeQcH7VoaLZU0ojNkWyjnqnlrOh54=; b=OMoHY37U3rDCcCL0zCkW/9mJsa1AWKTE06bzWOlY1TlJCRvraRejioiCYv+sbwb65X Qh6rkbNUpSg+YEWxpR7NZOwuKys+12kj9ao/U664ca9lEjw0QDu7tggh1QkqEksduRcJ fb0VgmG1KBF5K8GwvTzgg3QDnnRymBINC109AZkYKPxY7c3gzPe85As9eHNJxXWnO501 07KYOoIRzaqaXimwh+XhnNZlWbYKYmCiz7jUszc4STs5il5rwHC81ZQAx3onlNAnfIPN mRAsbm7Az0WHNymmi5CfgiBHtTBsofhOOJ0DK14gzT7PzWItRY1uGIaBtoWGddjapKpv M1jw== 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=j7wKHMHg4D7YQEoeQcH7VoaLZU0ojNkWyjnqnlrOh54=; b=bFLx8jxrs/yy25nq3T1+Ib0PiY7CyjfQv6LJLePN3r8ZXxRJY4KgJy+krPQwEzhMuM cL9N9v35tIyB+/IDP/O2NwSDw8MWo3pwvkyvIDNpcZ4xwMZ3LgTYd3fNOH4VMAa/p13H 4pe0PR/eQs+5VYYWaXkN1FyIMCSwAJKLjJssJPrSIIcGvA4M5KF6tGhKKefZRq4AmrQu hhAc4rXCjcYqbkvdJ34wGUSRJYciJ6TW8uk4pgtU1fAwta1EpVbaZzxMgjsJoFcU1tyG UtPFBHRQwgZN+czgQNc5gkYgI/L5/n9DU4MZEH//ENkr5Gf2IbguRT6ukVFjP3KYpYsJ Dg8g== X-Gm-Message-State: AFeK/H0iWm7WQTFB/lAx5wLXxJtXnpRHh0Ct1qyEIP3Hna8RW8mUjBozTh461HRPhIA60Twoa4YSzKHg8CCWSw== X-Received: by 10.176.84.76 with SMTP id o12mr2650403uaa.132.1489789346947; Fri, 17 Mar 2017 15:22:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.147.13 with HTTP; Fri, 17 Mar 2017 15:22:26 -0700 (PDT) In-Reply-To: <20170317002315.50000.qmail@ary.lan> References: <20170317002315.50000.qmail@ary.lan> From: "Murray S. Kucherawy" Date: Fri, 17 Mar 2017 15:22:26 -0700 Message-ID: To: John Levine Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c1b2df2d0a7dd054af49cfd Archived-At: Subject: Re: [dmarc-ietf] "Missed it by *that* much". . . X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2017 22:22:29 -0000 --94eb2c1b2df2d0a7dd054af49cfd Content-Type: text/plain; charset=UTF-8 On Thu, Mar 16, 2017 at 5:23 PM, John Levine wrote: > In article gmail.com> you write: > >I'm not sure how you could go about registering key lengths. What do you > >have in mind? > > Come to DISPATCH and learn all about it. > Oh, don't you worry. :-) The general point is that DKIM's key advice is kind of stale -- 512 bit > keys are > too short, 1024 keys are OK now, but within the likely lifetime of this > spec > we'll need longer keys. The obvious suggestion is 2048 except they don't > fit in a single TXT record string, and way too much DNS web crudware(tm) > doesn't handle multiple strings. > > Oh, and elliptic curve. > Sure; the existing registries are for hash algorithms and key types. Obviously more of those could be added, or we could deprecate some entries. And I could see an "Updates" document changing what DKIM says about supported or recommended key sizes, or amendments to these registries. But Kurt said something about creating an IANA registry of supported key sizes, and I don't know what that would look like. I'll find out in Chicago, I guess. -MSK --94eb2c1b2df2d0a7dd054af49cfd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 16, 2017 at 5:23 PM, John Levine <johnl@taugh.c= om> wrote:
In article <CAL0qLwZDCbP2tWAp6RH38jTdkZueH8WPTbwd6Kfjk6Y0csZEXg@mail.gm= ail.com> you write:
>I'm not sure how you could go about registering key lengths.=C2=A0 = What do you
>have in mind?

Come to DISPATCH and learn all about it.

Oh, don't you worry.=C2=A0 :-)

The general point is that DKIM's key advice is kind of stale -- 512 bit= keys are
too short, 1024 keys are OK now, but within the likely lifetime of this spe= c
we'll need longer keys.=C2=A0 The obvious suggestion is 2048 except the= y don't
fit in a single TXT record string, and way too much DNS web crudware(tm) doesn't handle multiple strings.

Oh, and elliptic curve.

Sure; the exist= ing registries are for hash algorithms and key types.=C2=A0 Obviously more = of those could be added, or we could deprecate some entries.=C2=A0 And I co= uld see an "Updates" document changing what DKIM says about suppo= rted or recommended key sizes, or amendments to these registries.=C2=A0 But= Kurt said something about creating an IANA registry of supported key sizes= , and I don't know what that would look like.

I'l= l find out in Chicago, I guess.

-MSK
--94eb2c1b2df2d0a7dd054af49cfd-- From nobody Fri Mar 24 02:19:17 2017 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 6EE7B12955D for ; Fri, 24 Mar 2017 02:19:16 -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 UU8Mg7VFZNYh for ; Fri, 24 Mar 2017 02:19:14 -0700 (PDT) Received: from lepidum.jp (lepidum.jp [60.32.83.213]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17394129567 for ; Fri, 24 Mar 2017 02:19:12 -0700 (PDT) Received: from [10.51.128.141] (lepidum.net [60.32.83.208]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: okd@lepidum.co.jp) by mail06.server.lepidum.net (Postfix) with ESMTPSA id 4C0F92F8000C5; Fri, 24 Mar 2017 18:19:10 +0900 (JST) From: Kouji Okada Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: <8559BB82-3951-4B14-A3D9-011936AEAD9E@lepidum.co.jp> Date: Fri, 24 Mar 2017 18:19:09 +0900 Cc: Kouji Okada To: dmarc X-Mailer: Apple Mail (2.3259) X-Clamav-Info: Checked(Clean) X-LepidumMailFilterAgent-by: mailfromd (5.1) X-LepidumMailFilterAgent-Info: Original (mailfrom:Inbound) Archived-At: Subject: [dmarc-ietf] updating draft-akagiri-dmarc-virtual-verification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 24 Mar 2017 09:19:16 -0000 Folks We are now working on revising draft-akagiri-dmarc-virtual-verification. = https://datatracker.ietf.org/doc/html/draft-akagiri-dmarc-virtual-verifica= tion We are going to submit new version in early April. Authors are recognizing there are some open issues for the draft. 1. The authentication code. In the draft, we suggest to mark =E2=80=9Cdmarc=3Dpass=E2=80=9D in the = authentication result when the virtual dmarc verifications have passed. We are going to keep it as it is. In 02, we are going to mention that e-mail operators can add comments to the authentication result field to indicate the =E2=80=9Cpass=E2=80=9D = is marked by the virtual verification. We are not going to define the format of the comments, but the example comment would be like below. ex) dmarc=3Dpass(vdmarc=3Dtrue) 2. vdmarc=3Dfail problem When submitting 00 version of the draft, some people gave us the comments that it is harmful to mark =E2=80=9Cdmarc=3Dfail=E2=80=9D without explicit = declaration of policy records. Our intention is to utilize the authentication results of = =E2=80=9Cdmarc=3Dpass=E2=80=9D for the e-mails potentially can be treated as so. As Takehito posted to this ML, our evaluation on Japanese ISPs showed more than 20% of received email traffic can be treated as "dmarc=3Dpass" = with our verification. Thus our proposal helps to increase the number of legitimate e-mails on = the receiver side. =E2=80=9CStatistics about effects of =E2=80=9CVirtual DMARC=E2=80=9D=E2=80= =9D: https://www.vdmarc.dmarc.jp/?p=3D122 We are going to emphasize the point in 02. 3. rua, ruf We do not define any default report destinations for the virtual = verification. 4. Draft tile Currently our draft title is =E2=80=9CDMARC verification without record = definitions(dmarc-virtual-verification)=E2=80=9D. Would you have any suggestions for the title? Any comments will be appreciated. Thank you, Kouji Okada From nobody Fri Mar 24 09:55:47 2017 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 77B2F126C25 for ; Fri, 24 Mar 2017 09:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-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 h5iEKiMExHhg for ; Fri, 24 Mar 2017 09:55:43 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0121.outbound.protection.outlook.com [104.47.42.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D285127078 for ; Fri, 24 Mar 2017 09:55:43 -0700 (PDT) Received: from CO2PR00MB0120.namprd00.prod.outlook.com (10.166.215.146) by CO2PR00MB0152.namprd00.prod.outlook.com (10.166.214.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1018.0; Fri, 24 Mar 2017 16:55:42 +0000 Received: from CO2PR00MB0120.namprd00.prod.outlook.com ([fe80::4d26:dd65:8c4a:fc54]) by CO2PR00MB0120.namprd00.prod.outlook.com ([fe80::4d26:dd65:8c4a:fc54%18]) with mapi id 15.01.1018.000; Fri, 24 Mar 2017 16:55:42 +0000 From: Terry Zink To: dmarc Thread-Topic: [dmarc-ietf] updating draft-akagiri-dmarc-virtual-verification Thread-Index: AQHSpH+5NEZHb5SR50y5vEzhA1tBMaGkNVPQ Date: Fri, 24 Mar 2017 16:55:42 +0000 Message-ID: References: <8559BB82-3951-4B14-A3D9-011936AEAD9E@lepidum.co.jp> In-Reply-To: <8559BB82-3951-4B14-A3D9-011936AEAD9E@lepidum.co.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [71.35.189.247] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CO2PR00MB0152; 7:q2eKDfEKgbHYMvSRTjbS1zBghG3n9/uDs8vFGf12oeXSvXEeZMHq92Lp2Z0aK+itgqjGbvFVkibct8oZva5XGZHDcyiFS9MczMUMG6jyRA1c9US9oV756KoQHbpEY/7KDdL5bRMM9/tVQhEYnmknrn1MN7fxjXd255zSC7mHiquYiKG0fbuVdkMwSrCffWCxk+jngyjkLRTTuT5WpeQq/M/0CqcXL1s7ZRv8SFOq3SsJ0AsVFudp0L/Q7PwM055HbAABW6mZRRocMllqFcCOI88qDZnpx5RYWnSt1swuyncTJHLqNxU+gRuFNQCl0lhYrou/GNJWjfXBbcyR29XJqqZcFM1eRkB2gw90K1E6ESM= x-ms-office365-filtering-correlation-id: e7a0fd72-6b41-4d12-1c0f-08d472d69b7f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423013)(201703031133019)(201702281549013); SRVR:CO2PR00MB0152; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(189930954265078)(219752817060721); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040391)(601004)(2401047)(5005006)(8121501046)(10201501046)(93006021)(93001021)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123555025)(201703131423016)(201702281528016)(201703061421016)(201703061406016)(20161123562025)(20161123564025)(20161123558025)(6072148); SRVR:CO2PR00MB0152; BCL:0; PCL:0; RULEID:; SRVR:CO2PR00MB0152; x-forefront-prvs: 0256C18696 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39850400002)(39860400002)(39840400002)(39410400002)(39400400002)(13464003)(377454003)(76176999)(50986999)(5005710100001)(10290500002)(10090500001)(230783001)(8936002)(5660300001)(15650500001)(7736002)(54356999)(3280700002)(25786009)(2906002)(110136004)(2900100001)(53546009)(86362001)(575784001)(74316002)(5250100002)(8676002)(86612001)(6246003)(6506006)(561944003)(33656002)(7696004)(55016002)(6306002)(66066001)(6916009)(6436002)(53936002)(2950100002)(9686003)(3846002)(3660700001)(229853002)(189998001)(6116002)(81166006)(305945005)(99286003)(102836003)(38730400002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR00MB0152; H:CO2PR00MB0120.namprd00.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Mar 2017 16:55:42.2598 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR00MB0152 Archived-At: Subject: Re: [dmarc-ietf] updating draft-akagiri-dmarc-virtual-verification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 24 Mar 2017 16:55:45 -0000 TWljcm9zb2Z0IGFscmVhZHkgZG9lcyB3aGF0IGlzIGluIHRoZSBzcGVjIGluIE9mZmljZSAzNjUg KHdoaWNoIHRoZXkgc3BlY2lmaWNhbGx5IGNhbGwgb3V0IGluIHRoZSBkcmFmdCksIHNvIGV2ZW50 dWFsbHkgSG90bWFpbC9PdXRsb29rLmNvbSB3aWxsIGluaGVyaXQgaXQuIEJ1dCB0aGVyZSBhcmUg dHdvIGRpZmZlcmVuY2VzOg0KDQoxLiBPZmZpY2UgMzY1IHN0YW1wcyAiZG1hcmM9YmVzdGd1ZXNz cGFzcyIsIG5vdCAiZG1hcmM9cGFzcyIuIFRoYXQgbWFrZXMgaXQgZWFzaWVyIHRvIGRpc3Rpbmd1 aXNoIGluIHRoZSBsb2dzDQoyLiBXZSBkbyByZWxheGVkIGFsaWdubWVudCwgbm90IHN0cmljdCBh bGlnbm1lbnQgbGlrZSBpdCBzYXlzIGluIHRoZSBzcGVjDQoNClNlZW1zIHRvIHdvcmsganVzdCBm aW5lLg0KDQpBbHNvLCBub3Qgc3VyZSB3aHkgdGhlcmUgd291bGQgYmUgYSBkaXNjdXNzaW9uIG9m IHJ1YSBhbmQgcnVmLiBJdCdzIHN0cmFpZ2h0Zm9yd2FyZCB0byBpbnRlcnBvbGF0ZSB0aGUgdmly dHVhbCBETUFSQyByZWNvcmQgYnV0IGhvdyBjYW4geW91IGludGVycG9sYXRlIHdoZXJlIHRvIHNl bmQgYSBmYWlsdXJlIHJlcG9ydD8NCg0KLS1UZXJyeQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogZG1hcmMgW21haWx0bzpkbWFyYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgS291amkgT2thZGENClNlbnQ6IEZyaWRheSwgTWFyY2ggMjQsIDIwMTcgMjoxOSBBTQ0K VG86IGRtYXJjIDxkbWFyY0BpZXRmLm9yZz4NCkNjOiBLb3VqaSBPa2FkYSA8b2tkQGxlcGlkdW0u Y28uanA+DQpTdWJqZWN0OiBbZG1hcmMtaWV0Zl0gdXBkYXRpbmcgZHJhZnQtYWthZ2lyaS1kbWFy Yy12aXJ0dWFsLXZlcmlmaWNhdGlvbg0KDQpGb2xrcw0KDQpXZSBhcmUgbm93IHdvcmtpbmcgb24g cmV2aXNpbmcgZHJhZnQtYWthZ2lyaS1kbWFyYy12aXJ0dWFsLXZlcmlmaWNhdGlvbi4NCmh0dHBz Oi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJG JTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZodG1sJTJGZHJhZnQtYWthZ2lyaS1kbWFy Yy12aXJ0dWFsLXZlcmlmaWNhdGlvbiZkYXRhPTAyJTdDMDElN0N0emluayU0MG1pY3Jvc29mdC5j b20lN0M3NWNkNTczOTM2OGE0MGNlNjgyMjA4ZDQ3Mjk2ZGE5NSU3QzcyZjk4OGJmODZmMTQxYWY5 MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzYyNTk0Mzk2MjA5MzIzNTcmc2RhdGE9bERBaTZU amxkQ1hvZ0dabFFJMVZwTGZZT3lhM2ZqYUpQUm44bXRCZ28xVSUzRCZyZXNlcnZlZD0wDQoNCldl IGFyZSBnb2luZyB0byBzdWJtaXQgbmV3IHZlcnNpb24gaW4gZWFybHkgQXByaWwuDQpBdXRob3Jz IGFyZSByZWNvZ25pemluZyB0aGVyZSBhcmUgc29tZSBvcGVuIGlzc3VlcyBmb3IgdGhlIGRyYWZ0 Lg0KDQoxLiBUaGUgYXV0aGVudGljYXRpb24gY29kZS4NCg0KSW4gdGhlIGRyYWZ0LCB3ZSBzdWdn ZXN0IHRvIG1hcmsg4oCcZG1hcmM9cGFzc+KAnSBpbiB0aGUgYXV0aGVudGljYXRpb24gcmVzdWx0 IHdoZW4gdGhlIHZpcnR1YWwgZG1hcmMgdmVyaWZpY2F0aW9ucyBoYXZlIHBhc3NlZC4NCldlIGFy ZSBnb2luZyB0byBrZWVwIGl0IGFzIGl0IGlzLg0KDQpJbiAwMiwgd2UgYXJlIGdvaW5nIHRvIG1l bnRpb24gdGhhdCBlLW1haWwgb3BlcmF0b3JzIGNhbiBhZGQgY29tbWVudHMgdG8gdGhlIGF1dGhl bnRpY2F0aW9uIHJlc3VsdCBmaWVsZCB0byBpbmRpY2F0ZSB0aGUg4oCccGFzc+KAnSBpcyBtYXJr ZWQgYnkgdGhlIHZpcnR1YWwgdmVyaWZpY2F0aW9uLg0KV2UgYXJlIG5vdCBnb2luZyB0byBkZWZp bmUgdGhlIGZvcm1hdCBvZiB0aGUgY29tbWVudHMsIGJ1dCB0aGUgZXhhbXBsZSBjb21tZW50IHdv dWxkIGJlIGxpa2UgYmVsb3cuDQoNCmV4KSBkbWFyYz1wYXNzKHZkbWFyYz10cnVlKQ0KDQoyLiB2 ZG1hcmM9ZmFpbCBwcm9ibGVtDQoNCldoZW4gc3VibWl0dGluZyAwMCB2ZXJzaW9uIG9mIHRoZSBk cmFmdCwgc29tZSBwZW9wbGUgZ2F2ZSB1cyB0aGUgY29tbWVudHMgdGhhdCBpdCBpcyBoYXJtZnVs IHRvIG1hcmsg4oCcZG1hcmM9ZmFpbOKAnSB3aXRob3V0IGV4cGxpY2l0IGRlY2xhcmF0aW9uIG9m IHBvbGljeSByZWNvcmRzLg0KT3VyIGludGVudGlvbiBpcyB0byB1dGlsaXplIHRoZSBhdXRoZW50 aWNhdGlvbiByZXN1bHRzIG9mIOKAnGRtYXJjPXBhc3PigJ0NCmZvciB0aGUgZS1tYWlscyBwb3Rl bnRpYWxseSBjYW4gYmUgdHJlYXRlZCBhcyBzby4NCg0KQXMgVGFrZWhpdG8gcG9zdGVkIHRvIHRo aXMgTUwsDQpvdXIgZXZhbHVhdGlvbiBvbiBKYXBhbmVzZSBJU1BzIHNob3dlZA0KbW9yZSB0aGFu IDIwJSBvZiByZWNlaXZlZCBlbWFpbCB0cmFmZmljIGNhbiBiZSB0cmVhdGVkIGFzICJkbWFyYz1w YXNzIiB3aXRoIG91ciB2ZXJpZmljYXRpb24uDQpUaHVzIG91ciBwcm9wb3NhbCBoZWxwcyB0byBp bmNyZWFzZSB0aGUgbnVtYmVyIG9mIGxlZ2l0aW1hdGUgZS1tYWlscyBvbiB0aGUgcmVjZWl2ZXIg c2lkZS4NCg0K4oCcU3RhdGlzdGljcyBhYm91dCBlZmZlY3RzIG9mIOKAnFZpcnR1YWwgRE1BUkPi gJ3igJ06DQogIGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/ dXJsPWh0dHBzJTNBJTJGJTJGd3d3LnZkbWFyYy5kbWFyYy5qcCUyRiUzRnAlM0QxMjImZGF0YT0w MiU3QzAxJTdDdHppbmslNDBtaWNyb3NvZnQuY29tJTdDNzVjZDU3MzkzNjhhNDBjZTY4MjIwOGQ0 NzI5NmRhOTUlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2 MjU5NDM5NjIwOTQyMzY0JnNkYXRhPW1WeWVaNUVNSTZjajFwdlVYVllpblpaaTY0SkxxakU5djkw aUNVd2lKNE0lM0QmcmVzZXJ2ZWQ9MA0KDQpXZSBhcmUgZ29pbmcgdG8gZW1waGFzaXplIHRoZSBw b2ludCBpbiAwMi4NCg0KMy4gcnVhLCBydWYNCg0KV2UgZG8gbm90IGRlZmluZSBhbnkgZGVmYXVs dCByZXBvcnQgZGVzdGluYXRpb25zIGZvciB0aGUgdmlydHVhbCB2ZXJpZmljYXRpb24uDQoNCjQu IERyYWZ0IHRpbGUNCg0KQ3VycmVudGx5IG91ciBkcmFmdCB0aXRsZSBpcyDigJxETUFSQyB2ZXJp ZmljYXRpb24gd2l0aG91dCByZWNvcmQgZGVmaW5pdGlvbnMoZG1hcmMtdmlydHVhbC12ZXJpZmlj YXRpb24p4oCdLg0KV291bGQgeW91IGhhdmUgYW55IHN1Z2dlc3Rpb25zIGZvciB0aGUgdGl0bGU/ DQoNCg0KQW55IGNvbW1lbnRzIHdpbGwgYmUgYXBwcmVjaWF0ZWQuDQoNClRoYW5rIHlvdSwNCktv dWppIE9rYWRhDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCmRtYXJjIG1haWxpbmcgbGlzdA0KZG1hcmNAaWV0Zi5vcmcNCmh0dHBzOi8vbmEwMS5z YWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3Lmll dGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGZG1hcmMmZGF0YT0wMiU3QzAxJTdDdHppbmsl NDBtaWNyb3NvZnQuY29tJTdDNzVjZDU3MzkzNjhhNDBjZTY4MjIwOGQ0NzI5NmRhOTUlN0M3MmY5 ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2MjU5NDM5NjIwOTQyMzY0 JnNkYXRhPUFlSVUxbHM5N2YlMkZrdG9YMFp1VHVmdjF4REUwUTglMkZUQXElMkJHcEs4ZzlNdkUl M0QmcmVzZXJ2ZWQ9MA0K From nobody Fri Mar 24 11:17:51 2017 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 86AB0129889 for ; Fri, 24 Mar 2017 11:17:50 -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 (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irFlaVZMbDiq for ; Fri, 24 Mar 2017 11:17:43 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3760D12987B for ; Fri, 24 Mar 2017 11:17:43 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id l43so6891897wre.1 for ; Fri, 24 Mar 2017 11:17:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:from:date:message-id:subject:to; bh=JtcarRNtmkmwg1BO5XbZRKI3xoewcZRVXjT2bBZxwOc=; b=WozDxHuR7vgMDEu86QwBFKJ+E563azPvXYprIuBssR1blwsiojGbjYElXhdLUX6kjE w0HyJxBw04O/t5QQ0YDwIQ61mZWUBfQkR15f5QUSofz4EqrCpI+bR6Z3s6tKOGLUxzDD SjNon4BLtXbUC6ueAS7rPnOD8R2v+1v8X4Z3oI/1gYnCtTt+S67JNklWVaI2lX6Nh0eZ xOH3V+UARXVq4djG2GPkG99rwAKSptNi6pncslDi1FM3WYJz1B+y4YRp+tLoMSXFurud tbYWTGGVkVAZujKo9n1md2jsv+CEJo+e9zoLRUiYjIwBS/Jxyw5Qn0VtstEhov31bsmG BAlQ== 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=JtcarRNtmkmwg1BO5XbZRKI3xoewcZRVXjT2bBZxwOc=; b=igXGHpN0Yx1zSjWeDdlbWhqpo2bUtuu3Cyx8kYqXuffzFfxGwr2NNC7TlwaAir2RUV T+WQT8UkpleuKLdx+1AIWzStNh+4NoFCEZIEdOI/C4ozDJgtyM0J7gXNtPAQ6u8RIpDb LX3ijrndHXqV5fqndCodIoFzPZw2CFahAKaZVr3p4HtApx5kcp40EcJ7/TY8qcnwZh3u 9cqfdzbhUvB4bX4s2daqNwxnkHVfohMmA5ewsWEkWltpLZrK+Ax3XwOObc/Rm52onKFt GhjlfUp1jYmVHMSstaGa109iMKK6EMHF5P304xm1XRQtZAXjpa353+1vv0jxVRS/vG/H XRyg== X-Gm-Message-State: AFeK/H05X8H/Dra99qGf6vcWYjrCdgPkdNpFhSsPskJj8AZmYldbmn3ndz1w30QkZgc/OUv5YZ/IjK+hokv+CA== X-Received: by 10.223.164.83 with SMTP id e19mr9012135wra.201.1490379461244; Fri, 24 Mar 2017 11:17:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.142.130 with HTTP; Fri, 24 Mar 2017 11:17:40 -0700 (PDT) From: Gene Shuman Date: Fri, 24 Mar 2017 11:17:40 -0700 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary=f403045f1f985e6008054b7e023e Archived-At: Subject: [dmarc-ietf] indeterminisim of ARC-Seal b= value X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 24 Mar 2017 18:17:51 -0000 --f403045f1f985e6008054b7e023e Content-Type: text/plain; charset=UTF-8 Hi All, Based on a conversation I had with Murray the other day, I'd like to revive a conversation I'd started on the ARC discuss forum a few months back. Basically there is a subtle issue present in the current ARC draft that doesn't exist with DKIM that I don't think most people are aware of that gives implementor a large degree of control over ARC-Seal b= values The issue is that its possible for two separate arc implementations, given the exact same message inputs, keys, timestamps, etc to be generating two different, but equally valid ARC seal hashes. Basically, the ARC-seal b= tag *is not deterministic* based on the incoming message. This hash value is *implementation dependent.* I think that we want to think about this, as this state of affairs does not exist in DKIM. In DKIM(for a given set of headers to sign, etc), there are only one valid b= & bh= hashes. Here are some details. Message 1 comes in with no arc signature. The implementation creates an ARC-Message-Signature tag, which is basically just a DKIM signature. Given, timestamps, header list, selector, domain, etc, there is exactly one way to compute both the b= & bh= tags. However, *the *implementation* is free to vary the text representation of this signature*. There is no sort of canonicalization happening here. The implementation is free to order tags arbitrarily, and things like add additional tags & whitespace. The reason this matters is because the textual representation of this signature is used in the ARC-Seal's b= computation, making this value *arbitrarily implementation dependent. *The implementation has a very large degree of control over the actual value of the ARC-Seal b= hash, and this seems like a non-trivial security risk. The obvious solution I see here is to canonicalize the headers going into the the AS computation. There are some pretty sensible ways to do this. --f403045f1f985e6008054b7e023e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All,

Based on a conversation I had w= ith Murray the other day, I'd like to revive a conversation I'd sta= rted on the ARC discuss forum a few months back.=C2=A0 Basically there is a= subtle issue present in the current ARC draft that doesn't exist with = DKIM that I don't think most people are aware of that gives implementor= a large degree of control over ARC-Seal b=3D values

The issue is that its possible for two separate arc implementations, giv= en the exact same message inputs, keys, timestamps, etc to be generating tw= o different, but equally valid ARC seal hashes.=C2=A0 Basically, the ARC-se= al b=3D tag is not deterministic=C2=A0based on the incoming message.= =C2=A0 This hash value is implementation dependent.=C2=A0 I think th= at we want to think about this, as this state of affairs does not exist in = DKIM.=C2=A0 In DKIM(for a given set of headers to sign, etc), there are onl= y one valid b=3D & bh=3D hashes. =C2=A0=C2=A0

= Here are some details.=C2=A0 Message 1 comes in with no arc signature.=C2= =A0 The implementation creates an ARC-Message-Signature tag, which is basic= ally just a DKIM signature.=C2=A0 Given, timestamps, header list, selector,= domain, etc, there is exactly one way to compute both the b=3D & bh=3D= tags.=C2=A0 However, the implementation is free to vary the text= representation of this signature.=C2=A0 There is no sort of canonicali= zation happening here.=C2=A0 The implementation is free to order tags arbit= rarily, and things like add additional tags & whitespace. =C2=A0
<= div>
The reason this matters is because the textual represent= ation of this signature is used in the ARC-Seal's b=3D computation, mak= ing this value arbitrarily implementation dependent. =C2=A0The imple= mentation has a very large degree of control over the actual value of the A= RC-Seal b=3D hash, and this seems like a non-trivial security risk. =C2=A0<= /div>

The obvious solution I see here is to canonicalize= the headers going into the the AS computation.=C2=A0 There are some pretty= sensible ways to do this. =C2=A0
--f403045f1f985e6008054b7e023e-- From nobody Fri Mar 24 14:23:38 2017 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 18CD5127F0E for ; Fri, 24 Mar 2017 14:23:32 -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 Xu0kRKxk8N2n for ; Fri, 24 Mar 2017 14:23:28 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9F6B129504 for ; Fri, 24 Mar 2017 14:23:27 -0700 (PDT) Received: (qmail 74505 invoked from network); 24 Mar 2017 21:23:26 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 24 Mar 2017 21:23:26 -0000 Date: 24 Mar 2017 21:23:04 -0000 Message-ID: <20170324212304.85346.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org Cc: gene@valimail.com In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 24 Mar 2017 21:23:32 -0000 In article you write: >The issue is that its possible for two separate arc implementations, given >the exact same message inputs, keys, timestamps, etc to be generating two >different, but equally valid ARC seal hashes. DKIM does the same thing. The order of fields in a DKIM-Signature header is arbitrary, and the b= hash includes that header, so there are lots of different equivalent DKIM signatures for the same message and same selector and key. Verifiers use the DKIM-Signature header in the message so they get the same answer as the signer, which I would think would work the same way in ARC-Seal. Can you explain why you think this is a problem? R's, John From nobody Fri Mar 24 21:46:02 2017 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 BAA3812940D for ; Fri, 24 Mar 2017 21:46:00 -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_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.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 vfbYWtGYZscJ for ; Fri, 24 Mar 2017 21:45:58 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1430C126BF7 for ; Fri, 24 Mar 2017 21:45:57 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 44172C401A8 for ; Fri, 24 Mar 2017 23:45:55 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1490417155; bh=Bs0YfVARW9ZUilYQ9EiXh2MkObFE1qpGNf1lmXGN4bg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=RudR2bRDeAVZoZKQg2LqCze9/MtrfdyRZiW4wWwjFMe1tSWl6Nxc6f+hzsgAkXJLC YxE3wLieSgFPYzO8iflRaXEZXO7bBwA4ex9V6C8Sce58+rJ+aFYtQ8WaaX7UIQQRxc c5xLQe5uS7JsMV5QqYuECC2zRYaOzCtWF9lno00A= From: Scott Kitterman To: dmarc@ietf.org Date: Sat, 25 Mar 2017 00:45:54 -0400 Message-ID: <2153663.3j7HfnN8Lr@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-112-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <8559BB82-3951-4B14-A3D9-011936AEAD9E@lepidum.co.jp> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Archived-At: Subject: Re: [dmarc-ietf] updating draft-akagiri-dmarc-virtual-verification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2017 04:46:01 -0000 For SPF, we had "best guess" [1], which we chose not to standardize at = all=20 because we didn't think it appropriate to break the opt-in nature of SP= F. =20 This concerns me a bit here, but I'm mostly writing to support the idea= of=20 distinguishing between some kind of guess and an actual DMARC result. I think "dmarc=3Dbestguesspass" is far superior to "dmarc=3Dpass", sinc= e this is=20 not a DMARC pass. I think "dmarcguess=3Dpass" would be better since th= is isn't=20 properly a DMARC check at all. Scott k [1] http://www.openspf.org/FAQ/Best_guess_record On Friday, March 24, 2017 04:55:42 PM Terry Zink wrote: > Microsoft already does what is in the spec in Office 365 (which they > specifically call out in the draft), so eventually Hotmail/Outlook.co= m will > inherit it. But there are two differences: =20 > 1. Office 365 stamps "dmarc=3Dbestguesspass", not "dmarc=3Dpass". Tha= t makes it > easier to distinguish in the logs 2. We do relaxed alignment, not strict > alignment like it says in the spec=20 > Seems to work just fine. >=20 > Also, not sure why there would be a discussion of rua and ruf. It's > straightforward to interpolate the virtual DMARC record but how can y= ou > interpolate where to send a failure report? =20 > --Terry >=20 > -----Original Message----- > From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Kouji Okada > Sent: Friday, March 24, 2017 2:19 AM > To: dmarc > Cc: Kouji Okada > Subject: [dmarc-ietf] updating draft-akagiri-dmarc-virtual-verificati= on >=20 > Folks >=20 > We are now working on revising draft-akagiri-dmarc-virtual-verificati= on. > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fda= tatracker > .ietf.org%2Fdoc%2Fhtml%2Fdraft-akagiri-dmarc-virtual-verification&dat= a=3D02%7C > 01%7Ctzink%40microsoft.com%7C75cd5739368a40ce682208d47296da95%7C72f98= 8bf86f1 > 41af91ab2d7cd011db47%7C1%7C0%7C636259439620932357&sdata=3DlDAi6TjldCX= ogGZlQI1V > pLfYOya3fjaJPRn8mtBgo1U%3D&reserved=3D0 =20 > We are going to submit new version in early April. > Authors are recognizing there are some open issues for the draft. >=20 > 1. The authentication code. >=20 > In the draft, we suggest to mark =E2=80=9Cdmarc=3Dpass=E2=80=9D in th= e authentication result > when the virtual dmarc verifications have passed. We are going to keep it > as it is. >=20 > In 02, we are going to mention that e-mail operators can add comments= to the > authentication result field to indicate the =E2=80=9Cpass=E2=80=9D is= marked by the virtual > verification. We are not going to define the format of the comments, but > the example comment would be like below.=20 > ex) dmarc=3Dpass(vdmarc=3Dtrue) >=20 > 2. vdmarc=3Dfail problem >=20 > When submitting 00 version of the draft, some people gave us the comm= ents > that it is harmful to mark =E2=80=9Cdmarc=3Dfail=E2=80=9D without exp= licit declaration of > policy records. Our intention is to utilize the authentication results of > =E2=80=9Cdmarc=3Dpass=E2=80=9D for the e-mails potentially can be tre= ated as so. >=20 > As Takehito posted to this ML, > our evaluation on Japanese ISPs showed > more than 20% of received email traffic can be treated as "dmarc=3Dpa= ss" with > our verification. Thus our proposal helps to increase the number of > legitimate e-mails on the receiver side.=20 > =E2=80=9CStatistics about effects of =E2=80=9CVirtual DMARC=E2=80=9D=E2= =80=9D: > =20 > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= w.vdmarc > .dmarc.jp%2F%3Fp%3D122&data=3D02%7C01%7Ctzink%40microsoft.com%7C75cd5= 739368a40 > ce682208d47296da95%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63625= 9439620 > 942364&sdata=3DmVyeZ5EMI6cj1pvUXVYinZZi64JLqjE9v90iCUwiJ4M%3D&reserve= d=3D0 =20 > We are going to emphasize the point in 02. >=20 > 3. rua, ruf >=20 > We do not define any default report destinations for the virtual > verification. =20 > 4. Draft tile >=20 > Currently our draft title is =E2=80=9CDMARC verification without reco= rd > definitions(dmarc-virtual-verification)=E2=80=9D. Would you have any suggestions > for the title? >=20 >=20 > Any comments will be appreciated. >=20 > Thank you, > Kouji Okada >=20 >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= w.ietf.or > g%2Fmailman%2Flistinfo%2Fdmarc&data=3D02%7C01%7Ctzink%40microsoft.com= %7C75cd57 > 39368a40ce682208d47296da95%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0= %7C6362 > 59439620942364&sdata=3DAeIU1ls97f%2FktoX0ZuTufv1xDE0Q8%2FTAq%2BGpK8g9= MvE%3D&re > served=3D0 _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Sun Mar 26 15:23:55 2017 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 366331286CA for ; Sun, 26 Mar 2017 15:23:53 -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 (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yP36x_7nZKNw for ; Sun, 26 Mar 2017 15:23:50 -0700 (PDT) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::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 2AFA6126BF6 for ; Sun, 26 Mar 2017 15:23:49 -0700 (PDT) Received: by mail-wr0-x22b.google.com with SMTP id w43so19877600wrb.0 for ; Sun, 26 Mar 2017 15:23:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7mfjJJ5hiNp3d3aM+TEm2pe+P0nbudewSnAEsFFK/1o=; b=OWnR4My0/F4f3x+ChYeOnZ3bLnAxTsmHrlylDMfT/wS8xLFu8H1Hj/3GBcczdR8r2O S5KxE0BkAqXAxEiESzi/4w76ntu/Ye4AOzU8AV1lEBEsNPGL2Pmp1rR+JMEmvzr5UTfV YGCbRdxPM8irqTt/ydanZVpQHAxDQYTHVeoTxAI9Ox2X88ZPzPkOrNAFDtZTlONKIb2t cE6o4+Ec/MUu+KoF3xPvRczqxz9cfF7MhmtfFZXSfJF2eNDFi0lFz1btw1xW2TXmSdh0 e1SrtkXBlw2p6NFMx2HYAy/opnwFclO3owHBQGcj9dlS7XGfcPnnR/LugLeQ8rGqM2Hd uUwQ== 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=7mfjJJ5hiNp3d3aM+TEm2pe+P0nbudewSnAEsFFK/1o=; b=hcDXDVRw2MqfM4zA74Q1E/1IWdaWGeCWJUr66FpIFjDBExFbx5UmMNpZABFU9Cfv8L F+W76htNwjwPHY5V6Y7ulFrALfJAUaeZQCqEUwVVsAz3PjBihkqCyp5LPldz4pH31IXJ XaPTvPQpXO2SGeQOz+wr4JG6K1yO7fhhoZSIWMnqsagBgJn6DhsaNSHRVzK43zYYnKtT CL4yzdhtGG2CSVxmu+mc9CbWxIAyyczyJmTPqqcBmUhD328jnSLct6FKYpmVb/+0FauV qXIWZZK0M/Ub00yNiI9LmLc9xd6yhp/DWK1FBfEJwdl7n/02Qcmby2vIgszlGlPgQ4co MY5Q== X-Gm-Message-State: AFeK/H13uULJ/emzNKhJhsB0cADpxNL+2oBHI0gkaPhtaLjX7dAE0UFADV5BiS9i6rSY0RReGZ3ERRKuPlfSCw== X-Received: by 10.223.160.183 with SMTP id m52mr444798wrm.201.1490567028424; Sun, 26 Mar 2017 15:23:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.142.130 with HTTP; Sun, 26 Mar 2017 15:23:47 -0700 (PDT) In-Reply-To: <20170324212304.85346.qmail@ary.lan> References: <20170324212304.85346.qmail@ary.lan> From: Gene Shuman Date: Sun, 26 Mar 2017 15:23:47 -0700 Message-ID: To: John Levine Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary=94eb2c05eb3e3e5559054ba9ae12 Archived-At: Subject: Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 26 Mar 2017 22:23:53 -0000 --94eb2c05eb3e3e5559054ba9ae12 Content-Type: text/plain; charset=UTF-8 Ah that had slipped my mind & is a good point. However, I think the issue here is generally that ARC is more complex protocol than DKIM and therefore it's more important to reduce ambiguity & increase standardization while we have the chance. I think this is generally a good idea from a security perspective, however this is mostly relevant with respect to testing & validation, as ensuring cross-compatibility is a much bigger challenge. It's even more important than it was with DKIM to have a test suite that can verify signing behavior. If we don't agree on any sort of standard, a test suite will need to select a preferred format for the ARC headers & will fail all implementations that don't meet this form. We've discussed this with Murray, and he agrees with this conclusion. Our belief is that, given this is a new standard and all of the implementors are on this list, it makes the most sense to define the tag/value behavior strictly in the RFC. Thoughts? On Fri, Mar 24, 2017 at 2:23 PM, John Levine wrote: > In article 5uRfA@mail.gmail.com> you write: > >The issue is that its possible for two separate arc implementations, given > >the exact same message inputs, keys, timestamps, etc to be generating two > >different, but equally valid ARC seal hashes. > > DKIM does the same thing. The order of fields in a DKIM-Signature > header is arbitrary, and the b= hash includes that header, so there > are lots of different equivalent DKIM signatures for the same message > and same selector and key. Verifiers use the DKIM-Signature header in > the message so they get the same answer as the signer, which I would > think would work the same way in ARC-Seal. > > Can you explain why you think this is a problem? > > R's, > John > --94eb2c05eb3e3e5559054ba9ae12 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ah that had slipped my mind & is a good point.=C2=A0 H= owever, I think the issue here is generally that ARC is more complex protoc= ol than DKIM and therefore it's more important to reduce ambiguity &= ; increase standardization while we have the chance.=C2=A0 I think this is = generally a good idea from a security perspective, however this is mostly r= elevant with respect to testing & validation, as ensuring cross-compati= bility is a much bigger challenge.=C2=A0 It's even more important than = it was with DKIM to have a test suite that can verify signing behavior.=C2= =A0 If we don't agree on any sort of standard, a test suite will need t= o select a preferred format for the ARC headers & will fail all impleme= ntations that don't meet this form.=C2=A0 We've discussed this with= Murray, and he agrees with this conclusion.

O= ur belief is that, given this is a new standard and all of the implementors= are on this list, it makes the most sense to define the tag/value behavior= strictly in the RFC.

Thoughts? = =C2=A0

On Fri, Mar 24, 2017 at 2:23 PM, John Levine <johnl@taugh.com> wrote:
In article <= CANtLugO_D1Mz_v_341pc5O1mZ7RhOTrFA3+Ob5-onp72+5uRf= A@mail.gmail.com> you write:
>The issue is that its possible for two separate arc implementations, gi= ven
>the exact same message inputs, keys, timestamps, etc to be generating t= wo
>different, but equally valid ARC seal hashes.

DKIM does the same thing.=C2=A0 The order of fields in a DKIM-Signat= ure
header is arbitrary, and the b=3D hash includes that header, so there
are lots of different equivalent DKIM signatures for the same message
and same selector and key.=C2=A0 Verifiers use the DKIM-Signature header in=
the message so they get the same answer as the signer, which I would
think would work the same way in ARC-Seal.

Can you explain why you think this is a problem?

R's,
John

--94eb2c05eb3e3e5559054ba9ae12-- From nobody Sun Mar 26 19:32:45 2017 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 98976128BB7 for ; Sun, 26 Mar 2017 19:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=bBq6ZZjX; dkim=pass (1536-bit key) header.d=taugh.com header.b=aOQWwirX 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 vCrHNroRenbm for ; Sun, 26 Mar 2017 19:32:42 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E370012778D for ; Sun, 26 Mar 2017 19:32:41 -0700 (PDT) Received: (qmail 90295 invoked from network); 27 Mar 2017 02:32:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=160b5.58d879c8.k1703; bh=RQEYckATQTPtiPIxSbtpqNa46LUfNhCinJFCPW4a8zY=; b=bBq6ZZjXdGL+qE1ip4QWqnyb+Ug99yVsltcFZ+T1dA+XL4jkuSiDtuBFYECENbmTLPW975oSJ6Hr6kidXyx4e9wh0R4fDfD6hdXvkQcHRTmfkg6JLlUibeh0nZJJLwhLlwIeNpEwLiRaZPljwQWzACY/dRLjb6LUt4MXQ0No7kUylnFmFXRAtMGcOKBuESxoxpCyC5HUoI7GUqd2e+aPLxmwlp/80UZJmTHWe6U2z+5CCtfUGYAMpsPt1HfErcOF DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=160b5.58d879c8.k1703; bh=RQEYckATQTPtiPIxSbtpqNa46LUfNhCinJFCPW4a8zY=; b=aOQWwirXDbbb2ws9STl2Jqu43cM1ydN87XmkzlaudkmLKa5F/UG8XAYPPmDguOwBxvbFVURGGM7R4ZAWl6L6PtF43kQyAlVw4wcJ5W/JtcrsLC7YqCz7a2ATy4WJZ6NOfrJBcGn9rz1wPgoc/317Kk4FVVH7EOYIkQhzbBQcktIY6tyNFPZtXPxy7XX8la0JgnQO58SReEEoRGl7qj4IeDkkHZkVmRFBlMhav2XTZOzGQyYK4F4Pqm7GTOg3ymXP Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 27 Mar 2017 02:32:40 -0000 Date: 26 Mar 2017 21:32:40 -0500 Message-ID: From: "John R Levine" To: "Gene Shuman" Cc: dmarc@ietf.org In-Reply-To: References: <20170324212304.85346.qmail@ary.lan> User-Agent: Alpine 2.20 (OSX 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 27 Mar 2017 02:32:43 -0000 > It's even more important than it was with DKIM to have a test suite that > can verify signing behavior. If we don't agree on any sort of standard, a > test suite will need to select a preferred format for the ARC headers & > will fail all implementations that don't meet this form. We've discussed > this with Murray, and he agrees with this conclusion. I have to say I don't find that very persuasive. It's not hard to write test code that checks for the hashes and fields in a signature header without regard to what order they're in. I would rather write better test code than add fragile extra cruft to every ARC implementation. As it happens, the IETF is meeting this week in Chicago, and I expect I'll see Murray in the next day or two so I can talk to him directly. R's, John From nobody Sun Mar 26 21:26:05 2017 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 0FB381276AF for ; Sun, 26 Mar 2017 21:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.718 X-Spam-Level: X-Spam-Status: No, score=-1.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcRCW9P4yUeX for ; Sun, 26 Mar 2017 21:26:00 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE9DB1292D0 for ; Sun, 26 Mar 2017 21:25:56 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id f11so28922665qkb.0 for ; Sun, 26 Mar 2017 21:25:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uADX4LJA32miQ+TSu8+6yPUJiwxpCLTRrbpGmdL3Q9g=; b=LZArxiuMHUDP3N3C7BYDQoT9evHSBSYkpEKtv0DAb5cRcBYTVGPUIbAreCKrbXCF8+ CNBn4gCh2BzVUIEGr4rwY199j045RoqEAVtFdsHL3Q9sE2Ha+QbSGswPlm0Td1x1GIcJ NKFAW0XJZzyGLtK7RhLroP3/rgUXg3rfN1cTXATaeXOBqTfDfcBYerMw89EuS7odD8Ix x915Qwa6r45tGampJ7eomEfVINp8sabcDKyQXWTd5cy6MZXH4yeocZhI6PqFZJw+d3X0 6yk4+1zWIMrVapAX425PvibNUaNr35OjfbI6HpHa6ncX0B2EJ7r6BFL80NQg/AsnYg2/ V2Gw== 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=uADX4LJA32miQ+TSu8+6yPUJiwxpCLTRrbpGmdL3Q9g=; b=fldux4DrQA/htqqMBKKQMn8GcfIn3CocbX0clz5dDU030ER5EPmVGrVmsWJ/Mr4bPh ciVihGLLmNNmo5QB4Eh6STMzbk7rEK1J21tSOvV7aCEUm5y389Xna96PbUJhufMekV15 fgh8AM0Lo/buTQC4c7J7tYFdr75q5v57yI/RfiOr3RylNcC9uZnuI+IcnEVr4q4pbNOO /HEGb+Kd1lQR91Wmy35JNiSInB2F/Gnjm2ya9OKD2zCZvT/3nxqjRL61pbAWgv+Wmtkg QGX67lCwQFB2mwicL0CbT5Y64Cn7G/1KvSwt2vYrFvUbzvO77aUQFuajoCWluqr+y6zA Qf1Q== X-Gm-Message-State: AFeK/H0ba9LDNVq2YYTPb8/yFpLs4Pn+FYnF9EerUWt8S4dSDPIm6oZ2ICtF3SB1+cBj+fSBInZ0wyh1OzrtIg== X-Received: by 10.55.170.143 with SMTP id t137mr17374768qke.303.1490588755669; Sun, 26 Mar 2017 21:25:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.141.207 with HTTP; Sun, 26 Mar 2017 21:25:55 -0700 (PDT) In-Reply-To: References: <20170324212304.85346.qmail@ary.lan> From: Peter Goldstein Date: Sun, 26 Mar 2017 21:25:55 -0700 Message-ID: To: John R Levine Cc: Gene Shuman , dmarc Content-Type: multipart/alternative; boundary=94eb2c05d99a49d290054baebd62 Archived-At: Subject: Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 27 Mar 2017 04:26:04 -0000 --94eb2c05d99a49d290054baebd62 Content-Type: text/plain; charset=UTF-8 John, > I have to say I don't find that very persuasive. It's not hard to write > test code that checks for the hashes and fields in a signature header > without regard to what order they're in. I would rather write better test > code than add fragile extra cruft to every ARC implementation. I honestly find this response a little unpersuasive :). There are two points I'd like to raise. First, the idea that locking down the format of the signature adds 'fragile extra cruft' seems off to me. On the contrary, the suggestions in this thread reduce fragility - by requiring that the set of signed fields (ARC Message Signatures, ARC Seals) meet a well-defined, strict, and trivially verifiable format. This is fairly standard practice in video, security, etc. protocols - every field has a place, and large scale re-ordering/re-formatting is not permitted unless there's a compelling technical reason. I'm not sure why there's a perceived value in accommodating ambiguity here - this is a brand new standard with a limited number of actual implementers. There's no random person not on this list implementing ARC (especially given the standard isn't finalized). And if there is, the whole idea of providing a globally usable automated test suite is to ensure that person can easily validate that their implementation will interoperate. Second, the premise that "it's not hard to write test code..." is simply not true. What would be required to actually write such code would be either a) pick a preferred ordering/formatting for these tags, and only have the tests pass for that ordering or b) include a complete ARC verifying system in the test code. The first is what OpenDKIM did for its specs (see below). The latter is possible, but seems ill-advised for a test suite. To see that this is the case, it's useful to look at two earlier email standards and their corresponding test suites. SPF has a language-agnostic test suite (http://www.openspf.org/Test_Suite) that makes it easy to test implementations in any language. I've done it myself, and it requires minimal effort - https://github.com/ValiMail/coppertone/tree/master/spec/ open_spf. I can tell you from personal experience that the test suite was really helpful in ensuring the implementation was correct in all cases. There is no corresponding test suite for DKIM, and the ambiguity in tag/value ordering is the fundamental reason why. The closest we come are the tests for OpenDKIM. If you examine the signing tests for OpenDKIM, it's clear that they fail your "not hard" requirement. I can write a perfectly valid, legal DKIM signing implementation that will fail all of OpenDKIM's signing tests, because OpenDKIM has a preferred ordering and formatting for tags. The OpenDKIM signing tests all check that OpenDKIM produces a signature header matching a constant string that embodies this preferred ordering. Any implementation that uses a different ordering/formatting will obviously fail. Changing the tag ordering/formatting changes the hashed value in the header, so it's not just a matter of parsing some tag/value pairs. And so short of a full DKIM verification implementation it's impossible to make a generic test suite that accepts all legal implementations. Frankly, this is somewhat unfortunate. But DKIM is a relatively simple protocol. ARC is more complicated, with multiple levels of signatures and more complex state. Given the substantially more complicated nature of ARC, it's desirable to have a test suite that will pass any legal implementation. Interops are great, but I'd take a bulletproof test suite over an interop any day of the week. I won't be at the IETF meeting this week, but I'd be happy to dive into this in more detail over email or phone if it's helpful. Best, Peter On Sun, Mar 26, 2017 at 7:32 PM, John R Levine wrote: > It's even more important than it was with DKIM to have a test suite that >> can verify signing behavior. If we don't agree on any sort of standard, a >> test suite will need to select a preferred format for the ARC headers & >> will fail all implementations that don't meet this form. We've discussed >> this with Murray, and he agrees with this conclusion. >> > > I have to say I don't find that very persuasive. It's not hard to write > test code that checks for the hashes and fields in a signature header > without regard to what order they're in. I would rather write better test > code than add fragile extra cruft to every ARC implementation. > > As it happens, the IETF is meeting this week in Chicago, and I expect I'll > see Murray in the next day or two so I can talk to him directly. > > > R's, > John > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- [image: logo for sig file.png] Bringing Trust to Email Peter Goldstein | CTO & Co-Founder peter@valimail.com +1.415.793.5783 <(415)%20793-5783> --94eb2c05d99a49d290054baebd62 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
John,
=C2=A0
I have to say I d= on't find that very persuasive.=C2=A0 It's not hard to write test c= ode that checks for the hashes and fields in a signature header without reg= ard to what order they're in.=C2=A0 I would rather write better test co= de than add fragile extra cruft to every ARC implementation.

I hone= stly find this response a little unpersuasive =C2=A0:).=C2=A0 There are two= points I'd like to raise.

First, the idea that locking down the format o= f the signature adds 'fragile extra cruft' seems off to me.=C2=A0 O= n the contrary, the suggestions in this thread reduce fragility - by requir= ing that the set of signed fields (ARC Message Signatures, ARC Seals) meet = a well-defined, strict, and trivially verifiable format.=C2=A0 This is fair= ly standard practice in video, security, etc. protocols - every field has a= place, and large scale re-ordering/re-formatting is not permitted unless t= here's a compelling technical reason.=C2=A0

I'm not sure why there's = a perceived value in accommodating ambiguity here - this is a brand new sta= ndard with a limited number of actual implementers.=C2=A0 There's no ra= ndom person not on this list implementing ARC (especially given the standar= d isn't finalized).=C2=A0 And if there is, the whole idea of providing = a globally usable automated test suite is to ensure that person can easily = validate that their implementation will interoperate.

Second, the premise that &q= uot;it's not hard to write test code..." is simply not true.=C2=A0= What would be required to actually write such code would be either a) pick= a preferred ordering/formatting for these tags, and only have the tests pa= ss for that ordering or b) include a complete ARC verifying system in the t= est code.=C2=A0 The first is what OpenDKIM did for its specs (see below).= =C2=A0 The latter is possible, but seems ill-advised for a test suite.

To see tha= t this is the case, it's useful to look at two earlier email standards = and their corresponding test suites.=C2=A0 SPF has a language-agnostic test= suite (htt= p://www.openspf.org/Test_Suite) that makes it easy to test impleme= ntations in any language.=C2=A0 I've done it myself, and it requires mi= nimal effort -=C2=A0https://github.com/ValiMail/co= ppertone/tree/master/spec/open_spf.=C2=A0 I can tell you from pers= onal experience that the test suite was really helpful in ensuring the impl= ementation was correct in all cases.

There is no corresponding test suite for DKI= M, and the ambiguity in tag/value ordering is the fundamental reason why.= =C2=A0 The closest we come are the tests for OpenDKIM.=C2=A0 If you examine= the signing tests for OpenDKIM, it's clear that they fail your "n= ot hard" requirement.=C2=A0 I can write a perfectly valid, legal DKIM = signing implementation that will fail all of OpenDKIM's signing tests, = because OpenDKIM has a preferred ordering and formatting for tags.

The OpenDKIM s= igning tests all check that OpenDKIM produces a signature header matching a= constant string that embodies this preferred ordering.=C2=A0 Any implement= ation that uses a different ordering/formatting will obviously fail.=C2=A0 = Changing the tag ordering/formatting changes the hashed value in the header= , so it's not just a matter of parsing some tag/value pairs.=C2=A0 And = so short of a full DKIM verification implementation it's impossible to = make a generic test suite that accepts all legal implementations.

Frankly, this i= s somewhat unfortunate.=C2=A0 But DKIM is a relatively simple protocol.=C2= =A0 ARC is more complicated, with multiple levels of signatures and more co= mplex state.=C2=A0 Given the substantially more complicated nature of ARC, = it's desirable to have a test suite that will pass any legal implementa= tion.=C2=A0 Interops are great, but I'd take a bulletproof test suite o= ver an interop any day of the week.
I won't be at the IETF meeting this w= eek, but I'd be happy to dive into this in more detail over email or ph= one if it's helpful.

Best,

Peter

On Sun, Mar 26, 2017 at 7:32 PM, John R Levine <johnl@taugh.com= > wrote:
It's even more important than it was with DKIM to have a test suite tha= t
can verify signing behavior.=C2=A0 If we don't agree on any sort of sta= ndard, a
test suite will need to select a preferred format for the ARC headers &=
will fail all implementations that don't meet this form.=C2=A0 We'v= e discussed
this with Murray, and he agrees with this conclusion.

 I have to say I don't find that very persuasive.=C2=A0 It's not har= d to write test code that checks for the hashes and fields in a signature h= eader without regard to what order they're in.=C2=A0 I would rather wri= te better test code than add fragile extra cruft to every ARC implementatio= n.

As it happens, the IETF is meeting this week in Chicago, and I expect I'= ;ll see Murray in the next day or two so I can talk to him directly.


R's,
John

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



--
=


3D"logo

Bringing Trust to Email

Peter Goldstein | CTO & Co-Founder

peter@valimail.com

+1.415.793.5783
=
--94eb2c05d99a49d290054baebd62-- From nobody Mon Mar 27 11:06:30 2017 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 22B16129445 for ; Mon, 27 Mar 2017 11:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Bjmt2CBHwYUF for ; Mon, 27 Mar 2017 11:06:26 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::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 C175A12949F for ; Mon, 27 Mar 2017 11:06:23 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id d191so37361857ywe.2 for ; Mon, 27 Mar 2017 11:06:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=28SFU7uVe2pquufdRMls/5kTPnBO//1FBDHq7eEPBdY=; b=rSeAgJ2Jlp4rXD2+T2zXhPlO4RLBh5nw9tgwhB2rjCPVLSM+AJjzTVY4Sk+dCmdQ8k SHLWGKWhl+EuNtWk1NvcJbnKH0ydTp5AEVwJPed1qTKZ/AHOrpoYmmpaYLhF8mCpXTiH q7NZhrBHgls6hRhVOZY3+9mq/+3amOapKBa6bLuhMrqiFgaIgA83/OU9PGJ0LYoQ2nD5 oCRjvJO7tGArpDS9bxHRNLp+VIoixieKm8m47tODJJG8/HVYwhsZF+OsxBd6tRLQPJXv g35aXjafO6pZes7pwLqAS+IitMq1FHMgUvVQZELLkRil4JfOqhDUtZbk8OyZBx86F0OU 8Axg== 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=28SFU7uVe2pquufdRMls/5kTPnBO//1FBDHq7eEPBdY=; b=YZ9O1eR+0o2sehOmmrZQEGZ/cSlSvwNJHEz3hC1fMViFJl1j6H2oFu8epCAl47rLyF N9DMpsjS001iVcD5vFjQUVWeHmKqvZE4Meq8ioi5I1SzWyBUYQJZQ027mfU8ONUMVkAK uTVSVh9sZZ3v/FQ7jSZEfL5ebTg7bC+f8W6Jhd9KKFO4lGC2FeIRGNaUNaehgtZ9y4uC ENHuVkcjuNkGALZAFdB1yGDD0/5NSAeOWHrFr1nNm5icrDv4ct97PQxdvcQ/ciXlGXHN n8ZVnCIOE8lt3UdhrzwOBjVl+kz3+Jg4UzltxfN+1rJdIs1ayAxZU6gyu34F91OcmHGk B8HA== X-Gm-Message-State: AFeK/H2cZiMSZwrG4qcapzErsrPR/r9hkd/LTCXAb67eETxoFxZkFwhKBQHgDlalJoFRV6+ttLsqdijZCPLsnAWn X-Received: by 10.37.39.130 with SMTP id n124mr16764065ybn.127.1490637982546; Mon, 27 Mar 2017 11:06:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.220.11 with HTTP; Mon, 27 Mar 2017 11:06:20 -0700 (PDT) Received: by 10.37.220.11 with HTTP; Mon, 27 Mar 2017 11:06:20 -0700 (PDT) In-Reply-To: References: <20170324212304.85346.qmail@ary.lan> From: Brandon Long Date: Mon, 27 Mar 2017 11:06:20 -0700 Message-ID: To: Peter Goldstein Cc: dmarc@ietf.org, Gene Shuman , John R Levine Content-Type: multipart/alternative; boundary=94eb2c134fd470c445054bba337a Archived-At: Subject: Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 27 Mar 2017 18:06:29 -0000 --94eb2c134fd470c445054bba337a Content-Type: text/plain; charset=UTF-8 What does validating the exact signature generated benefit us over just verifying that the signature verifies? I haven't looked at what the tests are for signing, though given the descriptions for the verifying tests, I'm not sure it would be obvious. Can you summarize them? Brandon On Mar 26, 2017 9:26 PM, "Peter Goldstein" wrote: > John, > > >> I have to say I don't find that very persuasive. It's not hard to write >> test code that checks for the hashes and fields in a signature header >> without regard to what order they're in. I would rather write better test >> code than add fragile extra cruft to every ARC implementation. > > > I honestly find this response a little unpersuasive :). There are two > points I'd like to raise. > > First, the idea that locking down the format of the signature adds > 'fragile extra cruft' seems off to me. On the contrary, the suggestions in > this thread reduce fragility - by requiring that the set of signed fields > (ARC Message Signatures, ARC Seals) meet a well-defined, strict, and > trivially verifiable format. This is fairly standard practice in video, > security, etc. protocols - every field has a place, and large scale > re-ordering/re-formatting is not permitted unless there's a compelling > technical reason. > > I'm not sure why there's a perceived value in accommodating ambiguity here > - this is a brand new standard with a limited number of actual > implementers. There's no random person not on this list implementing ARC > (especially given the standard isn't finalized). And if there is, the > whole idea of providing a globally usable automated test suite is to ensure > that person can easily validate that their implementation will interoperate. > > Second, the premise that "it's not hard to write test code..." is simply > not true. What would be required to actually write such code would be > either a) pick a preferred ordering/formatting for these tags, and only > have the tests pass for that ordering or b) include a complete ARC > verifying system in the test code. The first is what OpenDKIM did for its > specs (see below). The latter is possible, but seems ill-advised for a > test suite. > > To see that this is the case, it's useful to look at two earlier email > standards and their corresponding test suites. SPF has a language-agnostic > test suite (http://www.openspf.org/Test_Suite) that makes it easy to test > implementations in any language. I've done it myself, and it requires > minimal effort - https://github.com/ValiMail/ > coppertone/tree/master/spec/open_spf. I can tell you from personal > experience that the test suite was really helpful in ensuring the > implementation was correct in all cases. > > There is no corresponding test suite for DKIM, and the ambiguity in > tag/value ordering is the fundamental reason why. The closest we come are > the tests for OpenDKIM. If you examine the signing tests for OpenDKIM, > it's clear that they fail your "not hard" requirement. I can write a > perfectly valid, legal DKIM signing implementation that will fail all of > OpenDKIM's signing tests, because OpenDKIM has a preferred ordering and > formatting for tags. > > The OpenDKIM signing tests all check that OpenDKIM produces a signature > header matching a constant string that embodies this preferred ordering. > Any implementation that uses a different ordering/formatting will obviously > fail. Changing the tag ordering/formatting changes the hashed value in the > header, so it's not just a matter of parsing some tag/value pairs. And so > short of a full DKIM verification implementation it's impossible to make a > generic test suite that accepts all legal implementations. > > Frankly, this is somewhat unfortunate. But DKIM is a relatively simple > protocol. ARC is more complicated, with multiple levels of signatures and > more complex state. Given the substantially more complicated nature of > ARC, it's desirable to have a test suite that will pass any legal > implementation. Interops are great, but I'd take a bulletproof test suite > over an interop any day of the week. > > I won't be at the IETF meeting this week, but I'd be happy to dive into > this in more detail over email or phone if it's helpful. > > Best, > > Peter > > On Sun, Mar 26, 2017 at 7:32 PM, John R Levine wrote: > >> It's even more important than it was with DKIM to have a test suite that >>> can verify signing behavior. If we don't agree on any sort of standard, >>> a >>> test suite will need to select a preferred format for the ARC headers & >>> will fail all implementations that don't meet this form. We've discussed >>> this with Murray, and he agrees with this conclusion. >>> >> >> I have to say I don't find that very persuasive. It's not hard to write >> test code that checks for the hashes and fields in a signature header >> without regard to what order they're in. I would rather write better test >> code than add fragile extra cruft to every ARC implementation. >> >> As it happens, the IETF is meeting this week in Chicago, and I expect >> I'll see Murray in the next day or two so I can talk to him directly. >> >> >> R's, >> John >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > > > > -- > > > [image: logo for sig file.png] > > Bringing Trust to Email > > Peter Goldstein | CTO & Co-Founder > > peter@valimail.com > +1.415.793.5783 <(415)%20793-5783> > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --94eb2c134fd470c445054bba337a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
What does validating the exact signature generated benefi= t us over just verifying that the signature verifies?

=
I haven't looked at what the tests are for sign= ing, though given the descriptions =C2=A0for the verifying tests, I'm n= ot sure it would be obvious.=C2=A0 Can you summarize them?

Brandon

On Mar 26, 2017 9:26 PM, "Pet= er Goldstein" <peter@valimail= .com> wrote:
=
John,
=C2=A0
I have to say I d= on't find that very persuasive.=C2=A0 It's not hard to write test c= ode that checks for the hashes and fields in a signature header without reg= ard to what order they're in.=C2=A0 I would rather write better test co= de than add fragile extra cruft to every ARC implementation.

I hone= stly find this response a little unpersuasive =C2=A0:).=C2=A0 There are two= points I'd like to raise.

First, the idea that locking down the format o= f the signature adds 'fragile extra cruft' seems off to me.=C2=A0 O= n the contrary, the suggestions in this thread reduce fragility - by requir= ing that the set of signed fields (ARC Message Signatures, ARC Seals) meet = a well-defined, strict, and trivially verifiable format.=C2=A0 This is fair= ly standard practice in video, security, etc. protocols - every field has a= place, and large scale re-ordering/re-formatting is not permitted unless t= here's a compelling technical reason.=C2=A0

I'm not sure why there's = a perceived value in accommodating ambiguity here - this is a brand new sta= ndard with a limited number of actual implementers.=C2=A0 There's no ra= ndom person not on this list implementing ARC (especially given the standar= d isn't finalized).=C2=A0 And if there is, the whole idea of providing = a globally usable automated test suite is to ensure that person can easily = validate that their implementation will interoperate.

Second, the premise that &q= uot;it's not hard to write test code..." is simply not true.=C2=A0= What would be required to actually write such code would be either a) pick= a preferred ordering/formatting for these tags, and only have the tests pa= ss for that ordering or b) include a complete ARC verifying system in the t= est code.=C2=A0 The first is what OpenDKIM did for its specs (see below).= =C2=A0 The latter is possible, but seems ill-advised for a test suite.

To see tha= t this is the case, it's useful to look at two earlier email standards = and their corresponding test suites.=C2=A0 SPF has a language-agnostic test= suite (htt= p://www.openspf.org/Test_Suite) that makes it easy to test impleme= ntations in any language.=C2=A0 I've done it myself, and it requires mi= nimal effort -=C2=A0https://github.com/ValiMail/co= ppertone/tree/master/spec/open_spf.=C2=A0 I can tell you from pers= onal experience that the test suite was really helpful in ensuring the impl= ementation was correct in all cases.

There is no corresponding test suite for DKI= M, and the ambiguity in tag/value ordering is the fundamental reason why.= =C2=A0 The closest we come are the tests for OpenDKIM.=C2=A0 If you examine= the signing tests for OpenDKIM, it's clear that they fail your "n= ot hard" requirement.=C2=A0 I can write a perfectly valid, legal DKIM = signing implementation that will fail all of OpenDKIM's signing tests, = because OpenDKIM has a preferred ordering and formatting for tags.

The OpenDKIM s= igning tests all check that OpenDKIM produces a signature header matching a= constant string that embodies this preferred ordering.=C2=A0 Any implement= ation that uses a different ordering/formatting will obviously fail.=C2=A0 = Changing the tag ordering/formatting changes the hashed value in the header= , so it's not just a matter of parsing some tag/value pairs.=C2=A0 And = so short of a full DKIM verification implementation it's impossible to = make a generic test suite that accepts all legal implementations.

Frankly, this i= s somewhat unfortunate.=C2=A0 But DKIM is a relatively simple protocol.=C2= =A0 ARC is more complicated, with multiple levels of signatures and more co= mplex state.=C2=A0 Given the substantially more complicated nature of ARC, = it's desirable to have a test suite that will pass any legal implementa= tion.=C2=A0 Interops are great, but I'd take a bulletproof test suite o= ver an interop any day of the week.
I won't be at the IETF meeting this w= eek, but I'd be happy to dive into this in more detail over email or ph= one if it's helpful.

Best,

Peter

On Sun, Mar 26, 2017 at 7:32 PM, John R Levine <johnl@taugh.com= > wrote:
It's even more important than it was with DKIM to have a test suite tha= t
can verify signing behavior.=C2=A0 If we don't agree on any sort of sta= ndard, a
test suite will need to select a preferred format for the ARC headers &=
will fail all implementations that don't meet this form.=C2=A0 We'v= e discussed
this with Murray, and he agrees with this conclusion.

 I have to say I don't find that very persuasive.=C2=A0 It's not har= d to write test code that checks for the hashes and fields in a signature h= eader without regard to what order they're in.=C2=A0 I would rather wri= te better test code than add fragile extra cruft to every ARC implementatio= n.

As it happens, the IETF is meeting this week in Chicago, and I expect I'= ;ll see Murray in the next day or two so I can talk to him directly.



--
=


= 3D"logo

Bringing Trust to Email

Peter Goldstein | CTO & Co-Foun= der

peter@valimail.com

+1.415.793.5783
<= /div>

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

--94eb2c134fd470c445054bba337a-- From nobody Mon Mar 27 12:03:32 2017 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 5E0B312957D for ; Mon, 27 Mar 2017 12:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.718 X-Spam-Level: X-Spam-Status: No, score=-1.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekldKdfkKkhE for ; Mon, 27 Mar 2017 12:03:26 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 663E11294D3 for ; Mon, 27 Mar 2017 12:02:48 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id d10so41298653qke.1 for ; Mon, 27 Mar 2017 12:02:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZobVofhniP3NAI3ekbSooQSRV8nXUkhOcWL3oP8aaek=; b=anzE4Tkfn2gLe9C0BFmWAtLXZQxu/gzlp4XLqqL/mRhaHTBPjgaehsW90XGO/xQIoO CgnkbV5VuOtdBt++S+UT/SNPKt5w4r3cYSwHepFu6LQb1pEvQ6pIxZUHfr3ApUy0VxKI OmYdJqHcf5Ls4H9kEg/TqV6maFFnZmlPdpkjxhGm3qq12tj38LPGLKNV28+QUh3tO2St yhCeZuCjsASTNDGnlUHAyvK8K6bUpdN1cME3LDKNWiZQiRrisHxjpo1vWQXHcPbhcUUs AFkLnTw4rOB1uNZb0+C2SdL6BFZRp3Q3BQJmfcn1PKb3nn71g1eRaa1dXn5gHfF4Pmwz RZXg== 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=ZobVofhniP3NAI3ekbSooQSRV8nXUkhOcWL3oP8aaek=; b=Ru7fw1cxkRk5XnzVpHddKDVv1XyZh7DvhhFLS6HIV9LjKUSxzhZ0RaieoUkQkK8YYz pFloW4X5gI/qO1oshwwrKq5afcPJLatkr4y3sbogOw4TmX+zFCkR+4PVTVUCd4Hsxb0Y bufgFlE6d2F01TMXVtSkUwZzbW40RdCIle5l4hBxBHv9M6dJ4HAxwNXnZDM1zX9X/Njk A6/rg8o+MMu95qbjOUXjseQRkoipScrNh2KgI3WVfnLylr64D/io7GN2NovbGIug1ptI sfD3gMLGJOgA8Yj7mKSeVrrnod3trW+bufM5rT8eG8pXDdR6rSxAfVoUmYqsLiKmrUQG Wu2w== X-Gm-Message-State: AFeK/H1xqkNPPusAi0ABq9a1K/p6bx7IGksXKGwHrD91NqpT536qRKwxGCfsi9xj1hAyDMsu7ptY5wlw9ukUCg== X-Received: by 10.55.214.26 with SMTP id t26mr15600475qki.16.1490641366551; Mon, 27 Mar 2017 12:02:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.141.207 with HTTP; Mon, 27 Mar 2017 12:02:46 -0700 (PDT) In-Reply-To: References: <20170324212304.85346.qmail@ary.lan> From: Peter Goldstein Date: Mon, 27 Mar 2017 12:02:46 -0700 Message-ID: To: Brandon Long Cc: dmarc , Gene Shuman , John R Levine Content-Type: multipart/alternative; boundary=001a1149dfbe248eca054bbafd6a Archived-At: Subject: Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 27 Mar 2017 19:03:30 -0000 --001a1149dfbe248eca054bbafd6a Content-Type: text/plain; charset=UTF-8 Brandon, How do you validate that the signature verifies? To do that you need an entire ARC implementation that is packaged within the test suite (and the ability for it to run as a service, or make it available in some way to implementations being tested that are written in different languages). That's the whole point. The tests under discussion are validating that with assorted inputs (original message, DNS configuration, etc.) an ARC implementation produces a valid output message (correct ARC seal, ARC chain, etc.). Essentially we're looking at testing that: SIGN(INPUTS) => OUTPUT MESSAGE With the canonicalization being proposed, the OUTPUT MESSAGE becomes a deterministic result, and verifying it becomes a matter of string comparison. This is the success criterion: OUTPUT MESSAGE == EXPECTED MESSAGE Without the canonicalization being proposed, it will be necessary to run verification on the OUTPUT MESSAGE to assess whether the test gives the expected results for a generic implementation. In that case this is the success criterion: ARC_VALIDATION(OUTPUT MESSAGE, INPUTS) == EXPECTED_ARC_STATE(INPUTS) We can't use the ARC validation implementation for the library under test, because it may share bugs with the signing side. Instead we'll need to have a bundled ARC validaiton with the test suite. Does that make sense? Best, Peter On Mon, Mar 27, 2017 at 11:06 AM, Brandon Long wrote: > What does validating the exact signature generated benefit us over just > verifying that the signature verifies? > > I haven't looked at what the tests are for signing, though given the > descriptions for the verifying tests, I'm not sure it would be obvious. > Can you summarize them? > > Brandon > > On Mar 26, 2017 9:26 PM, "Peter Goldstein" wrote: > >> John, >> >> >>> I have to say I don't find that very persuasive. It's not hard to write >>> test code that checks for the hashes and fields in a signature header >>> without regard to what order they're in. I would rather write better test >>> code than add fragile extra cruft to every ARC implementation. >> >> >> I honestly find this response a little unpersuasive :). There are two >> points I'd like to raise. >> >> First, the idea that locking down the format of the signature adds >> 'fragile extra cruft' seems off to me. On the contrary, the suggestions in >> this thread reduce fragility - by requiring that the set of signed fields >> (ARC Message Signatures, ARC Seals) meet a well-defined, strict, and >> trivially verifiable format. This is fairly standard practice in video, >> security, etc. protocols - every field has a place, and large scale >> re-ordering/re-formatting is not permitted unless there's a compelling >> technical reason. >> >> I'm not sure why there's a perceived value in accommodating ambiguity >> here - this is a brand new standard with a limited number of actual >> implementers. There's no random person not on this list implementing ARC >> (especially given the standard isn't finalized). And if there is, the >> whole idea of providing a globally usable automated test suite is to ensure >> that person can easily validate that their implementation will interoperate. >> >> Second, the premise that "it's not hard to write test code..." is simply >> not true. What would be required to actually write such code would be >> either a) pick a preferred ordering/formatting for these tags, and only >> have the tests pass for that ordering or b) include a complete ARC >> verifying system in the test code. The first is what OpenDKIM did for its >> specs (see below). The latter is possible, but seems ill-advised for a >> test suite. >> >> To see that this is the case, it's useful to look at two earlier email >> standards and their corresponding test suites. SPF has a language-agnostic >> test suite (http://www.openspf.org/Test_Suite) that makes it easy to >> test implementations in any language. I've done it myself, and it requires >> minimal effort - https://github.com/ValiMail/ >> coppertone/tree/master/spec/open_spf. I can tell you from personal >> experience that the test suite was really helpful in ensuring the >> implementation was correct in all cases. >> >> There is no corresponding test suite for DKIM, and the ambiguity in >> tag/value ordering is the fundamental reason why. The closest we come are >> the tests for OpenDKIM. If you examine the signing tests for OpenDKIM, >> it's clear that they fail your "not hard" requirement. I can write a >> perfectly valid, legal DKIM signing implementation that will fail all of >> OpenDKIM's signing tests, because OpenDKIM has a preferred ordering and >> formatting for tags. >> >> The OpenDKIM signing tests all check that OpenDKIM produces a signature >> header matching a constant string that embodies this preferred ordering. >> Any implementation that uses a different ordering/formatting will obviously >> fail. Changing the tag ordering/formatting changes the hashed value in the >> header, so it's not just a matter of parsing some tag/value pairs. And so >> short of a full DKIM verification implementation it's impossible to make a >> generic test suite that accepts all legal implementations. >> >> Frankly, this is somewhat unfortunate. But DKIM is a relatively simple >> protocol. ARC is more complicated, with multiple levels of signatures and >> more complex state. Given the substantially more complicated nature of >> ARC, it's desirable to have a test suite that will pass any legal >> implementation. Interops are great, but I'd take a bulletproof test suite >> over an interop any day of the week. >> >> I won't be at the IETF meeting this week, but I'd be happy to dive into >> this in more detail over email or phone if it's helpful. >> >> Best, >> >> Peter >> >> On Sun, Mar 26, 2017 at 7:32 PM, John R Levine wrote: >> >>> It's even more important than it was with DKIM to have a test suite that >>>> can verify signing behavior. If we don't agree on any sort of >>>> standard, a >>>> test suite will need to select a preferred format for the ARC headers & >>>> will fail all implementations that don't meet this form. We've >>>> discussed >>>> this with Murray, and he agrees with this conclusion. >>>> >>> >>> I have to say I don't find that very persuasive. It's not hard to write >>> test code that checks for the hashes and fields in a signature header >>> without regard to what order they're in. I would rather write better test >>> code than add fragile extra cruft to every ARC implementation. >>> >>> As it happens, the IETF is meeting this week in Chicago, and I expect >>> I'll see Murray in the next day or two so I can talk to him directly. >>> >>> >>> R's, >>> John >>> >>> _______________________________________________ >>> dmarc mailing list >>> dmarc@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmarc >>> >> >> >> >> -- >> >> >> [image: logo for sig file.png] >> >> Bringing Trust to Email >> >> Peter Goldstein | CTO & Co-Founder >> >> peter@valimail.com >> +1.415.793.5783 <(415)%20793-5783> >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> >> -- [image: logo for sig file.png] Bringing Trust to Email Peter Goldstein | CTO & Co-Founder peter@valimail.com +1.415.793.5783 --001a1149dfbe248eca054bbafd6a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Brandon,

How do you validate= that the signature verifies?=C2=A0 To do that you need an entire ARC imple= mentation that is packaged within the test suite (and the ability for it to= run as a service, or make it available in some way to implementations bein= g tested that are written in different languages).=C2=A0 That's the who= le point.

The tests under discussion are valid= ating that with assorted inputs (original message, DNS configuration, etc.)= an ARC implementation produces a valid output message (correct ARC seal, A= RC chain, etc.).=C2=A0 Essentially we're looking at testing that:
=

SIGN(INPUTS) =3D> OUTPUT MESSAGE

With the canonicalization being proposed, the OUTPUT MESSAGE becomes = a deterministic result, and verifying it becomes a matter of string compari= son.=C2=A0 This is the success criterion:

OUTPUT M= ESSAGE =3D=3D EXPECTED MESSAGE

Without the canonic= alization being proposed, it will be necessary to run verification on the O= UTPUT MESSAGE to assess whether the test gives the expected results for a g= eneric implementation.=C2=A0 In that case this is the success criterion:

ARC_VALIDATION(OUTPUT MESSAGE, INPUTS) =3D=3D EXPECT= ED_ARC_STATE(INPUTS)

We can't use the ARC vali= dation implementation for the library under test, because it may share bugs= with the signing side.=C2=A0 Instead we'll need to have a bundled ARC = validaiton with the test suite.

Does that make sen= se?

Best,

Peter



=

O= n Mon, Mar 27, 2017 at 11:06 AM, Brandon Long <blong@google.com> wrote:
What does va= lidating the exact signature generated benefit us over just verifying that = the signature verifies?

I have= n't looked at what the tests are for signing, though given the descript= ions =C2=A0for the verifying tests, I'm not sure it would be obvious.= =C2=A0 Can you summarize them?

Brandon

On Mar 26, 2017 9:26 PM, "Peter= Goldstein" <peter@valimail.com> wrote:
John,
=C2=A0
I= have to say I don't find that very persuasive.=C2=A0 It's not hard= to write test code that checks for the hashes and fields in a signature he= ader without regard to what order they're in.=C2=A0 I would rather writ= e better test code than add fragile extra cruft to every ARC implementation= .

I honestly find this response a little unpersuasive =C2=A0:).=C2= =A0 There are two points I'd like to raise.

First, the idea that locking = down the format of the signature adds 'fragile extra cruft' seems o= ff to me.=C2=A0 On the contrary, the suggestions in this thread reduce frag= ility - by requiring that the set of signed fields (ARC Message Signatures,= ARC Seals) meet a well-defined, strict, and trivially verifiable format.= =C2=A0 This is fairly standard practice in video, security, etc. protocols = - every field has a place, and large scale re-ordering/re-formatting is not= permitted unless there's a compelling technical reason.=C2=A0

I'm not su= re why there's a perceived value in accommodating ambiguity here - this= is a brand new standard with a limited number of actual implementers.=C2= =A0 There's no random person not on this list implementing ARC (especia= lly given the standard isn't finalized).=C2=A0 And if there is, the who= le idea of providing a globally usable automated test suite is to ensure th= at person can easily validate that their implementation will interoperate.<= /div>

Second= , the premise that "it's not hard to write test code..." is s= imply not true.=C2=A0 What would be required to actually write such code wo= uld be either a) pick a preferred ordering/formatting for these tags, and o= nly have the tests pass for that ordering or b) include a complete ARC veri= fying system in the test code.=C2=A0 The first is what OpenDKIM did for its= specs (see below).=C2=A0 The latter is possible, but seems ill-advised for= a test suite.

To see that this is the case, it's useful to look at two earli= er email standards and their corresponding test suites.=C2=A0 SPF has a lan= guage-agnostic test suite (http://www.openspf.org/Test_Suite) that makes it e= asy to test implementations in any language.=C2=A0 I've done it myself,= and it requires minimal effort -=C2=A0https://github.c= om/ValiMail/coppertone/tree/master/spec/open_spf.=C2=A0 I can= tell you from personal experience that the test suite was really helpful i= n ensuring the implementation was correct in all cases.

There is no corresponding= test suite for DKIM, and the ambiguity in tag/value ordering is the fundam= ental reason why.=C2=A0 The closest we come are the tests for OpenDKIM.=C2= =A0 If you examine the signing tests for OpenDKIM, it's clear that they= fail your "not hard" requirement.=C2=A0 I can write a perfectly = valid, legal DKIM signing implementation that will fail all of OpenDKIM'= ;s signing tests, because OpenDKIM has a preferred ordering and formatting = for tags.

The OpenDKIM signing tests all check that OpenDKIM produces a signature= header matching a constant string that embodies this preferred ordering.= =C2=A0 Any implementation that uses a different ordering/formatting will ob= viously fail.=C2=A0 Changing the tag ordering/formatting changes the hashed= value in the header, so it's not just a matter of parsing some tag/val= ue pairs.=C2=A0 And so short of a full DKIM verification implementation it&= #39;s impossible to make a generic test suite that accepts all legal implem= entations.

Frankly, this is somewhat unfortunate.=C2=A0 But DKIM is a relatively = simple protocol.=C2=A0 ARC is more complicated, with multiple levels of sig= natures and more complex state.=C2=A0 Given the substantially more complica= ted nature of ARC, it's desirable to have a test suite that will pass a= ny legal implementation.=C2=A0 Interops are great, but I'd take a bulle= tproof test suite over an interop any day of the week.

I won't be at the= IETF meeting this week, but I'd be happy to dive into this in more det= ail over email or phone if it's helpful.

Best,

Peter

On Sun, Mar 26, 2017 at 7:32 PM, John R Le= vine <johnl@taugh.com> wrote:
It's even more important than it was with DKIM to have a test suite tha= t
can verify signing behavior.=C2=A0 If we don't agree on any sort of sta= ndard, a
test suite will need to select a preferred format for the ARC headers &=
will fail all implementations that don't meet this form.=C2=A0 We'v= e discussed
this with Murray, and he agrees with this conclusion.

 I have to say I don't find that very persuasive.=C2=A0 It's not har= d to write test code that checks for the hashes and fields in a signature h= eader without regard to what order they're in.=C2=A0 I would rather wri= te better test code than add fragile extra cruft to every ARC implementatio= n.

As it happens, the IETF is meeting this week in Chicago, and I expect I'= ;ll see Murray in the next day or two so I can talk to him directly.


R's,
John

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



--
=


3D"logo

Bringing Trust to= Email

Peter Goldstei= n | CTO & Co-Founder

peter@valimail.= com

+1.415.793.578= 3
<= /div>

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




--
=
=


3D"logo

Bringing Trust to= Email

Peter Goldstei= n | CTO & Co-Founder

peter@valimail.= com

+1.415.793.57= 83
<= /div>
--001a1149dfbe248eca054bbafd6a-- From nobody Mon Mar 27 15:45:52 2017 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 2A6E31296A4 for ; Mon, 27 Mar 2017 15:45:50 -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 uGX4V2NSgLEt for ; Mon, 27 Mar 2017 15:45:46 -0700 (PDT) Received: from lepidum.jp (lepidum.jp [60.32.83.213]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D4221296AD for ; Mon, 27 Mar 2017 15:45:43 -0700 (PDT) Received: from dhcp-8e94.meeting.ietf.org (dhcp-8e94.meeting.ietf.org [31.133.142.148]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: okd@lepidum.co.jp) by mail06.server.lepidum.net (Postfix) with ESMTPSA id CF3F62F8000C5 for ; Tue, 28 Mar 2017 07:45:40 +0900 (JST) To: dmarc@ietf.org References: <8559BB82-3951-4B14-A3D9-011936AEAD9E@lepidum.co.jp> <2153663.3j7HfnN8Lr@kitterma-e6430> From: Kouji Okada Message-ID: <72d7e03d-dce8-4263-e329-1511a15ccdd7@lepidum.co.jp> Date: Tue, 28 Mar 2017 07:45:38 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <2153663.3j7HfnN8Lr@kitterma-e6430> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Clamav-Info: Checked(Clean) X-LepidumMailFilterAgent-by: mailfromd (5.1) X-LepidumMailFilterAgent-Info: Original (mailfrom:Inbound) Archived-At: Subject: Re: [dmarc-ietf] updating draft-akagiri-dmarc-virtual-verification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 27 Mar 2017 22:45:50 -0000 Terry and Scott Thank you for you feedback. I’m sorry for my late reply. We don’t stick around utilizing “dmarc=pass”. The authors will discuss the authentication-results again and update the draft. >> Also, not sure why there would be a discussion of rua and ruf. It's >> straightforward to interpolate the virtual DMARC record but how can you >> interpolate where to send a failure report? When submitting 00 draft, there were some responses that without reporting, it cannot be called DMARC. We could utilize whois records or some other operational information, but that kind of guess is too rude. So, just to clarify, we kept the discussion. Best regards, Kouji Okada On 2017/03/25 13:45, Scott Kitterman wrote:> >For SPF, we had "best guess" [1], which we chose not to standardize at all >because we didn't think it appropriate to break the opt-in nature of SPF. >This concerns me a bit here, but I'm mostly writing to support the idea of >distinguishing between some kind of guess and an actual DMARC result. > >I think "dmarc=bestguesspass" is far superior to "dmarc=pass", since this is >not a DMARC pass. I think "dmarcguess=pass" would be better since this isn't >properly a DMARC check at all. > >Scott k > > >[1] http://www.openspf.org/FAQ/Best_guess_record > > >On Friday, March 24, 2017 04:55:42 PM Terry Zink wrote: >> Microsoft already does what is in the spec in Office 365 (which they >> specifically call out in the draft), so eventually Hotmail/Outlook.com will >> inherit it. But there are two differences: > >> 1. Office 365 stamps "dmarc=bestguesspass", not "dmarc=pass". That makes it >> easier to distinguish in the logs > 2. We do relaxed alignment, not strict >> alignment like it says in the spec >> Seems to work just fine. >> >> Also, not sure why there would be a discussion of rua and ruf. It's >> straightforward to interpolate the virtual DMARC record but how can you >> interpolate where to send a failure report? > >> --Terry >> >> -----Original Message----- >> From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Kouji Okada >> Sent: Friday, March 24, 2017 2:19 AM >> To: dmarc >> Cc: Kouji Okada >> Subject: [dmarc-ietf] updating draft-akagiri-dmarc-virtual-verification >> >> Folks >> >> We are now working on revising draft-akagiri-dmarc-virtual-verification. >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker >> .ietf.org%2Fdoc%2Fhtml%2Fdraft-akagiri-dmarc-virtual-verification&data=02%7C >> 01%7Ctzink%40microsoft.com%7C75cd5739368a40ce682208d47296da95%7C72f988bf86f1 >> 41af91ab2d7cd011db47%7C1%7C0%7C636259439620932357&sdata=lDAi6TjldCXogGZlQI1V >> pLfYOya3fjaJPRn8mtBgo1U%3D&reserved=0 > >> We are going to submit new version in early April. >> Authors are recognizing there are some open issues for the draft. >> >> 1. The authentication code. >> >> In the draft, we suggest to mark “dmarc=pass” in the authentication result >> when the virtual dmarc verifications have passed. > We are going to keep it >> as it is. >> >> In 02, we are going to mention that e-mail operators can add comments to the >> authentication result field to indicate the “pass” is marked by the virtual >> verification. > We are not going to define the format of the comments, but >> the example comment would be like below. >> ex) dmarc=pass(vdmarc=true) >> >> 2. vdmarc=fail problem >> >> When submitting 00 version of the draft, some people gave us the comments >> that it is harmful to mark “dmarc=fail” without explicit declaration of >> policy records. > Our intention is to utilize the authentication results of >> “dmarc=pass” for the e-mails potentially can be treated as so. >> >> As Takehito posted to this ML, >> our evaluation on Japanese ISPs showed >> more than 20% of received email traffic can be treated as "dmarc=pass" with >> our verification. > Thus our proposal helps to increase the number of >> legitimate e-mails on the receiver side. >> “Statistics about effects of “Virtual DMARC””: >> >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.vdmarc >> .dmarc.jp%2F%3Fp%3D122&data=02%7C01%7Ctzink%40microsoft.com%7C75cd5739368a40 >> ce682208d47296da95%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636259439620 >> 942364&sdata=mVyeZ5EMI6cj1pvUXVYinZZi64JLqjE9v90iCUwiJ4M%3D&reserved=0 > >> We are going to emphasize the point in 02. >> >> 3. rua, ruf >> >> We do not define any default report destinations for the virtual >> verification. > >> 4. Draft tile >> >> Currently our draft title is “DMARC verification without record >> definitions(dmarc-virtual-verification)”. > Would you have any suggestions >> for the title? >> >> >> Any comments will be appreciated. >> >> Thank you, >> Kouji Okada >> >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.or >> g%2Fmailman%2Flistinfo%2Fdmarc&data=02%7C01%7Ctzink%40microsoft.com%7C75cd57 >> 39368a40ce682208d47296da95%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6362 >> 59439620942364&sdata=AeIU1ls97f%2FktoX0ZuTufv1xDE0Q8%2FTAq%2BGpK8g9MvE%3D&re >> served=0 > _______________________________________________ >> 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 > From nobody Mon Mar 27 16:36:46 2017 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 CF4C5124B0A for ; Mon, 27 Mar 2017 16:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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=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 9LiUHnRj1Dsd for ; Mon, 27 Mar 2017 16:36:41 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::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 0587C1296B9 for ; Mon, 27 Mar 2017 16:36:41 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id i203so42758188ywc.3 for ; Mon, 27 Mar 2017 16:36:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UmQS8kNd6mL8xUVDgwzcc2CPwQoHgMCPh4aHbAmNXeo=; b=TAuagZnS1H/GF11KhmTqGT3Sn+n4UPDTfrKXOwpQvJFOhPEECU0RsuhwfETUseEDTf OzJy1EIL48WrnuvdBgJt02tp6+s4A2sNw3zW1NKCNi0r4Y/BNWKa1PqbjrthG9zu3+Vf aIUE6gWOrcAKrYhqCWn+cVdyPJJuVX/NsJQmvVXOa6HZcmnuZ5QEXPYepu/eVQabJy/q L5WGYx1GQq5ae2ruCx8TMU2IsQf/DLdZw9+XUQOxVgLLIebeqSHQq5bhccKCJTMIMOwA K1lpDmycyHr7o3ModM7xr0RwhKN1g8O+EIxEG1BkEH1A0EgcuAFBSPCaBiCb5HbwmEeC ZLrA== 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=UmQS8kNd6mL8xUVDgwzcc2CPwQoHgMCPh4aHbAmNXeo=; b=d8h7JtauRc0/8gPA6KthiWXD25cb/uHxhNo7fTiMPtAbF2WlTgJtZIwOIvx4lf+y+i VuQ/0P0tbmpZvswkeceeSsCdAaZ94szT1SIL+1otnrmzp9T6ITmHuSW8kcJ6i0341WAu sYtd/hmYDJv4Jdkbu+F6TYhpNSBk3l5L8ZLwilsAhUVUcbs8y7ACMDS2A4lWA1deICbr glwFz0O/MFBUyPZ7KO9464dDUFz09cukHW3NiWHPEe8vAmpJSa1QXHi899kgdFU+S5pU wKSvbiETPOKiW9IXUz92zuIfggJbpdywaSTbYq9gM3o27kIOa4FYymE7EKVppO/vpSoi nJ6Q== X-Gm-Message-State: AFeK/H3oi9tG4StQc+kXxoNEkqHelKIKBIToRQ6ygG9wdMyXLPu+/ko5S9+4NNYLi/Z/01joUxFBg41PuRW3lOPj X-Received: by 10.129.164.149 with SMTP id b143mr19012859ywh.347.1490657799692; Mon, 27 Mar 2017 16:36:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.220.11 with HTTP; Mon, 27 Mar 2017 16:36:38 -0700 (PDT) Received: by 10.37.220.11 with HTTP; Mon, 27 Mar 2017 16:36:38 -0700 (PDT) In-Reply-To: References: <20170324212304.85346.qmail@ary.lan> From: Brandon Long Date: Mon, 27 Mar 2017 16:36:38 -0700 Message-ID: To: Peter Goldstein Cc: dmarc@ietf.org, Gene Shuman , John R Levine Content-Type: multipart/alternative; boundary=94eb2c128d48a24ba0054bbed073 Archived-At: Subject: Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 27 Mar 2017 23:36:45 -0000 --94eb2c128d48a24ba0054bbed073 Content-Type: text/plain; charset=UTF-8 Generating the tests did require an arc impl , however. I can understand if this was simple enough to generate them by hand or with a couple lines of python, but instead we're testing against an unknown impl that we can't validate is correct. Brandon On Mar 27, 2017 12:02 PM, "Peter Goldstein" wrote: Brandon, How do you validate that the signature verifies? To do that you need an entire ARC implementation that is packaged within the test suite (and the ability for it to run as a service, or make it available in some way to implementations being tested that are written in different languages). That's the whole point. The tests under discussion are validating that with assorted inputs (original message, DNS configuration, etc.) an ARC implementation produces a valid output message (correct ARC seal, ARC chain, etc.). Essentially we're looking at testing that: SIGN(INPUTS) => OUTPUT MESSAGE With the canonicalization being proposed, the OUTPUT MESSAGE becomes a deterministic result, and verifying it becomes a matter of string comparison. This is the success criterion: OUTPUT MESSAGE == EXPECTED MESSAGE Without the canonicalization being proposed, it will be necessary to run verification on the OUTPUT MESSAGE to assess whether the test gives the expected results for a generic implementation. In that case this is the success criterion: ARC_VALIDATION(OUTPUT MESSAGE, INPUTS) == EXPECTED_ARC_STATE(INPUTS) We can't use the ARC validation implementation for the library under test, because it may share bugs with the signing side. Instead we'll need to have a bundled ARC validaiton with the test suite. Does that make sense? Best, Peter On Mon, Mar 27, 2017 at 11:06 AM, Brandon Long wrote: > What does validating the exact signature generated benefit us over just > verifying that the signature verifies? > > I haven't looked at what the tests are for signing, though given the > descriptions for the verifying tests, I'm not sure it would be obvious. > Can you summarize them? > > Brandon > > On Mar 26, 2017 9:26 PM, "Peter Goldstein" wrote: > >> John, >> >> >>> I have to say I don't find that very persuasive. It's not hard to write >>> test code that checks for the hashes and fields in a signature header >>> without regard to what order they're in. I would rather write better test >>> code than add fragile extra cruft to every ARC implementation. >> >> >> I honestly find this response a little unpersuasive :). There are two >> points I'd like to raise. >> >> First, the idea that locking down the format of the signature adds >> 'fragile extra cruft' seems off to me. On the contrary, the suggestions in >> this thread reduce fragility - by requiring that the set of signed fields >> (ARC Message Signatures, ARC Seals) meet a well-defined, strict, and >> trivially verifiable format. This is fairly standard practice in video, >> security, etc. protocols - every field has a place, and large scale >> re-ordering/re-formatting is not permitted unless there's a compelling >> technical reason. >> >> I'm not sure why there's a perceived value in accommodating ambiguity >> here - this is a brand new standard with a limited number of actual >> implementers. There's no random person not on this list implementing ARC >> (especially given the standard isn't finalized). And if there is, the >> whole idea of providing a globally usable automated test suite is to ensure >> that person can easily validate that their implementation will interoperate. >> >> Second, the premise that "it's not hard to write test code..." is simply >> not true. What would be required to actually write such code would be >> either a) pick a preferred ordering/formatting for these tags, and only >> have the tests pass for that ordering or b) include a complete ARC >> verifying system in the test code. The first is what OpenDKIM did for its >> specs (see below). The latter is possible, but seems ill-advised for a >> test suite. >> >> To see that this is the case, it's useful to look at two earlier email >> standards and their corresponding test suites. SPF has a language-agnostic >> test suite (http://www.openspf.org/Test_Suite) that makes it easy to >> test implementations in any language. I've done it myself, and it requires >> minimal effort - https://github.com/ValiMail/ >> coppertone/tree/master/spec/open_spf. I can tell you from personal >> experience that the test suite was really helpful in ensuring the >> implementation was correct in all cases. >> >> There is no corresponding test suite for DKIM, and the ambiguity in >> tag/value ordering is the fundamental reason why. The closest we come are >> the tests for OpenDKIM. If you examine the signing tests for OpenDKIM, >> it's clear that they fail your "not hard" requirement. I can write a >> perfectly valid, legal DKIM signing implementation that will fail all of >> OpenDKIM's signing tests, because OpenDKIM has a preferred ordering and >> formatting for tags. >> >> The OpenDKIM signing tests all check that OpenDKIM produces a signature >> header matching a constant string that embodies this preferred ordering. >> Any implementation that uses a different ordering/formatting will obviously >> fail. Changing the tag ordering/formatting changes the hashed value in the >> header, so it's not just a matter of parsing some tag/value pairs. And so >> short of a full DKIM verification implementation it's impossible to make a >> generic test suite that accepts all legal implementations. >> >> Frankly, this is somewhat unfortunate. But DKIM is a relatively simple >> protocol. ARC is more complicated, with multiple levels of signatures and >> more complex state. Given the substantially more complicated nature of >> ARC, it's desirable to have a test suite that will pass any legal >> implementation. Interops are great, but I'd take a bulletproof test suite >> over an interop any day of the week. >> >> I won't be at the IETF meeting this week, but I'd be happy to dive into >> this in more detail over email or phone if it's helpful. >> >> Best, >> >> Peter >> >> On Sun, Mar 26, 2017 at 7:32 PM, John R Levine wrote: >> >>> It's even more important than it was with DKIM to have a test suite that >>>> can verify signing behavior. If we don't agree on any sort of >>>> standard, a >>>> test suite will need to select a preferred format for the ARC headers & >>>> will fail all implementations that don't meet this form. We've >>>> discussed >>>> this with Murray, and he agrees with this conclusion. >>>> >>> >>> I have to say I don't find that very persuasive. It's not hard to write >>> test code that checks for the hashes and fields in a signature header >>> without regard to what order they're in. I would rather write better test >>> code than add fragile extra cruft to every ARC implementation. >>> >>> As it happens, the IETF is meeting this week in Chicago, and I expect >>> I'll see Murray in the next day or two so I can talk to him directly. >>> >>> >>> R's, >>> John >>> >>> _______________________________________________ >>> dmarc mailing list >>> dmarc@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmarc >>> >> >> >> >> -- >> >> >> [image: logo for sig file.png] >> >> Bringing Trust to Email >> >> Peter Goldstein | CTO & Co-Founder >> >> peter@valimail.com >> +1.415.793.5783 <(415)%20793-5783> >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> >> -- [image: logo for sig file.png] Bringing Trust to Email Peter Goldstein | CTO & Co-Founder peter@valimail.com +1.415.793.5783 <(415)%20793-5783> --94eb2c128d48a24ba0054bbed073 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Generating the tests did require an arc impl , however.= =C2=A0 I can understand if this was simple enough to generate them by hand = or with a couple lines of python, but instead we're testing against an = unknown impl that we can't validate is correct.

Brandon



On Mar 27, 2= 017 12:02 PM, "Peter Goldstein" <peter@valimail.com> wrote:
Brandon,

Ho= w do you validate that the signature verifies?=C2=A0 To do that you need an= entire ARC implementation that is packaged within the test suite (and the = ability for it to run as a service, or make it available in some way to imp= lementations being tested that are written in different languages).=C2=A0 T= hat's the whole point.

The tests under dis= cussion are validating that with assorted inputs (original message, DNS con= figuration, etc.) an ARC implementation produces a valid output message (co= rrect ARC seal, ARC chain, etc.).=C2=A0 Essentially we're looking at te= sting that:

SIGN(INPUTS) =3D> OUTPUT MESSAGE

With the canonicalization being proposed, the OUTPUT= MESSAGE becomes a deterministic result, and verifying it becomes a matter = of string comparison.=C2=A0 This is the success criterion:

OUTPUT MESSAGE =3D=3D EXPECTED MESSAGE

Wi= thout the canonicalization being proposed, it will be necessary to run veri= fication on the OUTPUT MESSAGE to assess whether the test gives the expecte= d results for a generic implementation.=C2=A0 In that case this is the succ= ess criterion:

ARC_VALIDATION(OUTPUT MESSAGE, INPU= TS) =3D=3D EXPECTED_ARC_STATE(INPUTS)

We can't= use the ARC validation implementation for the library under test, because = it may share bugs with the signing side.=C2=A0 Instead we'll need to ha= ve a bundled ARC validaiton with the test suite.

D= oes that make sense?

Best,

Peter





On Mon, Mar 27, 2017 at 11:06 AM, Br= andon Long <blong@google.com> wrote:
What does validating the exact signature genera= ted benefit us over just verifying that the signature verifies?

I haven't looked at what the tests ar= e for signing, though given the descriptions =C2=A0for the verifying tests,= I'm not sure it would be obvious.=C2=A0 Can you summarize them?

Brandon

On Mar 2= 6, 2017 9:26 PM, "Peter Goldstein" <peter@valimail.com> wrote:
John,
=C2=A0
I have to say I don't find that very persuas= ive.=C2=A0 It's not hard to write test code that checks for the hashes = and fields in a signature header without regard to what order they're i= n.=C2=A0 I would rather write better test code than add fragile extra cruft= to every ARC implementation.

I honestly find this response a littl= e unpersuasive =C2=A0:).=C2=A0 There are two points I'd like to raise.<= br>

Fi= rst, the idea that locking down the format of the signature adds 'fragi= le extra cruft' seems off to me.=C2=A0 On the contrary, the suggestions= in this thread reduce fragility - by requiring that the set of signed fiel= ds (ARC Message Signatures, ARC Seals) meet a well-defined, strict, and tri= vially verifiable format.=C2=A0 This is fairly standard practice in video, = security, etc. protocols - every field has a place, and large scale re-orde= ring/re-formatting is not permitted unless there's a compelling technic= al reason.=C2=A0

I'm not sure why there's a perceived value in accommodat= ing ambiguity here - this is a brand new standard with a limited number of = actual implementers.=C2=A0 There's no random person not on this list im= plementing ARC (especially given the standard isn't finalized).=C2=A0 A= nd if there is, the whole idea of providing a globally usable automated tes= t suite is to ensure that person can easily validate that their implementat= ion will interoperate.

Second, the premise that "it's not hard to write = test code..." is simply not true.=C2=A0 What would be required to actu= ally write such code would be either a) pick a preferred ordering/formattin= g for these tags, and only have the tests pass for that ordering or b) incl= ude a complete ARC verifying system in the test code.=C2=A0 The first is wh= at OpenDKIM did for its specs (see below).=C2=A0 The latter is possible, bu= t seems ill-advised for a test suite.

<= /div>
To see that this is the case, it's usef= ul to look at two earlier email standards and their corresponding test suit= es.=C2=A0 SPF has a language-agnostic test suite (http://www.openspf.org/Test_Sui= te) that makes it easy to test implementations in any language.=C2=A0 I= 've done it myself, and it requires minimal effort -=C2=A0https://github.com/ValiMail/coppertone/tree/master/spec/op= en_spf.=C2=A0 I can tell you from personal experience that the test sui= te was really helpful in ensuring the implementation was correct in all cas= es.

Th= ere is no corresponding test suite for DKIM, and the ambiguity in tag/value= ordering is the fundamental reason why.=C2=A0 The closest we come are the = tests for OpenDKIM.=C2=A0 If you examine the signing tests for OpenDKIM, it= 's clear that they fail your "not hard" requirement.=C2=A0 I = can write a perfectly valid, legal DKIM signing implementation that will fa= il all of OpenDKIM's signing tests, because OpenDKIM has a preferred or= dering and formatting for tags.

<= div class=3D"gmail_extra">The OpenDKIM signing tests all check that OpenDKI= M produces a signature header matching a constant string that embodies this= preferred ordering.=C2=A0 Any implementation that uses a different orderin= g/formatting will obviously fail.=C2=A0 Changing the tag ordering/formattin= g changes the hashed value in the header, so it's not just a matter of = parsing some tag/value pairs.=C2=A0 And so short of a full DKIM verificatio= n implementation it's impossible to make a generic test suite that acce= pts all legal implementations.

Frankly, this is somewhat unfortunate.=C2=A0 But D= KIM is a relatively simple protocol.=C2=A0 ARC is more complicated, with mu= ltiple levels of signatures and more complex state.=C2=A0 Given the substan= tially more complicated nature of ARC, it's desirable to have a test su= ite that will pass any legal implementation.=C2=A0 Interops are great, but = I'd take a bulletproof test suite over an interop any day of the week.<= br>

I = won't be at the IETF meeting this week, but I'd be happy to dive in= to this in more detail over email or phone if it's helpful.

Best,

Peter

On Sun, Mar 26, 2017 at= 7:32 PM, John R Levine <johnl@taugh.com> wrote:
It's even more important than it was with DKIM to have a test suite tha= t
can verify signing behavior.=C2=A0 If we don't agree on any sort of sta= ndard, a
test suite will need to select a preferred format for the ARC headers &=
will fail all implementations that don't meet this form.=C2=A0 We'v= e discussed
this with Murray, and he agrees with this conclusion.

 I have to say I don't find that very persuasive.=C2=A0 It's not har= d to write test code that checks for the hashes and fields in a signature h= eader without regard to what order they're in.=C2=A0 I would rather wri= te better test code than add fragile extra cruft to every ARC implementatio= n.

As it happens, the IETF is meeting this week in Chicago, and I expect I'= ;ll see Murray in the next day or two so I can talk to him directly.


R's,
John

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



--
=
=


3D"logo

Bringing Trust to Email

Peter Goldstein | CTO & Co-Founder

peter@valimail.com

+1.415.793.5783
<= /div>

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




--
=


3D"logo

Peter Goldstein | CTO & Co-Founder

peter@valimail.com

+1.415.793.5783

--94eb2c128d48a24ba0054bbed073-- From nobody Mon Mar 27 17:24:18 2017 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 698CE1296D5 for ; Mon, 27 Mar 2017 17:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.718 X-Spam-Level: X-Spam-Status: No, score=-1.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhNfkYmAQKC7 for ; Mon, 27 Mar 2017 17:24:11 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d: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 E22131296C7 for ; Mon, 27 Mar 2017 17:24:10 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id d10so47395352qke.1 for ; Mon, 27 Mar 2017 17:24:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+ETGHwH3oukAjuRvSGFTCSyWnNMTbaeo8rHjliZb2l0=; b=Qejg2C+PNFi5YDo2lFkBj/K8exk/XsyM5tTnlY1Hx5Cs0nvGmgdJ9zjrqWLBZ9+kox NafwHjRxAQZZ1EMieNNhy/hfc8gxHZvX4ePeIabIQ9N9h0k3OBbCdvlKQG/mxV/5D2uU hj76MObAYkWodJIDZ7PM66Yt1dXsHLWZD5IUm0j2IxqtdauXnydJNzETEFi02PhN7xj2 ebkXccq5egyrgy8dlZ7Z750f1g14O8HWYq3Tt20LwPvjSEl4DzHWlqpa1w5+nNiGjAiD YgPD8KyiU8a4xF8nnDr6K/XK2h8+TDUKY5eaUhTXTqXPdkst7pc9OXmHSPpmoMusj8Hm rEEg== 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=+ETGHwH3oukAjuRvSGFTCSyWnNMTbaeo8rHjliZb2l0=; b=PnVsex7VIIe7SUo/ULaHt8nGr9C+zym2eA5X0v8daUsJ+iy1zfanW6IjIhnk+ySB7Z /7BS/ei9laZRVVBsD1w3CInY8ZUXWDIg1ppzo74Tn99xf4HIiPNce2DjgzNymXaZ+p5s u0Cefsd0pgfBbulxm+aAZb5a/2zwo5Zb2lgUTd8rVwhPDl08FBFj/xQJCZT77uroepoX ys2Cf6N48MPHNRaUk+v+2HNsmqyxAjH/iNuM5+mlw+WmcrO9y/czp7JSwLS4wAdOAjA1 gCqkj/gTN4OKw39QqE1A7keSNnXuCGBsww1uEfbQAw+LdYcPegU+56lTytihBpkjiFJE GlAA== X-Gm-Message-State: AFeK/H1SZcN53l0bl7WGTez5Q+ac6mnU7Oy6CWgUSY9dTmd5OUwcnHemZX7Xz9SNHD3bebaibtJ6m0/4KOeDFQ== X-Received: by 10.55.170.143 with SMTP id t137mr21701631qke.303.1490660649770; Mon, 27 Mar 2017 17:24:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.141.207 with HTTP; Mon, 27 Mar 2017 17:24:09 -0700 (PDT) In-Reply-To: References: <20170324212304.85346.qmail@ary.lan> From: Peter Goldstein Date: Mon, 27 Mar 2017 17:24:09 -0700 Message-ID: To: Brandon Long Cc: dmarc , Gene Shuman , John R Levine Content-Type: multipart/alternative; boundary=94eb2c05d99a82bfe8054bbf7a95 Archived-At: Subject: Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 28 Mar 2017 00:24:16 -0000 --94eb2c05d99a82bfe8054bbf7a95 Content-Type: text/plain; charset=UTF-8 Sure, generating the output message requires an ARC implementation. Same as generating a DKIM signature for validation requires an actual DKIM implementation. Or generating an SPF result for a complex situation generally requires an actual SPF implementation. Or generating an ARC-signed input message for the verifying side of the test suite requires some sort of ARC signing implementation. But I wouldn't agree with the inference that "we're testing against an unknown impl that we can't validate is correct" in any of these cases. The validity of the test suite derives from the fact that: 1. It was constructed from the RFC, and is built to cover a reasonably comprehensive set of cases - more complete than any individual developer is likely to consider. 2. While the output may have been generated with a particular implementation, the test suite should be validated against a number of independently developed implementations. That ensures correctness, and surfaces discrepancies which may represent ambiguities in the specification and/or errors in the test suite or one or more of the implementations. 3. Once N implementations have validated, the N+1th implementation is guaranteed a high degree of interoperability if it also passes the test suite. 4. If new edge cases are discovered or evolved, interoperability can be assured by adding them to the test suite and testing existing implementations. If there is ambiguity or disagreement in this circumstance, this is an opportunity for the community to come up with the agreed-upon right answer for behavior in this new case, and update the test suite to reflect that. None of this requires that we consider some unknown implementation that we can't validate is correct. The test suite becomes a statement of consistency among the different implementers and their interpretations of the RFC. See the OpenSPF.org test suite for a good example of how this works. Having a fully deterministic specification makes this all a lot easier. As I've stated previously, the alternative to the above is bundling a reference ARC verifier with the test suite. That means someone needs to write such a reference verifier (or repurpose and repackage an existing one). In addition, the test suite needs to be updated to ensure the reference implementation can be used as a service when developing ARC implementations in any language. That's more work, and it also makes the use of the test suite much more complex. I think tightening up some currently allowed ambiguity in the ARC specification is a much simpler and much better solution. I'm not sure why there's such concern about canonicalizing the format and ordering of some tag/value pairs. Best, Peter On Mon, Mar 27, 2017 at 4:36 PM, Brandon Long wrote: > Generating the tests did require an arc impl , however. I can understand > if this was simple enough to generate them by hand or with a couple lines > of python, but instead we're testing against an unknown impl that we can't > validate is correct. > > Brandon > > > > On Mar 27, 2017 12:02 PM, "Peter Goldstein" wrote: > > Brandon, > > How do you validate that the signature verifies? To do that you need an > entire ARC implementation that is packaged within the test suite (and the > ability for it to run as a service, or make it available in some way to > implementations being tested that are written in different languages). > That's the whole point. > > The tests under discussion are validating that with assorted inputs > (original message, DNS configuration, etc.) an ARC implementation produces > a valid output message (correct ARC seal, ARC chain, etc.). Essentially > we're looking at testing that: > > SIGN(INPUTS) => OUTPUT MESSAGE > > With the canonicalization being proposed, the OUTPUT MESSAGE becomes a > deterministic result, and verifying it becomes a matter of string > comparison. This is the success criterion: > > OUTPUT MESSAGE == EXPECTED MESSAGE > > Without the canonicalization being proposed, it will be necessary to run > verification on the OUTPUT MESSAGE to assess whether the test gives the > expected results for a generic implementation. In that case this is the > success criterion: > > ARC_VALIDATION(OUTPUT MESSAGE, INPUTS) == EXPECTED_ARC_STATE(INPUTS) > > We can't use the ARC validation implementation for the library under test, > because it may share bugs with the signing side. Instead we'll need to > have a bundled ARC validaiton with the test suite. > > Does that make sense? > > Best, > > Peter > > > > > > On Mon, Mar 27, 2017 at 11:06 AM, Brandon Long wrote: > >> What does validating the exact signature generated benefit us over just >> verifying that the signature verifies? >> >> I haven't looked at what the tests are for signing, though given the >> descriptions for the verifying tests, I'm not sure it would be obvious. >> Can you summarize them? >> >> Brandon >> >> On Mar 26, 2017 9:26 PM, "Peter Goldstein" wrote: >> >>> John, >>> >>> >>>> I have to say I don't find that very persuasive. It's not hard to >>>> write test code that checks for the hashes and fields in a signature header >>>> without regard to what order they're in. I would rather write better test >>>> code than add fragile extra cruft to every ARC implementation. >>> >>> >>> I honestly find this response a little unpersuasive :). There are two >>> points I'd like to raise. >>> >>> First, the idea that locking down the format of the signature adds >>> 'fragile extra cruft' seems off to me. On the contrary, the suggestions in >>> this thread reduce fragility - by requiring that the set of signed fields >>> (ARC Message Signatures, ARC Seals) meet a well-defined, strict, and >>> trivially verifiable format. This is fairly standard practice in video, >>> security, etc. protocols - every field has a place, and large scale >>> re-ordering/re-formatting is not permitted unless there's a compelling >>> technical reason. >>> >>> I'm not sure why there's a perceived value in accommodating ambiguity >>> here - this is a brand new standard with a limited number of actual >>> implementers. There's no random person not on this list implementing ARC >>> (especially given the standard isn't finalized). And if there is, the >>> whole idea of providing a globally usable automated test suite is to ensure >>> that person can easily validate that their implementation will interoperate. >>> >>> Second, the premise that "it's not hard to write test code..." is simply >>> not true. What would be required to actually write such code would be >>> either a) pick a preferred ordering/formatting for these tags, and only >>> have the tests pass for that ordering or b) include a complete ARC >>> verifying system in the test code. The first is what OpenDKIM did for its >>> specs (see below). The latter is possible, but seems ill-advised for a >>> test suite. >>> >>> To see that this is the case, it's useful to look at two earlier email >>> standards and their corresponding test suites. SPF has a language-agnostic >>> test suite (http://www.openspf.org/Test_Suite) that makes it easy to >>> test implementations in any language. I've done it myself, and it requires >>> minimal effort - https://github.com/ValiMail/ >>> coppertone/tree/master/spec/open_spf. I can tell you from personal >>> experience that the test suite was really helpful in ensuring the >>> implementation was correct in all cases. >>> >>> There is no corresponding test suite for DKIM, and the ambiguity in >>> tag/value ordering is the fundamental reason why. The closest we come are >>> the tests for OpenDKIM. If you examine the signing tests for OpenDKIM, >>> it's clear that they fail your "not hard" requirement. I can write a >>> perfectly valid, legal DKIM signing implementation that will fail all of >>> OpenDKIM's signing tests, because OpenDKIM has a preferred ordering and >>> formatting for tags. >>> >>> The OpenDKIM signing tests all check that OpenDKIM produces a signature >>> header matching a constant string that embodies this preferred ordering. >>> Any implementation that uses a different ordering/formatting will obviously >>> fail. Changing the tag ordering/formatting changes the hashed value in the >>> header, so it's not just a matter of parsing some tag/value pairs. And so >>> short of a full DKIM verification implementation it's impossible to make a >>> generic test suite that accepts all legal implementations. >>> >>> Frankly, this is somewhat unfortunate. But DKIM is a relatively simple >>> protocol. ARC is more complicated, with multiple levels of signatures and >>> more complex state. Given the substantially more complicated nature of >>> ARC, it's desirable to have a test suite that will pass any legal >>> implementation. Interops are great, but I'd take a bulletproof test suite >>> over an interop any day of the week. >>> >>> I won't be at the IETF meeting this week, but I'd be happy to dive into >>> this in more detail over email or phone if it's helpful. >>> >>> Best, >>> >>> Peter >>> >>> On Sun, Mar 26, 2017 at 7:32 PM, John R Levine wrote: >>> >>>> It's even more important than it was with DKIM to have a test suite that >>>>> can verify signing behavior. If we don't agree on any sort of >>>>> standard, a >>>>> test suite will need to select a preferred format for the ARC headers & >>>>> will fail all implementations that don't meet this form. We've >>>>> discussed >>>>> this with Murray, and he agrees with this conclusion. >>>>> >>>> >>>> I have to say I don't find that very persuasive. It's not hard to >>>> write test code that checks for the hashes and fields in a signature header >>>> without regard to what order they're in. I would rather write better test >>>> code than add fragile extra cruft to every ARC implementation. >>>> >>>> As it happens, the IETF is meeting this week in Chicago, and I expect >>>> I'll see Murray in the next day or two so I can talk to him directly. >>>> >>>> >>>> R's, >>>> John >>>> >>>> _______________________________________________ >>>> dmarc mailing list >>>> dmarc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dmarc >>>> >>> >>> >>> >>> -- >>> >>> >>> [image: logo for sig file.png] >>> >>> Bringing Trust to Email >>> >>> Peter Goldstein | CTO & Co-Founder >>> >>> peter@valimail.com >>> +1.415.793.5783 <(415)%20793-5783> >>> >>> _______________________________________________ >>> dmarc mailing list >>> dmarc@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmarc >>> >>> > > > -- > > > [image: logo for sig file.png] > > Bringing Trust to Email > > Peter Goldstein | CTO & Co-Founder > > peter@valimail.com > +1.415.793.5783 <(415)%20793-5783> > > > -- [image: logo for sig file.png] Bringing Trust to Email Peter Goldstein | CTO & Co-Founder peter@valimail.com +1.415.793.5783 --94eb2c05d99a82bfe8054bbf7a95 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sure, generating the output message requires an ARC implem= entation.=C2=A0 Same as generating a DKIM signature for validation requires= an actual DKIM implementation.=C2=A0 Or generating an SPF result for a com= plex situation generally requires an actual SPF implementation.=C2=A0 Or ge= nerating an ARC-signed input message for the verifying side of the test sui= te requires some sort of ARC signing implementation.=C2=A0 But I wouldn'= ;t agree with the inference that "we're testing against an unknown= impl that we can't validate is correct" in any of these cases.
The validity of the test suite derives from the fact that:=

1. It was constructed from the RFC, and is built = to cover a reasonably comprehensive set of cases - more complete than any i= ndividual developer is likely to consider.
2. While the output ma= y have been generated with a particular implementation, the test suite shou= ld be validated against a number of independently developed implementations= .=C2=A0 That ensures correctness, and surfaces discrepancies which may repr= esent ambiguities in the specification and/or errors in the test suite or o= ne or more of the implementations.
3. Once N implementations have= validated, the N+1th implementation is guaranteed a high degree of interop= erability if it also passes the test suite.
4. If new edge cases = are discovered or evolved, interoperability can be assured by adding them t= o the test suite and testing existing implementations.=C2=A0 If there is am= biguity or disagreement in this circumstance, this is an opportunity for th= e community to come up with the agreed-upon right answer for behavior in th= is new case, and update the test suite to reflect that.

None of this requires that we consider some unknown implementation th= at we can't validate is correct.=C2=A0 The test suite becomes a stateme= nt of consistency among the different implementers and their interpretation= s of the RFC.=C2=A0 See the OpenSPF.org test suite for a good example of ho= w this works.

Having a fully deterministic sp= ecification makes this all a lot easier. =C2=A0

As= I've stated previously, the alternative to the above is bundling a ref= erence ARC verifier with the test suite.=C2=A0 That means someone needs to = write such a reference verifier (or repurpose and repackage an existing one= ).=C2=A0=C2=A0=C2=A0In addition, the test suite needs to be updated to ensu= re the reference implementation can be used as a service when developing AR= C implementations in any language.=C2=A0 That's more work, and it also = makes the use of the test suite much more complex.

I think tightening up some currently allowed ambiguity in the ARC specific= ation is a much simpler and much better solution.=C2=A0 I'm not sure wh= y there's such concern about canonicalizing the format and ordering of = some tag/value pairs.

Best,

Peter

On Mon, Mar 27, 2017 at 4:3= 6 PM, Brandon Long <blong@google.com> wrote:
Generating the tests did require an arc= impl , however.=C2=A0 I can understand if this was simple enough to genera= te them by hand or with a couple lines of python, but instead we're tes= ting against an unknown impl that we can't validate is correct.

Brandon



On Mar 27, 2017 12:02 PM, "Peter Goldstein" <peter@valimail.com&= gt; wrote:
Brandon,

How do you v= alidate that the signature verifies?=C2=A0 To do that you need an entire AR= C implementation that is packaged within the test suite (and the ability fo= r it to run as a service, or make it available in some way to implementatio= ns being tested that are written in different languages).=C2=A0 That's = the whole point.

The tests under discussion ar= e validating that with assorted inputs (original message, DNS configuration= , etc.) an ARC implementation produces a valid output message (correct ARC = seal, ARC chain, etc.).=C2=A0 Essentially we're looking at testing that= :

SIGN(INPUTS) =3D> OUTPUT MESSAGE
With the canonicalization being proposed, the OUTPUT MESSAGE b= ecomes a deterministic result, and verifying it becomes a matter of string = comparison.=C2=A0 This is the success criterion:

O= UTPUT MESSAGE =3D=3D EXPECTED MESSAGE

Without the = canonicalization being proposed, it will be necessary to run verification o= n the OUTPUT MESSAGE to assess whether the test gives the expected results = for a generic implementation.=C2=A0 In that case this is the success criter= ion:

ARC_VALIDATION(OUTPUT MESSAGE, INPUTS) =3D=3D= EXPECTED_ARC_STATE(INPUTS)

We can't use the A= RC validation implementation for the library under test, because it may sha= re bugs with the signing side.=C2=A0 Instead we'll need to have a bundl= ed ARC validaiton with the test suite.

Does that m= ake sense?

Best,

Peter





On Mon, Mar 27, 2017 at = 11:06 AM, Brandon Long <blong@google.com> wrote:
What does validating the exact sign= ature generated benefit us over just verifying that the signature verifies?=

I haven't looked at what = the tests are for signing, though given the descriptions =C2=A0for the veri= fying tests, I'm not sure it would be obvious.=C2=A0 Can you summarize = them?

Brand= on

On Mar = 26, 2017 9:26 PM, "Peter Goldstein" <peter@valimail.com> wrote:
John,
=C2=A0
I have to say I don't find that very persua= sive.=C2=A0 It's not hard to write test code that checks for the hashes= and fields in a signature header without regard to what order they're = in.=C2=A0 I would rather write better test code than add fragile extra cruf= t to every ARC implementation.

I honestly find this response a litt= le unpersuasive =C2=A0:).=C2=A0 There are two points I'd like to raise.=

F= irst, the idea that locking down the format of the signature adds 'frag= ile extra cruft' seems off to me.=C2=A0 On the contrary, the suggestion= s in this thread reduce fragility - by requiring that the set of signed fie= lds (ARC Message Signatures, ARC Seals) meet a well-defined, strict, and tr= ivially verifiable format.=C2=A0 This is fairly standard practice in video,= security, etc. protocols - every field has a place, and large scale re-ord= ering/re-formatting is not permitted unless there's a compelling techni= cal reason.=C2=A0

I'm not sure why there's a perceived value in accommoda= ting ambiguity here - this is a brand new standard with a limited number of= actual implementers.=C2=A0 There's no random person not on this list i= mplementing ARC (especially given the standard isn't finalized).=C2=A0 = And if there is, the whole idea of providing a globally usable automated te= st suite is to ensure that person can easily validate that their implementa= tion will interoperate.

Second, the premise that "it's not hard to write= test code..." is simply not true.=C2=A0 What would be required to act= ually write such code would be either a) pick a preferred ordering/formatti= ng for these tags, and only have the tests pass for that ordering or b) inc= lude a complete ARC verifying system in the test code.=C2=A0 The first is w= hat OpenDKIM did for its specs (see below).=C2=A0 The latter is possible, b= ut seems ill-advised for a test suite.

=
To see that this is the case, it's use= ful to look at two earlier email standards and their corresponding test sui= tes.=C2=A0 SPF has a language-agnostic test suite (http://www.openspf.org/Test_Su= ite) that makes it easy to test implementations in any language.=C2=A0 = I've done it myself, and it requires minimal effort -=C2=A0https://github.com/ValiMail/coppertone/tree/master/spec/open_spf.=C2=A0 I can tell you from personal experience that the test su= ite was really helpful in ensuring the implementation was correct in all ca= ses.

T= here is no corresponding test suite for DKIM, and the ambiguity in tag/valu= e ordering is the fundamental reason why.=C2=A0 The closest we come are the= tests for OpenDKIM.=C2=A0 If you examine the signing tests for OpenDKIM, i= t's clear that they fail your "not hard" requirement.=C2=A0 I= can write a perfectly valid, legal DKIM signing implementation that will f= ail all of OpenDKIM's signing tests, because OpenDKIM has a preferred o= rdering and formatting for tags.

=
The OpenDKIM signing tests all check that OpenDK= IM produces a signature header matching a constant string that embodies thi= s preferred ordering.=C2=A0 Any implementation that uses a different orderi= ng/formatting will obviously fail.=C2=A0 Changing the tag ordering/formatti= ng changes the hashed value in the header, so it's not just a matter of= parsing some tag/value pairs.=C2=A0 And so short of a full DKIM verificati= on implementation it's impossible to make a generic test suite that acc= epts all legal implementations.

<= div class=3D"gmail_extra">Frankly, this is somewhat unfortunate.=C2=A0 But = DKIM is a relatively simple protocol.=C2=A0 ARC is more complicated, with m= ultiple levels of signatures and more complex state.=C2=A0 Given the substa= ntially more complicated nature of ARC, it's desirable to have a test s= uite that will pass any legal implementation.=C2=A0 Interops are great, but= I'd take a bulletproof test suite over an interop any day of the week.=

I= won't be at the IETF meeting this week, but I'd be happy to dive i= nto this in more detail over email or phone if it's helpful.

Best,

Peter

On Sun, Mar 26, 2017 a= t 7:32 PM, John R Levine <johnl@taugh.com> wrote:
It's even more important than it was with DKIM to have a test suite tha= t
can verify signing behavior.=C2=A0 If we don't agree on any sort of sta= ndard, a
test suite will need to select a preferred format for the ARC headers &=
will fail all implementations that don't meet this form.=C2=A0 We'v= e discussed
this with Murray, and he agrees with this conclusion.

I have to say I don't find that very persuasive.=C2=A0 It's not har= d to write test code that checks for the hashes and fields in a signature h= eader without regard to what order they're in.=C2=A0 I would rather wri= te better test code than add fragile extra cruft to every ARC implementatio= n.

As it happens, the IETF is meeting this week in Chicago, and I expect I'= ;ll see Murray in the next day or two so I can talk to him directly.


R's,
John

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



--
=
=


Bringing Trust to Email

Peter Goldstein | CTO & Co-Founder<= /p>

peter@valimail.com

+1.415.793.5783
=

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




--
=


Bringing Trust to Email

Peter Goldstein | CTO & Co-Founder<= /p>

peter@valimail.com

+1.415.793.5783
=




--

<= br>

3D"logo

Bringing Trust to Email

Peter Goldstein | CTO &= ; Co-Founder

peter@valimail.com

+1.415.793.5783
=
--94eb2c05d99a82bfe8054bbf7a95-- From nobody Mon Mar 27 19:21:16 2017 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 B917D1296E7 for ; Mon, 27 Mar 2017 19:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=Yr/xTMtK; dkim=pass (1536-bit key) header.d=taugh.com header.b=BSUihpqv 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 Wd20jEUkcQzI for ; Mon, 27 Mar 2017 19:21:14 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D1E31296E8 for ; Mon, 27 Mar 2017 19:21:13 -0700 (PDT) Received: (qmail 37208 invoked from network); 28 Mar 2017 02:21:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=9156.58d9c897.k1703; bh=NyqUHCM+nrzp/TmOUdMBsVFNXMH5onEcxqhHqCcSI2E=; b=Yr/xTMtKBV98keL7+vIWFVJTdBpYKWUFQp/p73+9UZmVChNQcd+pvllkc1wvM/04yrIGAqX+0+nTDgpnLry50yySwxqvBM01JlEoSQsfG396ugC0F3eeElbBTJ3hOCUYnyqYR19B5FzPi36XjZavx3aEeYTUX8HHSTJ4xXuePpDLmMxaNbWWPvZWvekdzREzz/sTsU8NeMu+HbHoYpgztgRy5XqaQo59WtNWiy3M+4C7HDfmKGdK/QLODOADYbOx DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=9156.58d9c897.k1703; bh=NyqUHCM+nrzp/TmOUdMBsVFNXMH5onEcxqhHqCcSI2E=; b=BSUihpqvqRfDEK/DqzGqljxGlX3GDSxifr7qtDV/MZCkJHOwHw/U35F7sBZ4bxtP/yYqT8piyoHnjfLHKVWq4Sf02AT00nhczh0V1dIVcBPtbqmGYtcAUS5BsXTwaCxzrKYinu4paVXfOfR5ptTQaQuy/7oQeI5LhUIVSu9BT6nP6NtlCAHnSEaPe4vxGNEGorR4IW/qgmJcwzEZ2wJrdohYCuFD02N1s2259lKjQqlj7BGHVmHic5/MN8xIG293 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; 28 Mar 2017 02:21:11 -0000 Date: 27 Mar 2017 21:21:11 -0500 Message-ID: From: "John R Levine" To: "Peter Goldstein" Cc: "dmarc" In-Reply-To: References: <20170324212304.85346.qmail@ary.lan> User-Agent: Alpine 2.20 (OSX 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 28 Mar 2017 02:21:16 -0000 > I think tightening up some currently allowed ambiguity in the ARC > specification is a much simpler and much better solution. I'm not sure why > there's such concern about canonicalizing the format and ordering of some > tag/value pairs. If you think that's all it would take to make signature headers perfectly identical, you will be deeeply disappointed. (Take a look at FWS in the ABNF and all of the other generic ABNF for message headers.) I think what we've been saying is that the SMTP mail ecosystem has never tried to make stuff bit-for-bit reproducible, and even if you could hammer on the spec to make super strict rules for one particular header, it's unlikely that the people who are adapting their DKIM code would pay attention. R's, John From nobody Mon Mar 27 19:54:50 2017 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 CCF171204DA for ; Mon, 27 Mar 2017 19:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zrqo_yk2sh0o for ; Mon, 27 Mar 2017 19:54:46 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CAD1128D3E for ; Mon, 27 Mar 2017 19:54:44 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id r45so53904111qte.3 for ; Mon, 27 Mar 2017 19:54:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bPnFd0+hDcief9RIJmDAVlY+4+y91EYN/8Ki1C4SbnQ=; b=UUDsZPFp0HsfCHebzRXlRvfQcxdCVWGPcR1FAfVikAGDnST8W3MMQXEazq4EKCPz1s 3GIa9VcZtLjoOePvnfU6h9eRhFBDAzSxZrUS5xjcETwXNHSM5qmvUAe6/UVEc2yY5b8l spykDjSYuzDYMHRmLNopCQnc0aW86/q5f8wIEn+RpYcaPZEdClGhKZEriF7cY1Q2/KZl AHradroNUHp8aEW+gMtAoZHLv0Bjh7DHU2BFAKelNq3/6o0YdgrdbSjouugS2oSVZ9FB t8mkZhWe7tVc7hCGGFv8L6PEHPbEkvwmwxCorC9ZyICtupqlY6fvAvkpbB8SM23IGrdb nStw== 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=bPnFd0+hDcief9RIJmDAVlY+4+y91EYN/8Ki1C4SbnQ=; b=YJz6EvOOGDBKHqzD4a9frysGYYPNfIdMJs6c1u9ICH/tl5hz98Sz9gEhvqf9nNVhOF TpyxCqdX1a/isreSm2A60uoNv1LjzFyedCQWK7To0+CM3DF+ZsX2RIgbrI7hE7p3zNsN qP2YEQ+/xyRCRJLjOFHK9xm21oTGcOJPDz9L0PfXRh262UB4Gk2QisvPSrKAiuNECj8U Gc5hlCZP7nlQlXSPlHpsjyFdWqPHXMiR3UGyv5KM/ibY/VyI6RZLZUNCEj58gN4jaQr0 41bCO0/+in/KMyBlIQkSZG6CvYT+EGRoPTfxJiMBJH+ORvnvuglzFTezLkIhhKbNKvBH 3c+w== X-Gm-Message-State: AFeK/H2wg5tzL0qZut7f9g/BsapROJ/yqAlimcdJEKjdejqWq9j6YbfkiKJboR2Y1AEYvjohWsnnW/PaJOXeZA== X-Received: by 10.200.52.135 with SMTP id w7mr24328756qtb.136.1490669684112; Mon, 27 Mar 2017 19:54:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.141.207 with HTTP; Mon, 27 Mar 2017 19:54:43 -0700 (PDT) In-Reply-To: References: <20170324212304.85346.qmail@ary.lan> From: Peter Goldstein Date: Mon, 27 Mar 2017 19:54:43 -0700 Message-ID: To: John R Levine Cc: dmarc Content-Type: multipart/alternative; boundary=001a1141a706ffd506054bc194db Archived-At: Subject: Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 28 Mar 2017 02:54:49 -0000 --001a1141a706ffd506054bc194db Content-Type: text/plain; charset=UTF-8 John, I'm familiar with the definition of the FWS in the ABNF, as well as the generic definition ABNF for message headers. I'm also aware of the challenges with trying to normalize such headers, and how that can impact email authentication - breaking forwarded DKIM signatures and such. But none of that is actually relevant here - we are not interested in arbitrary messages. We are interested in creating a set of valid input messages and ensuring that these messages are signed in a consistent, reliable way by any valid ARC implementation. This is an extremely narrow case - so yes, I do think the above is basically all it would take to make such signature headers identical. Perhaps I'll be disappointed, but based on the sample messages I have on hand from existing implementations, that seems unlikely. As for the hypothetical developers who will be adapting DKIM libraries to do ARC signing, we've been talking about them since M3AAWG in October 2015. So far they haven't materialized. Honestly, it's not even clear to me that there are that many DKIM libraries out there to adapt. Instead we've seen ~5 implementations (Google, AOL, Dkimpy, OpenARC, MailerQ), with potential support for implementations in 1-2 additional languages (e.g. Perl) probably driven by one or more of the implementers of the existing implementations. It should be relatively easy to coordinate such a change across the small number of existing implementations. Best, Peter On Mon, Mar 27, 2017 at 7:21 PM, John R Levine wrote: > I think tightening up some currently allowed ambiguity in the ARC >> specification is a much simpler and much better solution. I'm not sure >> why >> there's such concern about canonicalizing the format and ordering of some >> tag/value pairs. >> > > If you think that's all it would take to make signature headers perfectly > identical, you will be deeeply disappointed. (Take a look at FWS in the > ABNF and all of the other generic ABNF for message headers.) > > I think what we've been saying is that the SMTP mail ecosystem has never > tried to make stuff bit-for-bit reproducible, and even if you could hammer > on the spec to make super strict rules for one particular header, it's > unlikely that the people who are adapting their DKIM code would pay > attention. > > R's, > John > -- [image: logo for sig file.png] Bringing Trust to Email Peter Goldstein | CTO & Co-Founder peter@valimail.com +1.415.793.5783 --001a1141a706ffd506054bc194db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
John,

I'm familiar with the definit= ion of the FWS in the ABNF, as well as the generic definition ABNF for mess= age headers.=C2=A0 I'm also aware of the challenges with trying to norm= alize such headers, and how that can impact email authentication - breaking= forwarded DKIM signatures and such.=C2=A0 But none of that is actually rel= evant here - we are not interested in arbitrary messages.

We are interested in creating a set of valid input messages and ens= uring that these messages are signed in a consistent, reliable way by any v= alid ARC implementation.=C2=A0 This is an extremely narrow case - so yes, I= do think the above is basically all it would take to make such signature h= eaders identical.=C2=A0 Perhaps I'll be disappointed, but based on the = sample messages I have on hand from existing implementations, that seems un= likely.

As for the hypothetical developers who wil= l be adapting DKIM libraries to do ARC signing, we've been talking abou= t them since M3AAWG in October 2015.=C2=A0 So far they haven't material= ized.=C2=A0 Honestly, it's not even clear to me that there are that man= y DKIM libraries out there to adapt.

Instead we= 9;ve seen ~5 implementations (Google, AOL, Dkimpy, OpenARC, MailerQ), with = potential support for implementations in 1-2 additional languages (e.g. Per= l) probably driven by one or more of the implementers of the existing imple= mentations.=C2=A0 It should be relatively easy to coordinate such a change = across the small number of existing implementations.

Best,

Peter




On Mon, Mar 27, 2017 at 7:21 PM, John R Levine <johnl@tau= gh.com> wrote:
I think tightening up some currently allowed ambiguity in the ARC
specification is a much simpler and much better solution.=C2=A0 I'm not= sure why
there's such concern about canonicalizing the format and ordering of so= me
tag/value pairs.

 If you think that's all it would take to make signature headers perfect= ly identical, you will be deeeply disappointed.=C2=A0 (Take a look at FWS i= n the ABNF and all of the other generic ABNF for message headers.)

I think what we've been saying is that the SMTP mail ecosystem has neve= r tried to make stuff bit-for-bit reproducible, and even if you could hamme= r on the spec to make super strict rules for one particular header, it'= s unlikely that the people who are adapting their DKIM code would pay atten= tion.

R's,
John



--

<= br>

3D"logo

Bringing Trust to Email

Peter Goldstein | CTO &= ; Co-Founder

peter@valimail.com

+1.415.793.5783
=
--001a1141a706ffd506054bc194db-- From nobody Mon Mar 27 21:49:35 2017 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 8595A12987B for ; Mon, 27 Mar 2017 21:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-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=kitterman.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 Pc9CRBmJVSGx for ; Mon, 27 Mar 2017 21:49:21 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C908127241 for ; Mon, 27 Mar 2017 21:49:21 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 027A5C40293 for ; Mon, 27 Mar 2017 23:49:19 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1490676559; bh=jhUqbbkqe933UHJ6Q/ZyXoT/tDbEfR5qsyKahTxcR6o=; h=From:To:Subject:Date:In-Reply-To:References:From; b=W7tpcywnp2j+PGTJ4UHGElRE5WHfxKEbwU+/ApcoaEVZcHlhb9qG6ppO5OF6HKzvn Q6ytJRX0gvQCw01M71L8t5N9qERRI7IO/BXluzDqV9GufPTuJWVy6GYXWXs8ic4Vdx ZV9RGA8tHkYwZLmGQ6H0QGvOXtIfmvHD/9rRZoH4= From: Scott Kitterman To: dmarc@ietf.org Date: Tue, 28 Mar 2017 00:49:17 -0400 Message-ID: <2978391.eJVbVTHBlo@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-112-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 28 Mar 2017 04:49:32 -0000 What's more difficult to is identify all the ways that things get reordered, mangled, etc as they transit the various elements of the mail architecture. If you over specify the allowed order, aren't you risking increasing the brittleness of the solution. If test cases are automatically generated, then they are cheap and we shouldn't worry about unduly constraining things to keep the number small. As long as, at some point, the test cases are validated against multiple implementations, I think it's fine. If you've got a handful of implementations, then the risk of them all having the same bug is pretty low. In addition to Perl, I'd expect something in Ruby to appear in due course. Scott K On Monday, March 27, 2017 07:54:43 PM Peter Goldstein wrote: > John, > > I'm familiar with the definition of the FWS in the ABNF, as well as the > generic definition ABNF for message headers. I'm also aware of the > challenges with trying to normalize such headers, and how that can impact > email authentication - breaking forwarded DKIM signatures and such. But > none of that is actually relevant here - we are not interested in arbitrary > messages. > > We are interested in creating a set of valid input messages and ensuring > that these messages are signed in a consistent, reliable way by any valid > ARC implementation. This is an extremely narrow case - so yes, I do think > the above is basically all it would take to make such signature headers > identical. Perhaps I'll be disappointed, but based on the sample messages > I have on hand from existing implementations, that seems unlikely. > > As for the hypothetical developers who will be adapting DKIM libraries to > do ARC signing, we've been talking about them since M3AAWG in October > 2015. So far they haven't materialized. Honestly, it's not even clear to > me that there are that many DKIM libraries out there to adapt. > > Instead we've seen ~5 implementations (Google, AOL, Dkimpy, OpenARC, > MailerQ), with potential support for implementations in 1-2 additional > languages (e.g. Perl) probably driven by one or more of the implementers of > the existing implementations. It should be relatively easy to coordinate > such a change across the small number of existing implementations. > > Best, > > Peter > > On Mon, Mar 27, 2017 at 7:21 PM, John R Levine wrote: > > I think tightening up some currently allowed ambiguity in the ARC > > > >> specification is a much simpler and much better solution. I'm not sure > >> why > >> there's such concern about canonicalizing the format and ordering of some > >> tag/value pairs. > > > > If you think that's all it would take to make signature headers perfectly > > identical, you will be deeeply disappointed. (Take a look at FWS in the > > ABNF and all of the other generic ABNF for message headers.) > > > > I think what we've been saying is that the SMTP mail ecosystem has never > > tried to make stuff bit-for-bit reproducible, and even if you could hammer > > on the spec to make super strict rules for one particular header, it's > > unlikely that the people who are adapting their DKIM code would pay > > attention. > > > > R's, > > John From nobody Mon Mar 27 22:30:44 2017 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 50474126C89 for ; Mon, 27 Mar 2017 22:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id El6L3pCnRG-3 for ; Mon, 27 Mar 2017 22:30:39 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 E2D14126D85 for ; Mon, 27 Mar 2017 22:30:38 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id r45so55518402qte.3 for ; Mon, 27 Mar 2017 22:30:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EPSkHIOZbQW3C5BLerJqq+hTy0Pg/3pTL/4xIVor770=; b=LkA3h7D7exARt3SQ4etwZdxaL49Oz0VOMCvPvub0nt/TtzEE0mZsCNPkLGr85N5o1M JQj15bAQqVTrFO3zNI8tYIoPSx0j/TGSNpj4aQeXRdWidhX60XRkElsdbjDyTRq+51ds fxvPX8NkycPQc/Nt5m9BuV06EnGJjcPp7JGXpTkNnTGdJcBqKxLRSsPOl1ESyRouZYEA fE7NjczwXRbNq9orRsuP06AAbodsF84V2KP3HSFHn0CcxSmAkZKcAtVnMajGInGwb6QB nmVtgTo4759d/RmZBRXhExMBQNkgBVRJXl9Nssip2nmJcVDMWUh+W9ohdDvsdVQklUa6 +P1w== 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=EPSkHIOZbQW3C5BLerJqq+hTy0Pg/3pTL/4xIVor770=; b=dFTQcBfvqse2jH+dGNdOqVxVmqzGLVm9fS42kINsu0pQYjDh1PmHQifL1Df3wlehF9 cIMpYkksOnCDap+B0bJo3t1Dc+d+nqOUsCM6Ebn4rldQxhWiNbFGaI/AXABkkg8BZAW6 k5OerucNEYBa4o0u+pwynzi1gpDwdglCg5gzWx52Wx2NzuSet+d5yCJ8pjvnvh9iRVMw 541KdmCSMifpRSS0sCvBuY5mgiDFZthvvJnyWWf3E9WhklgGw2Lotf/z1clr2WMRRuiP uCE/nB6nHZDlL2RktWpLu3GIloZbml36vTzC/DVuKQz4ZhqApRno1tyLepVlD/+RZjMR j2YQ== X-Gm-Message-State: AFeK/H0v20RJGI4Hq5hq8T/B0OrhW9XOAzTzoyfd1mZxUimaAFGSeS6apA2lKEMcZZtCuJheOtwOe1ZYdhMl0g== X-Received: by 10.200.52.135 with SMTP id w7mr24741613qtb.136.1490679037885; Mon, 27 Mar 2017 22:30:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.141.207 with HTTP; Mon, 27 Mar 2017 22:30:37 -0700 (PDT) In-Reply-To: <2978391.eJVbVTHBlo@kitterma-e6430> References: <2978391.eJVbVTHBlo@kitterma-e6430> From: Peter Goldstein Date: Mon, 27 Mar 2017 22:30:37 -0700 Message-ID: To: Scott Kitterman Cc: dmarc Content-Type: multipart/alternative; boundary=001a1141a70687464b054bc3c224 Archived-At: Subject: Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 28 Mar 2017 05:30:42 -0000 --001a1141a70687464b054bc3c224 Content-Type: text/plain; charset=UTF-8 Scott, Header reordering is irrelevant to this discussion - the ARC RFC specifies in some detail how to construct the ARC Seal from the AMS and AAR headers - https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-02#section-5.2 . And the AMS headers have the same behavior as DKIM - header ordering and canonicalization is also well-defined, so header re-ordering doesn't impact the signature. The discussion at hand is literally about the ordering and formatting of tag/value pairs within the individual ARC headers. So the only brittleness question is whether existing mail infrastructure will potentially alter the internal structure of the AMS header or ARC Seal header. That is...unlikely. We can conclude it's unlikely, because a similar alteration of a DKIM signature header would break the DKIM signature of forwarded email. So if DKIM generally works (and it does), we should be able to conclude that specifying ordering/formatting of the tag/value pairs in an AMS/ARC header does not represent an increase in brittleness. I'm not really sure I understand the point regarding the # of test cases. We're not worried about keeping the # of test cases small - we're interested in ensuring that the same test cases will run successfully against any valid ARC implementation. Can you please clarify? And yes, something will probably be developed in Ruby at some point - but it's just as likely to be a de novo effort, as it is a modification of an existing DKIM gem. There is only 1 pure Ruby DKIM signing gem I'm aware of - https://github.com/jhawthorn/dkim - and it hasn't had any updates in 2+ years and lacks verification logic. So it's a less than ideal basis for developing an ARC gem. Best, Peter On Mon, Mar 27, 2017 at 9:49 PM, Scott Kitterman wrote: > What's more difficult to is identify all the ways that things get > reordered, > mangled, etc as they transit the various elements of the mail architecture. > If you over specify the allowed order, aren't you risking increasing the > brittleness of the solution. > > If test cases are automatically generated, then they are cheap and we > shouldn't worry about unduly constraining things to keep the number > small. As > long as, at some point, the test cases are validated against multiple > implementations, I think it's fine. If you've got a handful of > implementations, then the risk of them all having the same bug is pretty > low. > > In addition to Perl, I'd expect something in Ruby to appear in due course. > > Scott K > > On Monday, March 27, 2017 07:54:43 PM Peter Goldstein wrote: > > John, > > > > I'm familiar with the definition of the FWS in the ABNF, as well as the > > generic definition ABNF for message headers. I'm also aware of the > > challenges with trying to normalize such headers, and how that can impact > > email authentication - breaking forwarded DKIM signatures and such. But > > none of that is actually relevant here - we are not interested in > arbitrary > > messages. > > > > We are interested in creating a set of valid input messages and ensuring > > that these messages are signed in a consistent, reliable way by any valid > > ARC implementation. This is an extremely narrow case - so yes, I do > think > > the above is basically all it would take to make such signature headers > > identical. Perhaps I'll be disappointed, but based on the sample > messages > > I have on hand from existing implementations, that seems unlikely. > > > > As for the hypothetical developers who will be adapting DKIM libraries to > > do ARC signing, we've been talking about them since M3AAWG in October > > 2015. So far they haven't materialized. Honestly, it's not even clear > to > > me that there are that many DKIM libraries out there to adapt. > > > > Instead we've seen ~5 implementations (Google, AOL, Dkimpy, OpenARC, > > MailerQ), with potential support for implementations in 1-2 additional > > languages (e.g. Perl) probably driven by one or more of the implementers > of > > the existing implementations. It should be relatively easy to coordinate > > such a change across the small number of existing implementations. > > > > Best, > > > > Peter > > > > On Mon, Mar 27, 2017 at 7:21 PM, John R Levine wrote: > > > I think tightening up some currently allowed ambiguity in the ARC > > > > > >> specification is a much simpler and much better solution. I'm not > sure > > >> why > > >> there's such concern about canonicalizing the format and ordering of > some > > >> tag/value pairs. > > > > > > If you think that's all it would take to make signature headers > perfectly > > > identical, you will be deeeply disappointed. (Take a look at FWS in > the > > > ABNF and all of the other generic ABNF for message headers.) > > > > > > I think what we've been saying is that the SMTP mail ecosystem has > never > > > tried to make stuff bit-for-bit reproducible, and even if you could > hammer > > > on the spec to make super strict rules for one particular header, it's > > > unlikely that the people who are adapting their DKIM code would pay > > > attention. > > > > > > R's, > > > John > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- [image: logo for sig file.png] Bringing Trust to Email Peter Goldstein | CTO & Co-Founder peter@valimail.com +1.415.793.5783 --001a1141a70687464b054bc3c224 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Scott,

Header reordering is irrel= evant to this discussion - the ARC RFC specifies in some detail how to cons= truct the ARC Seal from the AMS and AAR headers -=C2=A0https://to= ols.ietf.org/html/draft-ietf-dmarc-arc-protocol-02#section-5.2 .=C2=A0 = And the AMS headers have the same behavior as DKIM - header ordering and ca= nonicalization is also well-defined, so header re-ordering doesn't impa= ct the signature.=C2=A0 The discussion at hand is literally about the order= ing and formatting of tag/value pairs within the individual ARC headers.
So the only brittleness question is whether existing mail = infrastructure will potentially alter the internal structure of the AMS hea= der or ARC Seal header.=C2=A0 That is...unlikely.=C2=A0 We can conclude it&= #39;s unlikely, because a similar alteration of a DKIM signature header wou= ld break the DKIM signature of forwarded email.=C2=A0 So if DKIM generally = works (and it does), we should be able to conclude that specifying ordering= /formatting of the tag/value pairs in an AMS/ARC header does not represent = an increase in brittleness.

I'm not really = sure I understand the point regarding the # of test cases.=C2=A0 We're = not worried about keeping the # of test cases small - we're interested = in ensuring that the same test cases will run successfully against any vali= d ARC implementation.=C2=A0 Can you please clarify?

And y= es, something will probably be developed in Ruby at some point - but it'= ;s just as likely to be a de novo effort, as it is a modification of an exi= sting DKIM gem.=C2=A0 There is only 1 pure Ruby DKIM signing gem I'm aw= are of -=C2=A0https://github.= com/jhawthorn/dkim - and it hasn't had any updates in 2+ years and = lacks verification logic.=C2=A0 So it's a less than ideal basis for dev= eloping an ARC gem. =C2=A0

Best,

Peter

On Mon, Mar 27, 2017 at 9:4= 9 PM, Scott Kitterman <sklist@kitterman.com> wrote:
What's more difficult to is identify all t= he ways that things get reordered,
mangled, etc as they transit the various elements of the mail architecture.=
If you over specify the allowed order, aren't you risking increasing th= e
brittleness of the solution.

If test cases are automatically generated, then they are cheap and we
shouldn't worry about unduly constraining things to keep the number sma= ll.=C2=A0 As
long as, at some point, the test cases are validated against multiple
implementations, I think it's fine.=C2=A0 If you've got a handful o= f
implementations, then the risk of them all having the same bug is pretty lo= w.

In addition to Perl, I'd expect something in Ruby to appear in due cour= se.

Scott K

On Monday, March 27, 2017 07:54:43 PM Peter Goldstein wrote:
> John,
>
> I'm familiar with the definition of the FWS in the ABNF, as well a= s the
> generic definition ABNF for message headers.=C2=A0 I'm also aware = of the
> challenges with trying to normalize such headers, and how that can imp= act
> email authentication - breaking forwarded DKIM signatures and such.=C2= =A0 But
> none of that is actually relevant here - we are not interested in arbi= trary
> messages.
>
> We are interested in creating a set of valid input messages and ensuri= ng
> that these messages are signed in a consistent, reliable way by any va= lid
> ARC implementation.=C2=A0 This is an extremely narrow case - so yes, I= do think
> the above is basically all it would take to make such signature header= s
> identical.=C2=A0 Perhaps I'll be disappointed, but based on the sa= mple messages
> I have on hand from existing implementations, that seems unlikely.
>
> As for the hypothetical developers who will be adapting DKIM libraries= to
> do ARC signing, we've been talking about them since M3AAWG in Octo= ber
> 2015.=C2=A0 So far they haven't materialized.=C2=A0 Honestly, it&#= 39;s not even clear to
> me that there are that many DKIM libraries out there to adapt.
>
> Instead we've seen ~5 implementations (Google, AOL, Dkimpy, OpenAR= C,
> MailerQ), with potential support for implementations in 1-2 additional=
> languages (e.g. Perl) probably driven by one or more of the implemente= rs of
> the existing implementations.=C2=A0 It should be relatively easy to co= ordinate
> such a change across the small number of existing implementations.
>
> Best,
>
> Peter
>
> On Mon, Mar 27, 2017 at 7:21 PM,= John R Levine <johnl@taugh.com&g= t; wrote:
> > I think tightening up some currently allowed ambiguity in the ARC=
> >
> >> specification is a much simpler and much better solution.=C2= =A0 I'm not sure
> >> why
> >> there's such concern about canonicalizing the format and = ordering of some
> >> tag/value pairs.
> >
> > If you think that's all it would take to make signature heade= rs perfectly
> > identical, you will be deeeply disappointed.=C2=A0 (Take a look a= t FWS in the
> > ABNF and all of the other generic ABNF for message headers.)
> >
> > I think what we've been saying is that the SMTP mail ecosyste= m has never
> > tried to make stuff bit-for-bit reproducible, and even if you cou= ld hammer
> > on the spec to make super strict rules for one particular header,= it's
> > unlikely that the people who are adapting their DKIM code would p= ay
> > attention.
> >
> > R's,
> > John

____________________________= ___________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc



--
=
=


3D"logo

Bringing Trust to= Email

Peter Goldstei= n | CTO & Co-Founder

peter@valimail.= com

+1.415.793.57= 83
<= /div>
--001a1141a70687464b054bc3c224-- From nobody Tue Mar 28 05:16:22 2017 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 69F841294F3 for ; Tue, 28 Mar 2017 05:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-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=kitterman.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 eNhKbA8ppsId for ; Tue, 28 Mar 2017 05:16:18 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2946112950A for ; Tue, 28 Mar 2017 05:16:18 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 9CE4FC401A8 for ; Tue, 28 Mar 2017 07:16:16 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1490703376; bh=OcH9tvmVv4d4DvybTWlEjP1Wc+XaL8Il5rrQiTXYQFg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=rgzBwMIbJ/OZObA+lKqu+fMFJbJRWkH6S+8We8uOC3uYwcLNbFiYy9tJH3DL1mv1S 0EalDf2xgSAO+OQ4U+f2lq9XqdwQurR1Js9nx/GgZScEo5Wkay9Djb8I5ENiBpwwF/ A2m5DP610veAjlBjbrxwek+F4V3rVd6ILMwEX58c= From: Scott Kitterman To: dmarc Date: Tue, 28 Mar 2017 08:16:15 -0400 Message-ID: <2009319.9kNPMXJLm6@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-112-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <2978391.eJVbVTHBlo@kitterma-e6430> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 28 Mar 2017 12:16:20 -0000 I will confess to not following all the details on a regular basis, but doesn't the paragraph you referenced give a required sequence of multiple header fields? Maybe that's not a problem any more (it's been some years since I looked), but that definitely used to be something it was risky to rely on. The test case comment was based on my understanding that you wanted deterministic ordering because if the ordering wasn't deterministic it would be too hard to test. I think that can be managed. Scott K On Monday, March 27, 2017 10:30:37 PM Peter Goldstein wrote: > Scott, > > Header reordering is irrelevant to this discussion - the ARC RFC specifies > in some detail how to construct the ARC Seal from the AMS and AAR headers - > https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-02#section-5.2 . > And the AMS headers have the same behavior as DKIM - header ordering and > canonicalization is also well-defined, so header re-ordering doesn't impact > the signature. The discussion at hand is literally about the ordering and > formatting of tag/value pairs within the individual ARC headers. > > So the only brittleness question is whether existing mail infrastructure > will potentially alter the internal structure of the AMS header or ARC Seal > header. That is...unlikely. We can conclude it's unlikely, because a > similar alteration of a DKIM signature header would break the DKIM > signature of forwarded email. So if DKIM generally works (and it does), we > should be able to conclude that specifying ordering/formatting of the > tag/value pairs in an AMS/ARC header does not represent an increase in > brittleness. > > I'm not really sure I understand the point regarding the # of test cases. > We're not worried about keeping the # of test cases small - we're > interested in ensuring that the same test cases will run successfully > against any valid ARC implementation. Can you please clarify? > > And yes, something will probably be developed in Ruby at some point - but > it's just as likely to be a de novo effort, as it is a modification of an > existing DKIM gem. There is only 1 pure Ruby DKIM signing gem I'm aware of > - https://github.com/jhawthorn/dkim - and it hasn't had any updates in 2+ > years and lacks verification logic. So it's a less than ideal basis for > developing an ARC gem. > > Best, > > Peter > > On Mon, Mar 27, 2017 at 9:49 PM, Scott Kitterman > > wrote: > > What's more difficult to is identify all the ways that things get > > reordered, > > mangled, etc as they transit the various elements of the mail > > architecture. > > If you over specify the allowed order, aren't you risking increasing the > > brittleness of the solution. > > > > If test cases are automatically generated, then they are cheap and we > > shouldn't worry about unduly constraining things to keep the number > > small. As > > long as, at some point, the test cases are validated against multiple > > implementations, I think it's fine. If you've got a handful of > > implementations, then the risk of them all having the same bug is pretty > > low. > > > > In addition to Perl, I'd expect something in Ruby to appear in due course. > > > > Scott K > > > > On Monday, March 27, 2017 07:54:43 PM Peter Goldstein wrote: > > > John, > > > > > > I'm familiar with the definition of the FWS in the ABNF, as well as the > > > generic definition ABNF for message headers. I'm also aware of the > > > challenges with trying to normalize such headers, and how that can > > > impact > > > email authentication - breaking forwarded DKIM signatures and such. But > > > none of that is actually relevant here - we are not interested in > > > > arbitrary > > > > > messages. > > > > > > We are interested in creating a set of valid input messages and ensuring > > > that these messages are signed in a consistent, reliable way by any > > > valid > > > ARC implementation. This is an extremely narrow case - so yes, I do > > > > think > > > > > the above is basically all it would take to make such signature headers > > > identical. Perhaps I'll be disappointed, but based on the sample > > > > messages > > > > > I have on hand from existing implementations, that seems unlikely. > > > > > > As for the hypothetical developers who will be adapting DKIM libraries > > > to > > > do ARC signing, we've been talking about them since M3AAWG in October > > > 2015. So far they haven't materialized. Honestly, it's not even clear > > > > to > > > > > me that there are that many DKIM libraries out there to adapt. > > > > > > Instead we've seen ~5 implementations (Google, AOL, Dkimpy, OpenARC, > > > MailerQ), with potential support for implementations in 1-2 additional > > > languages (e.g. Perl) probably driven by one or more of the implementers > > > > of > > > > > the existing implementations. It should be relatively easy to > > > coordinate > > > such a change across the small number of existing implementations. > > > > > > Best, > > > > > > Peter > > > > > > On Mon, Mar 27, 2017 at 7:21 PM, John R Levine wrote: > > > > I think tightening up some currently allowed ambiguity in the ARC > > > > > > > >> specification is a much simpler and much better solution. I'm not > > > > sure > > > > > >> why > > > >> there's such concern about canonicalizing the format and ordering of > > > > some > > > > > >> tag/value pairs. > > > > > > > > If you think that's all it would take to make signature headers > > > > perfectly > > > > > > identical, you will be deeeply disappointed. (Take a look at FWS in > > > > the > > > > > > ABNF and all of the other generic ABNF for message headers.) > > > > > > > > I think what we've been saying is that the SMTP mail ecosystem has > > > > never > > > > > > tried to make stuff bit-for-bit reproducible, and even if you could > > > > hammer > > > > > > on the spec to make super strict rules for one particular header, it's > > > > unlikely that the people who are adapting their DKIM code would pay > > > > attention. > > > > > > > > R's, > > > > John > > > > _______________________________________________ > > dmarc mailing list > > dmarc@ietf.org > > https://www.ietf.org/mailman/listinfo/dmarc From nobody Tue Mar 28 06:26:43 2017 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 33D401299DE for ; Tue, 28 Mar 2017 06:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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, RP_MATCHES_RCVD=-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=americangreetings.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 4GS4ObZcXYXW for ; Tue, 28 Mar 2017 06:26:40 -0700 (PDT) Received: from mailer1.americangreetings.com (mailer1.americangreetings.com [66.119.43.158]) (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 DD3B71299D8 for ; Tue, 28 Mar 2017 06:26:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=americangreetings.com; s=q42010; c=relaxed/relaxed; q=dns/txt; i=@americangreetings.com; t=1490707597; x=1522243597; h=From:Subject:Date:To:Cc:Reply-To:Message-ID:MIME-Version:Content-Type; bh=j1MbZfRclWUvrGD89G2DRTgSKSH5nVEAXSNLtT67j6E=; b=REUgIgj/cxeiZD20+gVUVlCstG3+E4ZdhzXmJTJxciWDE5AmPvvNXsq5dJOlwirJ RtKrtIK1I18CY0hgkT+EYIJb2Y8ELq5YeWFOHhUTGFlTf2dGpirxq141IomvfM62 Oet76YTkSkEoKJAJ/HMop8xU2PIp/qT48zavyIDl6Rs=; Received: from [66.119.43.83] ([66.119.43.83:20593] helo=dc3-mbox.ops.ag.com) by momentum8 (envelope-from ) (ecelerity 3.6.18.52357 r(Core:3.6.18.0)) with ESMTP id 81/94-30912-D846AD85; Tue, 28 Mar 2017 09:26:37 -0400 Received: from [10.210.42.34] ([10.210.42.34]) by dc3-mbox.ops.ag.com (8.14.4/8.14.4) with ESMTP id v2SDQbVE008378 for ; Tue, 28 Mar 2017 09:26:37 -0400 To: dmarc@ietf.org References: <8559BB82-3951-4B14-A3D9-011936AEAD9E@lepidum.co.jp> <2153663.3j7HfnN8Lr@kitterma-e6430> From: "mhammer@americangreetings.com" Message-ID: <076e78c0-f52f-d0d4-934d-e4477e27f388@americangreetings.com> Date: Tue, 28 Mar 2017 09:26:37 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <2153663.3j7HfnN8Lr@kitterma-e6430> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] updating draft-akagiri-dmarc-virtual-verification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 28 Mar 2017 13:26:42 -0000 On 3/25/2017 12:45 AM, Scott Kitterman wrote: > For SPF, we had "best guess" [1], which we chose not to standardize at all > because we didn't think it appropriate to break the opt-in nature of SPF. > This concerns me a bit here, but I'm mostly writing to support the idea of > distinguishing between some kind of guess and an actual DMARC result. > > I think "dmarc=bestguesspass" is far superior to "dmarc=pass", since this is > not a DMARC pass. I think "dmarcguess=pass" would be better since this isn't > properly a DMARC check at all. > > Scott k I absolutely agree with Scott on this. "bestguesspass" is NOT DMARC. It is local policy applied in a DMARC like manner. This is also why there is no legitimate place to send reports. The sender did not publish a DMARC record and did not ask for reports. Trying to guess where to send (unasked for) reports is guaranteed to end with poor outcomes. Mike From nobody Tue Mar 28 07:57:18 2017 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 1A4F8126FDC for ; Tue, 28 Mar 2017 07:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cihl5oi0Y_YU for ; Tue, 28 Mar 2017 07:57:11 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ADC81294CD for ; Tue, 28 Mar 2017 07:57:11 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id p22so67683022qka.3 for ; Tue, 28 Mar 2017 07:57:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CfCAAsOzVlcQt5ona9MpXOyaJioXfHC7Ix3nG/wFkWE=; b=bG8z5ND1+TLPuvFdrZ4o0YsAvHotoLQtd9dbSDmv4vxCR98y0A4GaHRBaD1d+nxhM2 rKs4IieAfx4j0pZKswdRlemGXVtHn1MAfQaPaqAgbGWjsmALzjpIQaEMxwE+qoO9wdKi Gruo2jyiraPaS1vwdIYQwRbf62Z7uTBDdLax9ekNMQ5ENdPC64pzmTYUdwHTsrYExs9n XPbdhsAglGo+nE136emuZklMXsuC+dGKK4lWJ/WnGXhNxBDW8zve5Bj/Y5Hdhgjp474P NXK5yGIvMFlxv5p9sBgftckH9Y0Ik61/PdiPCTjqzK33VitqHiug4otVCHePl5jJ2LwT RQYw== 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=CfCAAsOzVlcQt5ona9MpXOyaJioXfHC7Ix3nG/wFkWE=; b=EzKGGOyfOd4syP5cWvV6fqtPEF0Uax55Z3kkCbHZMkqlVEvG1VRViF9Qdud/8RRd02 TChtNKTbXl6xMvGKka0HyPRNLf16JANGTuCpyv0SEWX2Ncva2/XJdIezJhNy9xDBwb33 aSmwygJFo9JpYtM3y64zVfWaM0iQSM0frq2+hjguZ7cC8FYUjRT0PF9ZA84md1tdujN7 7v9q0I6wwDfnhcsfn3Qfxb20dkJeC3YqDxB/c9CBjQZcEwfs+T2yoiEtMOnLepP5K5Lm LyhYdpoyn99BHHvpUve5+/ozLe783FoC7HFA+c+HIJWe7ekzePXnuOqAXjwaOcKpgyL6 7gQg== X-Gm-Message-State: AFeK/H3png1iUbwtURcRZfB0Fb6jIjvHqglMyhE/A3u4Ln8OjKS1GyzMtpy9zZVk2iV8/YosWSK7oO3q+OynHg== X-Received: by 10.55.214.26 with SMTP id t26mr19477727qki.16.1490713030504; Tue, 28 Mar 2017 07:57:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.141.207 with HTTP; Tue, 28 Mar 2017 07:57:09 -0700 (PDT) In-Reply-To: <2009319.9kNPMXJLm6@kitterma-e6430> References: <2978391.eJVbVTHBlo@kitterma-e6430> <2009319.9kNPMXJLm6@kitterma-e6430> From: Peter Goldstein Date: Tue, 28 Mar 2017 07:57:09 -0700 Message-ID: To: Scott Kitterman Cc: dmarc Content-Type: multipart/alternative; boundary=001a1149dfbea54ef1054bcbacfb Archived-At: Subject: Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 28 Mar 2017 14:57:16 -0000 --001a1149dfbea54ef1054bcbacfb Content-Type: text/plain; charset=UTF-8 Scott, I will confess to not following all the details on a regular basis, but > doesn't the paragraph you referenced give a required sequence of multiple > header fields? Maybe that's not a problem any more (it's been some years > since I looked), but that definitely used to be something it was risky to > rely > on. No. Precisely the opposite. The referenced paragraph in the ARC spec is a set of instructions of how to create an ARC Seal for a message. The point of referencing the instructions is to show that the algorithm is already resilient to header re-ordering, and nothing being proposed here would change that. The test case comment was based on my understanding that you wanted > deterministic ordering because if the ordering wasn't deterministic it > would > be too hard to test. I think that can be managed. I think there's a misunderstanding here. You seem to be under the impression that supporting the current non-deterministic behavior can be managed with 'more tests' that can be auto-generated and run against all implementations. That's not the issue. The non-deterministic ordering requires either: 1. Implementations that use different tag/value ordering/formatting cannot share a test suite. Signing tests that are valid for one implementation will not be valid for an implementation using a different tag/value ordering or formatting. or 2. The test suite needs to include a 'reference' ARC verifier #1 explicitly fails your requirement that "test cases are validated against multiple implementations", unless the implementations use the same tag/value canonicalization. This thread is simply proposing that we pick one such canonicalization, and define it in the RFC, so that all ARC implementations share the same canonicalization. I've discussed why I think #2 is a bad idea - it's a lot of work (and it's unclear who will do it), much more fragile and complex, and yields no benefit that has been actually identified. Best, Peter On Tue, Mar 28, 2017 at 5:16 AM, Scott Kitterman wrote: > I will confess to not following all the details on a regular basis, but > doesn't the paragraph you referenced give a required sequence of multiple > header fields? Maybe that's not a problem any more (it's been some years > since I looked), but that definitely used to be something it was risky to > rely > on. > > The test case comment was based on my understanding that you wanted > deterministic ordering because if the ordering wasn't deterministic it > would > be too hard to test. I think that can be managed. > > Scott K > > On Monday, March 27, 2017 10:30:37 PM Peter Goldstein wrote: > > Scott, > > > > Header reordering is irrelevant to this discussion - the ARC RFC > specifies > > in some detail how to construct the ARC Seal from the AMS and AAR > headers - > > https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-02#section-5.2 > . > > And the AMS headers have the same behavior as DKIM - header ordering and > > canonicalization is also well-defined, so header re-ordering doesn't > impact > > the signature. The discussion at hand is literally about the ordering > and > > formatting of tag/value pairs within the individual ARC headers. > > > > So the only brittleness question is whether existing mail infrastructure > > will potentially alter the internal structure of the AMS header or ARC > Seal > > header. That is...unlikely. We can conclude it's unlikely, because a > > similar alteration of a DKIM signature header would break the DKIM > > signature of forwarded email. So if DKIM generally works (and it does), > we > > should be able to conclude that specifying ordering/formatting of the > > tag/value pairs in an AMS/ARC header does not represent an increase in > > brittleness. > > > > I'm not really sure I understand the point regarding the # of test cases. > > We're not worried about keeping the # of test cases small - we're > > interested in ensuring that the same test cases will run successfully > > against any valid ARC implementation. Can you please clarify? > > > > And yes, something will probably be developed in Ruby at some point - but > > it's just as likely to be a de novo effort, as it is a modification of an > > existing DKIM gem. There is only 1 pure Ruby DKIM signing gem I'm aware > of > > - https://github.com/jhawthorn/dkim - and it hasn't had any updates in > 2+ > > years and lacks verification logic. So it's a less than ideal basis for > > developing an ARC gem. > > > > Best, > > > > Peter > > > > On Mon, Mar 27, 2017 at 9:49 PM, Scott Kitterman > > > > wrote: > > > What's more difficult to is identify all the ways that things get > > > reordered, > > > mangled, etc as they transit the various elements of the mail > > > architecture. > > > If you over specify the allowed order, aren't you risking increasing > the > > > brittleness of the solution. > > > > > > If test cases are automatically generated, then they are cheap and we > > > shouldn't worry about unduly constraining things to keep the number > > > small. As > > > long as, at some point, the test cases are validated against multiple > > > implementations, I think it's fine. If you've got a handful of > > > implementations, then the risk of them all having the same bug is > pretty > > > low. > > > > > > In addition to Perl, I'd expect something in Ruby to appear in due > course. > > > > > > Scott K > > > > > > On Monday, March 27, 2017 07:54:43 PM Peter Goldstein wrote: > > > > John, > > > > > > > > I'm familiar with the definition of the FWS in the ABNF, as well as > the > > > > generic definition ABNF for message headers. I'm also aware of the > > > > challenges with trying to normalize such headers, and how that can > > > > impact > > > > email authentication - breaking forwarded DKIM signatures and such. > But > > > > none of that is actually relevant here - we are not interested in > > > > > > arbitrary > > > > > > > messages. > > > > > > > > We are interested in creating a set of valid input messages and > ensuring > > > > that these messages are signed in a consistent, reliable way by any > > > > valid > > > > ARC implementation. This is an extremely narrow case - so yes, I do > > > > > > think > > > > > > > the above is basically all it would take to make such signature > headers > > > > identical. Perhaps I'll be disappointed, but based on the sample > > > > > > messages > > > > > > > I have on hand from existing implementations, that seems unlikely. > > > > > > > > As for the hypothetical developers who will be adapting DKIM > libraries > > > > to > > > > do ARC signing, we've been talking about them since M3AAWG in October > > > > 2015. So far they haven't materialized. Honestly, it's not even > clear > > > > > > to > > > > > > > me that there are that many DKIM libraries out there to adapt. > > > > > > > > Instead we've seen ~5 implementations (Google, AOL, Dkimpy, OpenARC, > > > > MailerQ), with potential support for implementations in 1-2 > additional > > > > languages (e.g. Perl) probably driven by one or more of the > implementers > > > > > > of > > > > > > > the existing implementations. It should be relatively easy to > > > > coordinate > > > > such a change across the small number of existing implementations. > > > > > > > > Best, > > > > > > > > Peter > > > > > > > > On Mon, Mar 27, 2017 at 7:21 PM, John R Levine > wrote: > > > > > I think tightening up some currently allowed ambiguity in the ARC > > > > > > > > > >> specification is a much simpler and much better solution. I'm not > > > > > > sure > > > > > > > >> why > > > > >> there's such concern about canonicalizing the format and ordering > of > > > > > > some > > > > > > > >> tag/value pairs. > > > > > > > > > > If you think that's all it would take to make signature headers > > > > > > perfectly > > > > > > > > identical, you will be deeeply disappointed. (Take a look at FWS > in > > > > > > the > > > > > > > > ABNF and all of the other generic ABNF for message headers.) > > > > > > > > > > I think what we've been saying is that the SMTP mail ecosystem has > > > > > > never > > > > > > > > tried to make stuff bit-for-bit reproducible, and even if you could > > > > > > hammer > > > > > > > > on the spec to make super strict rules for one particular header, > it's > > > > > unlikely that the people who are adapting their DKIM code would pay > > > > > attention. > > > > > > > > > > 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 > -- [image: logo for sig file.png] Bringing Trust to Email Peter Goldstein | CTO & Co-Founder peter@valimail.com +1.415.793.5783 --001a1149dfbea54ef1054bcbacfb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Scott,

I will confess to not followi= ng all the details on a regular basis, but
doesn't the paragraph you referenced give a required sequenc= e of multiple
header fields?=C2= =A0 Maybe that's not a problem any more (it's been some years
since I looked), but that definitely = used to be something it was risky to rely
on.

=
No.=C2=A0 Precisely the opposite.=C2=A0 The referenced pa= ragraph in the ARC spec is a set of instructions of how to create an ARC Se= al for a message.=C2=A0 The point of referencing the instructions is to sho= w that the algorithm is already resilient to header re-ordering, and nothin= g being proposed here would change that.

The te= st case comment was based on my understanding that you wanted
deterministic ordering because if the orderin= g wasn't deterministic it would
be too hard to test.=C2=A0 I think that can be managed.

I think there's a misunderstanding here.=C2=A0 = You seem to be under the impression that supporting the current non-determi= nistic behavior can be managed with 'more tests' that can be auto-g= enerated and run against all implementations.=C2=A0 That's not the issu= e.

The non-deterministic ordering requires either:=

1. Implementations that use different tag/value o= rdering/formatting cannot share a test suite.=C2=A0 Signing tests that are = valid for one implementation will not be valid for an implementation using = a different tag/value ordering or formatting.

or

2. The test suite needs to include a 'reference= ' ARC verifier

#1 explicitly fails your requir= ement that "test cases are validated = against multiple=C2=A0implementatio= ns", unless the implementations use the same tag/value canonicalizatio= n.=C2=A0 This thread is simply proposing that we pick one such canonicaliza= tion, and define it in the RFC, so that all ARC implementations share the s= ame canonicalization.

I've discusse= d why I think #2 is a bad idea - it's a lot of work (and it's uncle= ar who will do it), much more fragile and complex, and yields no benefit th= at has been actually identified.

Best,
<= br>
Peter



=

On Tue, Mar 28, 2017 at 5:16 AM, Scott Kitterman <= sklist@kitterman.com> wrote:

On Monday, March 27, 2017 10:30:37 PM Peter Goldstein wrote:
> Scott,
>
> Header reordering is irrelevant to this discussion - the ARC RFC speci= fies
> in some detail how to construct the ARC Seal from the AMS and AAR head= ers -
> https://tools.ietf.org/= html/draft-ietf-dmarc-arc-protocol-02#section-5.2 .
> And the AMS headers have the same behavior as DKIM - header ordering a= nd
> canonicalization is also well-defined, so header re-ordering doesn'= ;t impact
> the signature.=C2=A0 The discussion at hand is literally about the ord= ering and
> formatting of tag/value pairs within the individual ARC headers.
>
> So the only brittleness question is whether existing mail infrastructu= re
> will potentially alter the internal structure of the AMS header or ARC= Seal
> header.=C2=A0 That is...unlikely.=C2=A0 We can conclude it's unlik= ely, because a
> similar alteration of a DKIM signature header would break the DKIM
> signature of forwarded email.=C2=A0 So if DKIM generally works (and it= does), we
> should be able to conclude that specifying ordering/formatting of the<= br> > tag/value pairs in an AMS/ARC header does not represent an increase in=
> brittleness.
>
> I'm not really sure I understand the point regarding the # of test= cases.
> We're not worried about keeping the # of test cases small - we'= ;re
> interested in ensuring that the same test cases will run successfully<= br> > against any valid ARC implementation.=C2=A0 Can you please clarify? >
> And yes, something will probably be developed in Ruby at some point - = but
> it's just as likely to be a de novo effort, as it is a modificatio= n of an
> existing DKIM gem.=C2=A0 There is only 1 pure Ruby DKIM signing gem I&= #39;m aware of
> - https://github.com/jhawthorn/dkim - and it hasn'= ;t had any updates in 2+
> years and lacks verification logic.=C2=A0 So it's a less than idea= l basis for
> developing an ARC gem.
>
> Best,
>
> Peter
>
> On Mon, Mar 27, 20= 17 at 9:49 PM, Scott Kitterman <= sklist@kitterman.com>
>
> wrote:
> > What's more difficult to is identify all the ways that things= get
> > reordered,
> > mangled, etc as they transit the various elements of the mail
> > architecture.
> > If you over specify the allowed order, aren't you risking inc= reasing the
> > brittleness of the solution.
> >
> > If test cases are automatically generated, then they are cheap an= d we
> > shouldn't worry about unduly constraining things to keep the = number
> > small.=C2=A0 As
> > long as, at some point, the test cases are validated against mult= iple
> > implementations, I think it's fine.=C2=A0 If you've got a= handful of
> > implementations, then the risk of them all having the same bug is= pretty
> > low.
> >
> > In addition to Perl, I'd expect something in Ruby to appear i= n due course.
> >
> > Scott K
> >
> > On Monday, March 27, 2017 07:54:43 PM Peter Goldstein wrote:
> > > John,
> > >
> > > I'm familiar with the definition of the FWS in the ABNF,= as well as the
> > > generic definition ABNF for message headers.=C2=A0 I'm a= lso aware of the
> > > challenges with trying to normalize such headers, and how th= at can
> > > impact
> > > email authentication - breaking forwarded DKIM signatures an= d such.=C2=A0 But
> > > none of that is actually relevant here - we are not interest= ed in
> >
> > arbitrary
> >
> > > messages.
> > >
> > > We are interested in creating a set of valid input messages = and ensuring
> > > that these messages are signed in a consistent, reliable way= by any
> > > valid
> > > ARC implementation.=C2=A0 This is an extremely narrow case -= so yes, I do
> >
> > think
> >
> > > the above is basically all it would take to make such signat= ure headers
> > > identical.=C2=A0 Perhaps I'll be disappointed, but based= on the sample
> >
> > messages
> >
> > > I have on hand from existing implementations, that seems unl= ikely.
> > >
> > > As for the hypothetical developers who will be adapting DKIM= libraries
> > > to
> > > do ARC signing, we've been talking about them since M3AA= WG in October
> > > 2015.=C2=A0 So far they haven't materialized.=C2=A0 Hone= stly, it's not even clear
> >
> > to
> >
> > > me that there are that many DKIM libraries out there to adap= t.
> > >
> > > Instead we've seen ~5 implementations (Google, AOL, Dkim= py, OpenARC,
> > > MailerQ), with potential support for implementations in 1-2 = additional
> > > languages (e.g. Perl) probably driven by one or more of the = implementers
> >
> > of
> >
> > > the existing implementations.=C2=A0 It should be relatively = easy to
> > > coordinate
> > > such a change across the small number of existing implementa= tions.
> > >
> > > Best,
> > >
> > > Peter
> > >
> > > On Mon, Mar 27, 2017 at 7:21 PM, John R Levine <johnl@taugh.com> wrote:
> > > > I think tightening up some currently allowed ambiguity = in the ARC
> > > >
> > > >> specification is a much simpler and much better sol= ution.=C2=A0 I'm not
> >
> > sure
> >
> > > >> why
> > > >> there's such concern about canonicalizing the f= ormat and ordering of
> >
> > some
> >
> > > >> tag/value pairs.
> > > >
> > > > If you think that's all it would take to make signa= ture headers
> >
> > perfectly
> >
> > > > identical, you will be deeeply disappointed.=C2=A0 (Tak= e a look at FWS in
> >
> > the
> >
> > > > ABNF and all of the other generic ABNF for message head= ers.)
> > > >
> > > > I think what we've been saying is that the SMTP mai= l ecosystem has
> >
> > never
> >
> > > > tried to make stuff bit-for-bit reproducible, and even = if you could
> >
> > hammer
> >
> > > > on the spec to make super strict rules for one particul= ar header, it's
> > > > unlikely that the people who are adapting their DKIM co= de would pay
> > > > attention.
> > > >
> > > > R's,
> > > > John
> >
> > _______________________________________________
> > dmarc mailing list
> > dmarc@ietf.org
> > https://www.ietf.org/mailman/listinfo/dmar= c

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



--
=
=


3D"logo

Bringing Trust to= Email

Peter Goldstei= n | CTO & Co-Founder

peter@valimail.= com

+1.415.793.57= 83
<= /div>
--001a1149dfbea54ef1054bcbacfb-- From nobody Thu Mar 30 01:21:19 2017 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 B87651293E1 for ; Thu, 30 Mar 2017 01:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 nMPrqBZnsG6y for ; Thu, 30 Mar 2017 01:21:15 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::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 9C77B12922E for ; Thu, 30 Mar 2017 01:21:14 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id s68so45667884vke.3 for ; Thu, 30 Mar 2017 01:21:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YzkblhQ2Bnlh62R0uZW426K5ypaoAqDIWAGv681iiC4=; b=CQQ/DAfLso8Km3zQPoFurq9Cz8pzXt2hR6hBuiznC3GCbFMErN4IPRhEt7ktmHVSAs ir/o9/SV6n4Y1QI5Q+UvuXUxIq5lNZKUzZZs5oxCj5I35LypTUc/yQD8ZndCGDaHXrtU zDqwNCKO9ldz3bvruuCMe0JRX3AAJ7o64wwgK44ZZu5L8jYzm7BX02UW0UrpbjAjhP9P 2hhNfMJmPTlP6lGQaPTAQ4IvUIV7muc2XA9CkoyuzfR40FIbMAJ6aWSTZV8TqOFLsTQo hwkh64a/Oy8SzL2DIZQQsrd3gstemrweyCAPxSgnE1WXHUvne3+RsPTauXYqqcrZ0MgL mGhg== 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=YzkblhQ2Bnlh62R0uZW426K5ypaoAqDIWAGv681iiC4=; b=akPy/QcpbyTGNm3uGK/zLGPvn84x1qPpNwW1w/+G4zkvHcyf5a2ZZNOsOIGONsj2jQ pXhF/A6buNDv8dJ4dRECR5XJSkopEAX6QTpZHwI1CKS1WSxCIA4L9UBQLdTA3wScWh06 Xcg+kMdf0Eq5kzXFXO8jbwH8dH3AZuQUFOV5CSpyq2ZV1LRzIUKovp4wi1iA9J0YcgPt Di02EN8hSeChVHmcCTqhruzcrZJhl59U7qD0sSGhwWdkjlOfbDZ157m5dkeIerbeb7Gz iBHoHAUXgzAF5AX1P+YbNoL7gL62FP4cEuv9mc2bleSbh+pUd9Wv7t4/Jenlkl6kqMHn CSQQ== X-Gm-Message-State: AFeK/H2j9qiWFAE2CW+fKUt1dOM4X/cwSCTsJgmtwEMufuf37LkxPC8K6BxmpMCffY3kRlx3BiE2STUzQDwiRg== X-Received: by 10.176.92.13 with SMTP id q13mr2902405uaf.149.1490862073525; Thu, 30 Mar 2017 01:21:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.130.70 with HTTP; Thu, 30 Mar 2017 01:21:12 -0700 (PDT) In-Reply-To: References: <20170324212304.85346.qmail@ary.lan> From: "Murray S. Kucherawy" Date: Thu, 30 Mar 2017 03:21:12 -0500 Message-ID: To: Gene Shuman Cc: John Levine , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=f403043614164d3b14054bee607d Archived-At: Subject: Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 30 Mar 2017 08:21:18 -0000 --f403043614164d3b14054bee607d Content-Type: text/plain; charset=UTF-8 I have to catch up on the rest of this thread still, but I wanted to chime in here to get started: On Sun, Mar 26, 2017 at 5:23 PM, Gene Shuman wrote: > Ah that had slipped my mind & is a good point. However, I think the issue > here is generally that ARC is more complex protocol than DKIM and therefore > it's more important to reduce ambiguity & increase standardization while we > have the chance. I think this is generally a good idea from a security > perspective, however this is mostly relevant with respect to testing & > validation, as ensuring cross-compatibility is a much bigger challenge. > It's even more important than it was with DKIM to have a test suite that > can verify signing behavior. If we don't agree on any sort of standard, a > test suite will need to select a preferred format for the ARC headers & > will fail all implementations that don't meet this form. We've discussed > this with Murray, and he agrees with this conclusion. > I agree that it's impossible to design a signer test suite that confirms correct output, without doing crytpo checks of its own with a known-good verifier, unless we nail down the syntax the output will use. For this to work, we'd have to mandate a lot of things, including at least these: - the order of the tags as presented to the hash algorithm - which tags will be present (note that many are not required, including "t=") - the specific values they will all contain - for ARC-Message-Signature, which canonicalization will be used - the spacing between the tags; since "relaxed" header canonicalization compresses spaces but does not add them, "a=foo;b=foo" is not the same as "a=foo; b=foo", but "a=foo;\r\n\tb=foo" is - similarly, how signature fields will be wrapped (if at all) - what signing key will be used - the body content to be signed - the header content to be signed - the set of header fields that will be signed (which becomes "h=") It certainly removes many variables to nail down a test in this way, and it's faster to run tests that don't require crypto functions or a known-good verifier to confirm. To be honest, I can't remember if we ever considered this sort of approach during the development of DKIM. I don't think we did, and after an admittedly brief search I couldn't find anything in the archives. I think when canonicalization was developed, it was plain that tag order wouldn't matter to the verifier, and that was sort of the end of it. The obvious counter-argument here is that DKIM has been successful without ever being strict about what a signature looks like. Our interop event in Dallas way-back-when consisted solely of implementer "A" sending mail at implementer "B" and seeing what passed and what failed, and digging into the failure cases to see if they're bugs in code or bugs in the specification. Independent of interop events, various implementers also set up auto-responders that would verify an arriving message, then re-sign it and send it back so the originator can test its verification. Any failure compelled us to implement debugging tools and exchange information so we could work out the kinks, either in the spec or in the implementation(s), until all participants were consistent. We reached a point where we had organically developed a bunch of "good" implementations based on the fact that they all appeared to agree with each other. Since the canonicalization algorithms in ARC are the same as the ones in DKIM, and the tag=value and key syntaxes are also the same, we've got a lot of concepts and code being recycled here. I'm not sure how much new fragility we should really be concerned about. I'll know more as I complete my implementation. Paul's point that video and security protocols are traditionally much more rigid is of course quite true, and I presume he's thinking of things like the headers of DNS, IP, TCP, etc. But I note that those are based on a different model where fields have fixed sizes and predictable positions. That's antithetical to email, however, where the fields come in arbitrary order, and the only way you know what a given header means is that its name precedes its value. There can even be duplication. And from one MTA to another, header fields can be added, removed, or rearranged. That's impossible in a rigid header definition, so it's perhaps no surprise that this community isn't exactly warm to the idea. The question, then, is whether this is a desirable path to follow: Is the value of a quick evaluation of a deterministic signer high enough to surrender the flexibility of DKIM style of tag spacing and ordering? And, perhaps more importantly, what's the cost of being wrong later? -MSK --f403043614164d3b14054bee607d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have to catch up on the rest of this thread still, but I= wanted to chime in here to get started:

On Sun, Mar 26, 2017 a= t 5:23 PM, Gene Shuman <gene@valimail.com> wrote:
Ah that had slipped my mind & is= a good point.=C2=A0 However, I think the issue here is generally that ARC = is more complex protocol than DKIM and therefore it's more important to= reduce ambiguity & increase standardization while we have the chance.= =C2=A0 I think this is generally a good idea from a security perspective, h= owever this is mostly relevant with respect to testing & validation, as= ensuring cross-compatibility is a much bigger challenge.=C2=A0 It's ev= en more important than it was with DKIM to have a test suite that can verif= y signing behavior.=C2=A0 If we don't agree on any sort of standard, a = test suite will need to select a preferred format for the ARC headers &= will fail all implementations that don't meet this form.=C2=A0 We'= ve discussed this with Murray, and he agrees with this conclusion.

I agree that it's impossible to design a = signer test suite that confirms correct output, without doing crytpo checks= of its own with a known-good verifier, unless we nail down the syntax the = output will use.=C2=A0 For this to work, we'd have to mandate a lot of = things, including at least these:

- the order of the tags as presented to the hash algorithm
- which tags will be present (note that many are n= ot required, including "t=3D")
- the specific values they will all contain
- for ARC-Message-Signature, which canonicalization will be used
=
- the spacing between the tags; since &quo= t;relaxed" header canonicalization compresses spaces but does not add = them, "a=3Dfoo;b=3Dfoo" is not the same as "a=3Dfoo; b=3Dfoo= ", but "a=3Dfoo;\r\n\tb=3Dfoo" is
- similarly, how signature fields will be wrapped (if at all)
=
- what signing key will be used
<= div class=3D"gmail_quote">- the body content to be signed
- the header content to be signed
- the set of header fields that will be signed (which becomes= "h=3D")

It certainly rem= oves many variables to nail down a test in this way, and it's faster to= run tests that don't require crypto functions or a known-good verifier= to confirm.=C2=A0 To be honest, I can't remember if we ever considered= this sort of approach during the development of DKIM.=C2=A0 I don't th= ink we did, and after an admittedly brief search I couldn't find anythi= ng in the archives.=C2=A0 I think when canonicalization was developed, it w= as plain that tag order wouldn't matter to the verifier, and that was s= ort of the end of it.

The obv= ious counter-argument here is that DKIM has been successful without ever be= ing strict about what a signature looks like.=C2=A0 Our interop event in Da= llas way-back-when consisted solely of implementer "A" sending ma= il at implementer "B" and seeing what passed and what failed, and= digging into the failure cases to see if they're bugs in code or bugs = in the specification.=C2=A0 Independent of interop events, various implemen= ters also set up auto-responders that would verify an arriving message, the= n re-sign it and send it back so the originator can test its verification.= =C2=A0 Any failure compelled us to implement debugging tools and exchange i= nformation so we could work out the kinks, either in the spec or in the imp= lementation(s), until all participants were consistent.=C2=A0 We reached a = point where we had organically developed a bunch of "good" implem= entations based on the fact that they all appeared to agree with each other= .

Since the canonicalization algori= thms in ARC are the same as the ones in DKIM, and the tag=3Dvalue and key s= yntaxes are also the same, we've got a lot of concepts and code being r= ecycled here.=C2=A0 I'm not sure how much new fragility we should reall= y be concerned about.=C2=A0 I'll know more as I complete my implementat= ion.

Paul's point that video and security protocols are traditionally much more=20 rigid is of course quite true, and I presume he's thinking of things li= ke the headers of DNS, IP, TCP, etc.=C2=A0 But I note that those are based = on a=20 different model where fields have fixed sizes and predictable=20 positions.=C2=A0 That's antithetical to email, however, where the field= s come in=20 arbitrary order, and the only way you know what a given header means is=20 that its name precedes its value.=C2=A0 There can even be duplication.=C2= =A0 And from one MTA to another, header fields can be=20 added, removed, or rearranged.=C2=A0 That's impossible in a rigid heade= r=20 definition, so it's perhaps no surprise that this community isn't e= xactly warm to the idea.

The question, then, is whether this is a=20 desirable path to follow: Is the value of a quick evaluation of a determini= stic signer high enough to surrender the flexibility of DKIM style of tag s= pacing and ordering?=C2=A0 And, perhaps more importantly, what's the co= st of being wrong later?

-MSK
--f403043614164d3b14054bee607d-- From nobody Thu Mar 30 01:52:33 2017 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 01BEC12922E for ; Thu, 30 Mar 2017 01:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 27QYRCD7FDXR for ; Thu, 30 Mar 2017 01:52:28 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83A60128B4E for ; Thu, 30 Mar 2017 01:52:28 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id z204so46519986vkd.1 for ; Thu, 30 Mar 2017 01:52:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/ohxSUpV1zv2mjxZbxoHKfKDU61xUmNI/mUm8eJp4j4=; b=dbsbFPqZYRyVT8MTVnPawb1FobQU2vuR4eW75q3zpZLl+ovDfqlWj/t6WRfNDYBhC6 pIThYymcALpSOlS0q8JmDmjyMS9g+CagkkEWd33XZqXGozjbKZLOgNbukXgehC21EeEB jCEHbAnK94gncy+pWHCr2As9C0LI2du2vpb1IsOtp7f9a5BJOqgC1mbz3iNDB042gzTd fSAb7EfSwqy0F092OQCmKJTUjlTvcUEGw9Mf9ANHbTbLZELohtDgmObuwhtpiD/fY9aC tfcY/RsDqWms3TCDc/DYnERcGds0VnVJDcACb3aile/DzNHi24M1S1dFhwGoTuVtDCz9 rH2w== 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=/ohxSUpV1zv2mjxZbxoHKfKDU61xUmNI/mUm8eJp4j4=; b=N2jimuPsXG6piqaoi24UJJzYj3g7v/hgqULvD8aK3iOfl+1kuHX4+WOdfYh6jaVtq+ CAO6ZmOXWe/cRCRboiiu81vAHuCzUhnPs/vuYfVfQVxRhDVxZCVwOq2dBzZwTl+HrZow XxMTJnwBOvyTKCOtidCDuM3mjFrG9UiUuyf5I8TYj8BGnd36ejbXki4lAY/iI8IjVyHd gOtv/mFzslGz3pmf1osJ77UktpTPuhkGHXnoIk294KzlDvIfP13gTW8VPFFxGPyh9tuO uY4SDh/KhGL9XCS8uOAAezuuZ/tdml614l2DDL5AfE+FDVr1qkA6QMCpKqc09jq7WeDy E+bA== X-Gm-Message-State: AFeK/H3Ds2I+3iydAVGM2SdH1Umt4GTMrniblthdroXZ0PuEVTke3LruKV/ub0Y26k/ICUF5BpbjOwUkmqLjYw== X-Received: by 10.31.73.6 with SMTP id w6mr2290519vka.137.1490863947467; Thu, 30 Mar 2017 01:52:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.130.70 with HTTP; Thu, 30 Mar 2017 01:52:26 -0700 (PDT) In-Reply-To: References: <20170324212304.85346.qmail@ary.lan> From: "Murray S. Kucherawy" Date: Thu, 30 Mar 2017 03:52:26 -0500 Message-ID: To: Peter Goldstein Cc: John R Levine , dmarc , Gene Shuman Content-Type: multipart/alternative; boundary=001a114db10aff50e2054beecf5b Archived-At: Subject: Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 30 Mar 2017 08:52:31 -0000 --001a114db10aff50e2054beecf5b Content-Type: text/plain; charset=UTF-8 On Sun, Mar 26, 2017 at 11:25 PM, Peter Goldstein wrote: > Second, the premise that "it's not hard to write test code..." is simply > not true. What would be required to actually write such code would be > either a) pick a preferred ordering/formatting for these tags, and only > have the tests pass for that ordering or b) include a complete ARC > verifying system in the test code. The first is what OpenDKIM did for its > specs (see below). The latter is possible, but seems ill-advised for a > test suite. > OpenDKIM does both. At some point when it was still "dkim-milter", when it came time to write tests (because at one point there were none), I mainly wanted to assure that commits made didn't cause any regressions; correctness could be affirmed in other ways like at interop events or through other implementers' auto-responders. So I picked a tag ordering I liked, generated a bunch of signatures with it, and then wrote tests that did two things with them: 1) Confirmed that the signing code produces those specific signatures given fixed inputs (timestamp, key, selector, domain, canonicalization, etc.). This was inherently a tautology at the time I generated them of course, but my goal was just to ensure no regressions were introduced. I didn't know for sure that the output was right, but I knew it would be consistent. 2) Since OpenDKIM conveniently includes a verifying capability, there are some tests that instantiate the library to produce a signature, then re-instantiate the library to verify it. Obviously this doesn't prove that its signatures are correct, but they do prove that its code is consistent with itself, and again that changes made later don't break verifying. None of this was done with an eye toward making my test suite applicable to other implementations. It's only for my own. What we're talking about here is different: coming up with tests that could be applied to any implementation, not to a specific one, so long as they agree on fixed syntax and inputs. To see that this is the case, it's useful to look at two earlier email > standards and their corresponding test suites. SPF has a language-agnostic > test suite (http://www.openspf.org/Test_Suite) that makes it easy to test > implementations in any language. I've done it myself, and it requires > minimal effort - https://github.com/ValiMail/ > coppertone/tree/master/spec/open_spf. I can tell you from personal > experience that the test suite was really helpful in ensuring the > implementation was correct in all cases. > An inherent difference between SPF and DKIM is that the order of the tokens in SPF is significant. In DKIM, reordering tags changes nothing about the meaning of the header field, though obviously it alters the resulting header hash. In contrast, the order of tags in SPF is necessarily specified. -MSK --001a114db10aff50e2054beecf5b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Mar 26, 2017 at 11:25 PM, Peter Goldstein <peter= @valimail.com> wrote:
Se= cond, the premise that "it's not hard to write test code..." = is simply not true.=C2=A0 What would be required to actually write such cod= e would be either a) pick a preferred ordering/formatting for these tags, a= nd only have the tests pass for that ordering or b) include a complete ARC = verifying system in the test code.=C2=A0 The first is what OpenDKIM did for= its specs (see below).=C2=A0 The latter is possible, but seems ill-advised= for a test suite.
=C2=A0
OpenDKIM doe= s both.=C2=A0 At some point when it was still "dkim-milter", when= it came time to write tests (because at one point there were none), I main= ly wanted to assure that commits made didn't cause any regressions; cor= rectness could be affirmed in other ways like at interop events or through = other implementers' auto-responders.=C2=A0 So I picked a tag ordering I= liked, generated a bunch of signatures with it, and then wrote tests that = did two things with them:

1) Confirmed that the signing c= ode produces those specific signatures given fixed inputs (timestamp, key, = selector, domain, canonicalization, etc.).=C2=A0 This was inherently a taut= ology at the time I generated them of course, but my goal was just to ensur= e no regressions were introduced.=C2=A0 I didn't know for sure that the= output was right, but I knew it would be consistent.

2) = Since OpenDKIM conveniently includes a verifying capability, there are some= tests that instantiate the library to produce a signature, then re-instant= iate the library to verify it.=C2=A0 Obviously this doesn't prove that = its signatures are correct, but they do prove that its code is consistent w= ith itself, and again that changes made later don't break verifying.
None of this was done with an eye toward making my test suite applicab= le to other implementations.=C2=A0 It's only for my own.=C2=A0 What we&= #39;re talking about here is different: coming up with tests that could be = applied to any implementation, not to a specific one, so long as they agree= on fixed syntax and inputs.

To see that th= is is the case, it's useful to look at two earlier email standards and = their corresponding test suites.=C2=A0 SPF has a language-agnostic test sui= te (http://= www.openspf.org/Test_Suite) that makes it easy to test implementat= ions in any language.=C2=A0 I've done it myself, and it requires minima= l effort -=C2=A0https://github.com/ValiMail/copper= tone/tree/master/spec/open_spf.=C2=A0 I can tell you from personal= experience that the test suite was really helpful in ensuring the implemen= tation was correct in all cases.

An inherent difference between SPF and DKIM is that the order of the toke= ns in SPF is significant.=C2=A0 In DKIM, reordering tags changes nothing ab= out the meaning of the header field, though obviously it alters the resulti= ng header hash.=C2=A0 In contrast, the order of tags in SPF is necessarily = specified.

-MSK
--001a114db10aff50e2054beecf5b-- From nobody Thu Mar 30 01:54:06 2017 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 4DBAB12922E for ; Thu, 30 Mar 2017 01:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 5_y3_1c_k1zn for ; Thu, 30 Mar 2017 01:54:02 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::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 933D5128B4E for ; Thu, 30 Mar 2017 01:54:02 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id r69so46423168vke.2 for ; Thu, 30 Mar 2017 01:54:02 -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=iJJ4IRAmn4ZWoxEoRePRIbhuFOoION4RVFnm1M1QAHw=; b=NCQjjBnJgGi8oetTD/XcLZjxdtYZlSQfvu/qc5pfsTDPELGMaEYNwYkWAmLJwvWh74 iuJHemG3Qj8Ko40SK+8M8jMbRouVJ5sf/bqwPMNCAeDBd5kH5K/8SORN9dmBoR9mr/ci q3/mfwjRZ+EAbhTYo8LyLzuFgyhTRSc+JPx6vMPahwaFNMQSzapgOuaGTEgtvqSrfudu qAMCGiRuuOXDXh0pNA1jtwcLA4e/+c1FSgyrRPXnUP9t+Y5tPo0BWD2+bB4zj6zBybT0 vj81hkAQubkc5oU4v/JkoMCULwHwuhLx8az/6s29IC7L3dPqnIVln9M0sinLoJxEi6Cv Qpkw== 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=iJJ4IRAmn4ZWoxEoRePRIbhuFOoION4RVFnm1M1QAHw=; b=pZC8r5r3BtEg4Nvc4RclM19Cx5AYn52b0Wxlg0f4IvYwPgfOyZ4EHdV34NouCEl9Qk SKw1JwEi+TR9ArH9J2ZiIThqOCxcBXxlMDA+MVvuAsvRDCKxDlbYsFUkpo0Hfq63XeUG NaxYuLNDWFMx7iEpPeXFrdLJWa80sqhu4d1l8SttzF3KbU9BHIpgXt8Qq1BEFwCcsQy2 oYbcD/1dkQdOYgJMgcjuPDf3hrptYwVX+avYdh8I2x0wsr3rxJBaIrJuM7k9RfSEU/rb lekzeiLMXn/x3xykNVsBxC+mNEtV41fiDJS6NOFNJDgZ7zerJHpHx42siHDa8r0bm7rR LyZw== X-Gm-Message-State: AFeK/H0nCrMNc6A82RroayzgOZneyE9Q12LFPdUGuiD1Uz1tUMGYmvVD7CHUHVdvUKkCtMR3pPpYW8zP3YzJ5g== X-Received: by 10.159.55.227 with SMTP id q90mr2970337uaq.8.1490864041709; Thu, 30 Mar 2017 01:54:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.130.70 with HTTP; Thu, 30 Mar 2017 01:54:01 -0700 (PDT) In-Reply-To: References: <20170324212304.85346.qmail@ary.lan> From: "Murray S. Kucherawy" Date: Thu, 30 Mar 2017 03:54:01 -0500 Message-ID: To: Brandon Long Cc: Peter Goldstein , "dmarc@ietf.org" , John R Levine , Gene Shuman Content-Type: multipart/alternative; boundary=94eb2c04c8629d57d2054beed504 Archived-At: Subject: Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 30 Mar 2017 08:54:04 -0000 --94eb2c04c8629d57d2054beed504 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 27, 2017 at 1:06 PM, Brandon Long wrote: > What does validating the exact signature generated benefit us over just > verifying that the signature verifies? > The most obvious benefit I can think of is that the output of signing is entirely deterministic. You could test it with strcmp() on a disconnected computer, rather than invoking a complete ARC verifier that might need DNS and would have to invoke crypto functions. -MSK --94eb2c04c8629d57d2054beed504 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Mar 27, 2017 at 1:06 PM, Brandon Long <blong@googl= e.com> wrote:
What does valida= ting the exact signature generated benefit us over just verifying that the = signature verifies?

The most obvious = benefit I can think of is that the output of signing is entirely determinis= tic.=C2=A0 You could test it with strcmp() on a disconnected computer, rath= er than invoking a complete ARC verifier that might need DNS and would have= to invoke crypto functions.

= -MSK
--94eb2c04c8629d57d2054beed504-- From nobody Thu Mar 30 01:57:46 2017 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 64290129564 for ; Thu, 30 Mar 2017 01:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 kZTDa_lPvnmY for ; Thu, 30 Mar 2017 01:57:43 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::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 85FE31293FD for ; Thu, 30 Mar 2017 01:57:43 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id z204so46645734vkd.1 for ; Thu, 30 Mar 2017 01:57: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=Fa2VgX5O7sfD4Aam7XpbDK3M4esqu9MSDBJ/+bKxzcE=; b=HasSGPHc1rydL5uVK13wQMwgzy69AzrphqYtCM+sW7W7X8PQqHHuxQN6r3QfEFKTYO 3Ev8FtktalcSuPp4OO+1/RCVYhSBdIaAKUWJXCvtn8XfJL8ZynArZKBqLP1FcCM7GKOe XoAdeP+7VD3GanShsAcNkGRJE0X4zpRgXaslTVcD/JLcWAoHF0Mzbpacx9Bw1joan0x8 QwwyLpz/RireEspOKffTY33dbWLRyXBWxrWIbXxxtL6olG1lh5UG1VyDWmBaP/0U17R/ +yr2YUqkefJvcD3HYLx6mtiG5ePjukfKok+bpWZV0rSfVhAQv5Ytonvacr1neu87kaFX 4XEQ== 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=Fa2VgX5O7sfD4Aam7XpbDK3M4esqu9MSDBJ/+bKxzcE=; b=oQR67oYR0nUZgSw2fU3OCIYOFOEE/vJJ10etaszCnapbxdOdgjIexufBA2RgrvZFUA lJfmuV/0StRhy0++lXmdxV+RGHw2l+GrqjkdG9K5mO1oGSs2PQVz57pa4kAAuV03qO6u LkYGxjjjrLcVx/uOOak2LyVG2TiTHqi9iDZmaZFJFNBsQCsWI3sHF8DR40+NrlXed4mb Ky1QS6KGJxN0uU5TvDLznb/3IVWYgd6iVMIXLPyXDTFpT8Fi0LzPs60W/eLUsoJKXQdS MHX0V+JNzVlIwWZM/g/DSKCQHF4f9aj1AmjPI9r4UL0FtBTbPqxcM9RoXP3ladoRApD0 3q+A== X-Gm-Message-State: AFeK/H3LUOJWmNBmKCOm142VGr8WW7wpQ5CLQ+wQ+lugND479hXD3lFLFUcke+x1PWcVgIl4JFTZrNJ5aoeBbw== X-Received: by 10.31.76.129 with SMTP id z123mr2839603vka.117.1490864262655; Thu, 30 Mar 2017 01:57:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.130.70 with HTTP; Thu, 30 Mar 2017 01:57:41 -0700 (PDT) In-Reply-To: <2978391.eJVbVTHBlo@kitterma-e6430> References: <2978391.eJVbVTHBlo@kitterma-e6430> From: "Murray S. Kucherawy" Date: Thu, 30 Mar 2017 03:57:41 -0500 Message-ID: To: Scott Kitterman Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a114dd13ec8b49c054beee291 Archived-At: Subject: Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 30 Mar 2017 08:57:45 -0000 --001a114dd13ec8b49c054beee291 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 27, 2017 at 11:49 PM, Scott Kitterman wrote: > What's more difficult to is identify all the ways that things get > reordered, > mangled, etc as they transit the various elements of the mail architecture. > If you over specify the allowed order, aren't you risking increasing the > brittleness of the solution. > I think Peter's proposal (and he can correct me if I'm wrong) is only to constrain signers. Verifiers are still expected to handle everything weird that the infrastructure might do. > If test cases are automatically generated, then they are cheap and we > shouldn't worry about unduly constraining things to keep the number > small. As > long as, at some point, the test cases are validated against multiple > implementations, I think it's fine. If you've got a handful of > implementations, then the risk of them all having the same bug is pretty > low. > That sort of organic validation of implementations seemed to work for DKIM. The unknown here is whether ARC will be as successful with that model. -MSK --001a114dd13ec8b49c054beee291 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Mar 27, 2017 at 11:49 PM, Scott Kitterman <skl= ist@kitterman.com> wrote:
What's more diffic= ult to is identify all the ways that things get reordered,
mangled, etc as they transit the various elements of the mail architecture.=
If you over specify the allowed order, aren't you risking increasing th= e
brittleness of the solution.

I think Pe= ter's proposal (and he can correct me if I'm wrong) is only to cons= train signers.=C2=A0 Verifiers are still expected to handle everything weir= d that the infrastructure might do.
=C2=A0
If test cases are automatically generated, then they are cheap and we
shouldn't worry about unduly constraining things to keep the number sma= ll.=C2=A0 As
long as, at some point, the test cases are validated against multiple
implementations, I think it's fine.=C2=A0 If you've got a handful o= f
implementations, then the risk of them all having the same bug is pretty lo= w.

That sort of organic validation of i= mplementations seemed to work for DKIM.=C2=A0 The unknown here is whether A= RC will be as successful with that model.

-MSK
<= /div>
--001a114dd13ec8b49c054beee291-- From nobody Thu Mar 30 07:12:34 2017 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 02A4E12950E for ; Thu, 30 Mar 2017 07:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 3ZlUp5CFBMbs for ; Thu, 30 Mar 2017 07:12:31 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (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 ABC751294F5 for ; Thu, 30 Mar 2017 07:12:31 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QCKR5UH6C000TSW6@mauve.mrochek.com> for dmarc@ietf.org; Thu, 30 Mar 2017 07:07:11 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QCI9YTYNS00003XB@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Thu, 30 Mar 2017 07:07:07 -0700 (PDT) From: ned+dmarc@mrochek.com Cc: Scott Kitterman , "dmarc@ietf.org" Message-id: <01QCKR5S5OXK0003XB@mauve.mrochek.com> Date: Thu, 30 Mar 2017 07:01:01 -0700 (PDT) In-reply-to: "Your message dated Thu, 30 Mar 2017 03:57:41 -0500" References: <2978391.eJVbVTHBlo@kitterma-e6430> To: "Murray S. Kucherawy" Archived-At: Subject: Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 30 Mar 2017 14:12:33 -0000 > On Mon, Mar 27, 2017 at 11:49 PM, Scott Kitterman > wrote: > > What's more difficult to is identify all the ways that things get > > reordered, > > mangled, etc as they transit the various elements of the mail architecture. > > If you over specify the allowed order, aren't you risking increasing the > > brittleness of the solution. > > > I think Peter's proposal (and he can correct me if I'm wrong) is only to > constrain signers. Verifiers are still expected to handle everything weird > that the infrastructure might do. This proposal creates a situation where verifiers are required to support something that no compliant signer will generate. The result will be that a test suite with reasonable coverage cannot be generated using compliant software. And since most people are not going to bother to create an incompliant signer specifically for purposes of testing, if anything this will create, rather than elimnate, interoperability problems. > > If test cases are automatically generated, then they are cheap and we > > shouldn't worry about unduly constraining things to keep the number > > small. As > > long as, at some point, the test cases are validated against multiple > > implementations, I think it's fine. If you've got a handful of > > implementations, then the risk of them all having the same bug is pretty > > low. > > > That sort of organic validation of implementations seemed to work for > DKIM. The unknown here is whether ARC will be as successful with that > model. Exactly. And given the success of the approach with DKIM, the burden is on those proposing to use a different model for ARC to explain why it will work better. And note that "this kind of test becomes possible" is not sufficient. All kinds of tests become possible when you add constraints - the question is what sort of real world problem will those additional tests find. Ned From nobody Thu Mar 30 09:10:37 2017 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 211F5129613 for ; Thu, 30 Mar 2017 09:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9YIOvyvOKbh for ; Thu, 30 Mar 2017 09:10:27 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D3CA129631 for ; Thu, 30 Mar 2017 09:10:24 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id n21so43485396qta.1 for ; Thu, 30 Mar 2017 09:10:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ght8yUsyWucTAjO/oZQMFKf2GvcrYKqgvtY9am4lBuI=; b=VMQowgG74hMVpEOrTdDLY4cILF7GxRa8BlNaTFSWXcPogGf5TSV9a21o7bMYSKb/zF jc22nSPn/2C81225HI7/lGQMincvsTF8SpZxntJ1SZ5GhwHCfygNtT4r45ZaAXOcTPQQ h7WKuBakOKR0GqYVqyAbmfAZ6zy2YD2qgXBTX9sPrk8L6QKa12oBP1KJRf3yMyNgfzuZ U+iUyXXMp0EAFyS3F18WpCv16HGsn3eUqOKnatRzaTqDhK6rnbz72DA+Vh1g15NPe1SM qzOuviXeKaFspJYJRjIn0FCeI7Mf9v1ApAksRNh1e0zBXDT+cV0+FOWooyVpT+C3MEvu 80nw== 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=ght8yUsyWucTAjO/oZQMFKf2GvcrYKqgvtY9am4lBuI=; b=LTpPYEr4ZBXoJAsZedO5yRj1HVUhbvG6kZVDKgPsjMdqixwtuy1lh1VjrW8SwcpUCE hu9ySQah2PaIUQpOOESZdfqU6F1lPp8JavDpufRZEglQ6EoTgXxrAPmTrW99KfaQkQ8y gsjg5diiLFakhgRAA2aug7G7dRgeXKVk1zPH7D+ostXbjnVmY0tdANd2gyI/KOqK0qkS E6mXq7QPbiilc68MRyhm3TnxRHgbZ78W87seJ7yw4dH/zQEncVMrJqCYKWyhbNb2GuDZ MYTkI7lRODWcVcCDWNdIJf+9lXJxdLdusPx06RmKqjrjeq4ur3rNZE2Uk9ZxGV1Vc+kW 108w== X-Gm-Message-State: AFeK/H1CsY9hpv45yGCd/jEz5ouwIXlpR5T387lAxgBjUUyua/2k0uhm5NSkqGpmCoiIk6VUXx1hOl6XjkdMbg== X-Received: by 10.200.35.184 with SMTP id q53mr527744qtq.235.1490890223414; Thu, 30 Mar 2017 09:10:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.141.207 with HTTP; Thu, 30 Mar 2017 09:10:22 -0700 (PDT) In-Reply-To: References: <20170324212304.85346.qmail@ary.lan> From: Peter Goldstein Date: Thu, 30 Mar 2017 09:10:22 -0700 Message-ID: To: "Murray S. Kucherawy" Cc: Gene Shuman , "dmarc@ietf.org" , John Levine Content-Type: multipart/alternative; boundary=001a113f49e82aa89d054bf4ee37 Archived-At: Subject: Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 30 Mar 2017 16:10:31 -0000 --001a113f49e82aa89d054bf4ee37 Content-Type: text/plain; charset=UTF-8 > > I agree that it's impossible to design a signer test suite that confirms > correct output, without doing crytpo checks of its own with a known-good > verifier, unless we nail down the syntax the output will use. Great. :) I wasn't sure there was agreement on that in the wider thread. > For this to work, we'd have to mandate a lot of things, including at least > these: > - the order of the tags as presented to the hash algorithm > - which tags will be present (note that many are not required, including > "t=") > - the specific values they will all contain > - for ARC-Message-Signature, which canonicalization will be used > - the spacing between the tags; since "relaxed" header canonicalization > compresses spaces but does not add them, "a=foo;b=foo" is not the same as > "a=foo; b=foo", but "a=foo;\r\n\tb=foo" is > - similarly, how signature fields will be wrapped (if at all) > - what signing key will be used > - the body content to be signed > - the header content to be signed > - the set of header fields that will be signed (which becomes "h=") > It certainly removes many variables to nail down a test in this way, and > it's faster to run tests that don't require crypto functions or a > known-good verifier to confirm. To be honest, I can't remember if we ever > considered this sort of approach during the development of DKIM. I don't > think we did, and after an admittedly brief search I couldn't find anything > in the archives. I think when canonicalization was developed, it was plain > that tag order wouldn't matter to the verifier, and that was sort of the > end of it. So while it is true for a given test case you would need to constrain all of these items, this is a much larger list than would need to be specified as part of the proposal under consideration. Many of these items are already constrained by the controlling RFC (ARC or DKIM) and the other values specified in the signature. For example, the order in which different header fields are combined and hashed is defined as a function of the tag/value pairs in the signature (i.e in DKIM signature the 'b' value is impacted by the choice of values for the 'a', 'c','h', etc. tag values). That ordering is therefore an input to the test case. The input message content (headers + body), the signing key(s), etc. would all also be input to a particular test case. A test suite should handle this by having test cases that exercise the library with different inputs that give good coverage across allowed variations. That has the side benefit of allowing the test suite implementer(s) to easily develop targeted test cases that cover those specific variations in isolation, making it easier to find bugs. That said, some of these items in the list (intertag spacing, required tags, canonical values for some of the tags) would need to be constrained as part of this proposal. This is clearly a change, but it's a change to a draft standard that has a small # of implementers and should be relatively easy to lock down. And I think it's far less of a change than some others on this list do. The obvious counter-argument here is that DKIM has been successful without > ever being strict about what a signature looks like. ... We reached a > point where we had organically developed a bunch of "good" implementations > based on the fact that they all appeared to agree with each other. I think the bigger point being argued is that DKIM has been successful without ever having a global test suite, because that's the impact of not making this choice (or committing to a global reference implementation). Which is mostly true, but frankly not entirely true. I'm aware of at least two major vendors who have production DKIM signing implementations with edge case bugs that would've been caught by such a suite. Those implementations made it through development, passed whatever implementation specific test cases the developers built, and made it to production. That's what a good test suite helps you avoid. Since the canonicalization algorithms in ARC are the same as the ones in > DKIM, and the tag=value and key syntaxes are also the same, we've got a lot > of concepts and code being recycled here. I'm not sure how much new > fragility we should really be concerned about. I'll know more as I > complete my implementation. Paul's point that video and security protocols are traditionally much more > rigid is of course quite true, and I presume he's thinking of things like > the headers of DNS, IP, TCP, etc. But I note that those are based on a > different model where fields have fixed sizes and predictable positions. > That's antithetical to email, however, where the fields come in arbitrary > order, and the only way you know what a given header means is that its name > precedes its value. There can even be duplication. And from one MTA to > another, header fields can be added, removed, or rearranged. That's > impossible in a rigid header definition, so it's perhaps no surprise that > this community isn't exactly warm to the idea. I'm assuming that I'm Paul. :) I am thinking of protocols like DNS, IP, TCP, but also standards that are higher up the stack like some video protocols. The latter standards often allow large scale re-ordering of the individual chunks and streams of the video, but usually have byte level constraints on the content of those chunks. In my view that's exactly analogous to what I'm proposing here. I'm also recognizing that, once a standard has a binary component (i.e. hashes), the level of flexibility that's being claimed no longer actually exists. As a specific example, take any email message you like that has passed DKIM. Insert a single additional space between any two tags/value in a passing DKIM signature. The message now fails DKIM. That means the semantic content of the message (and more importantly, how receivers will treat it) will change. There seems to be a lot of confusion in this thread about the difference between strictly specifying fields inside a single new header, and changes that cross headers. None of the above mentioned changes to the header set - adding, deleting, duplicating, etc. - is impacted in any way by the proposal under discussion. ARC already needs to handle those cases for the construction of the ARC seal, and much of the complexity of ARC is around canonicalizing the header set (specifying an order, eliminating duplicates) and handling the corner cases in the face of such traditional flexibility. The question, then, is whether this is a desirable path to follow: Is the > value of a quick evaluation of a deterministic signer high enough to > surrender the flexibility of DKIM style of tag spacing and ordering? And, > perhaps more importantly, what's the cost of being wrong later? Agreed. But I'd rephrase it as: 1. What is the value of having a open, globally available test suite for ARC against which any implementer can test a new implementation or changes to an existing implementation to ensure compatibility? This is compared to the current system of ad hoc interops at industry events. 2. What is the value of the flexibility of DKIM style of tag spacing and ordering in the context of ARC? 3. What's the cost of sacrificing #2 for #1? I hope I've made it clear why I think #1 is valuable. I haven't actually heard much of an argument for #2 in this thread - I'd love to understand the perceived benefits. Most of the arguments have centered around #3, and the idea that lots of ARC implementation will be adopted from existing DKIM implementations, which don't have this constraint, and that the implementations will ignore the new constraint. Frankly I'm skeptical about this - DKIM is made up of relatively simple components (RSA signing, Base64 encoding, even canonicalization) - that are mostly available as standalone libraries in many languages. Moreover, if you survey the number of existing libraries per language that implement both DKIM signing and verification, you come up with a pretty small number for most popular languages (1-3), and many of those projects are moribund. In many cases it'll be easier to start from scratch, especially given the bulk of ARC's complexity is in areas that don't really exist in DKIM (header set ordering by i, etc.). I know that if I write a Ruby implementation, that's likely how I'd approach it. Even if the DKIM code is adopted, we're talking about a very specific set of change to two isolated areas. Looking at OpenARC in particular, that code is already imposing a preferred tag/value ordering and spacing on the signing side. It's just buried in the implementation details. Changing/standardizing it would not be particularly difficult. Changing the verifying code to validate the ordering/spacing would also not be particularly difficult. That's pretty much all of the work as applies to that implementation. Best, Peter -- [image: logo for sig file.png] Bringing Trust to Email Peter Goldstein | CTO & Co-Founder peter@valimail.com +1.415.793.5783 --001a113f49e82aa89d054bf4ee37 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree = that it's impossible to design a signer test suite that confirms correc= t output, without doing crytpo checks of its own with a known-good verifier= , unless we nail down the syntax the output will use.
Great. =C2=A0:) =C2=A0I wasn't sure there was agreement on = that in the wider thread.
=C2=A0
For this to work, we'd have to mandate a lot of = things, including at least these:
- the order of the tags as presented t= o the hash algorithm
- which tags will be present (note that many are no= t required, including "t=3D")
- the specific values they will = all contain
- for ARC-Message-Signature, which canonicalization will be = used
- the spacing between the tags; since "relaxed" header ca= nonicalization compresses spaces but does not add them, "a=3Dfoo;b=3Df= oo" is not the same as "a=3Dfoo; b=3Dfoo", but "a=3Dfoo= ;\r\n\tb=3Dfoo" is
- similarly, how signature fields will be wrappe= d (if at all)
- what signing key will be used
- the body content to b= e signed
- the header content to be signed
- the set of header fields= that will be signed (which becomes "h=3D")
It certainly remov= es many variables to nail down a test in this way, and it's faster to r= un tests that don't require crypto functions or a known-good verifier t= o confirm.=C2=A0 To be honest, I can't remember if we ever considered t= his sort of approach during the development of DKIM.=C2=A0 I don't thin= k we did, and after an admittedly brief search I couldn't find anything= in the archives.=C2=A0 I think when canonicalization was developed, it was= plain that tag order wouldn't matter to the verifier, and that was sor= t of the end of it.

So while it is true for= a given test case you would need to constrain all of these items, this is = a much larger list than would need to be specified as part of the proposal = under consideration.

Many of these items are alrea= dy constrained by the controlling RFC (ARC or DKIM) and the other values sp= ecified in the signature.=C2=A0 For example, the order in which different h= eader fields are combined and hashed is defined as a function of the tag/va= lue pairs in the signature (i.e in DKIM signature the 'b' value is = impacted by the choice of values for the 'a', 'c','h= 9;, etc. tag values).=C2=A0 That ordering is therefore an input to the test= case.=C2=A0 The input message content (headers + body), the signing key(s)= , etc. would all also be input to a particular test case.

A test suite should handle this by having test cases that exercise = the library with different inputs that give good coverage across allowed va= riations.=C2=A0 That has the side benefit of allowing the test suite implem= enter(s) to easily develop targeted test cases that cover those specific va= riations in isolation, making it easier to find bugs.

<= div>That said, some of these items in the list (intertag spacing, required = tags, canonical values for some of the tags) would need to be constrained a= s part of this proposal.=C2=A0 This is clearly a change, but it's a cha= nge to a draft standard that has a small # of implementers and should be re= latively easy to lock down.=C2=A0 And I think it's far less of a change= than some others on this list do.

The obvious counter-argument here is tha= t DKIM has been successful without ever being strict about what a signature= looks like. =C2=A0...=C2=A0 We reached a point where we had organically de= veloped a bunch of "good" implementations based on the fact that = they all appeared to agree with each other.

I think the bigger point being argued is that DKIM has= been successful without ever having a global test suite, because that'= s the impact of not making this choice (or committing to a global reference= implementation).

Which is mostly true, but frankly not entirely true.=C2=A0 I= 9;m aware of at least two major vendors who have production DKIM signing im= plementations with edge case bugs that would've been caught by such a s= uite.=C2=A0 Those implementations made it through development, passed whate= ver implementation specific test cases the developers built, and made it to= production.=C2=A0 That's what a good test suite helps you avoid.=C2=A0=

Since the canonicalization algorithms in ARC are the same= as the ones in DKIM, and the tag=3Dvalue and key syntaxes are also the sam= e, we've got a lot of concepts and code being recycled here.=C2=A0 I= 9;m not sure how much new fragility we should really be concerned about.=C2= =A0 I'll know more as I complete my implementation.

Paul's point that video and security protocols are traditionally m= uch more rigid is of course quite true, and I presume he's thinking of = things like the headers of DNS, IP, TCP, etc.=C2=A0 But I note that those a= re based on a different model where fields have fixed sizes and predictable= positions.=C2=A0 That's antithetical to email, however, where the fiel= ds come in arbitrary order, and the only way you know what a given header m= eans is that its name precedes its value.=C2=A0 There can even be duplicati= on.=C2=A0 And from one MTA to another, header fields can be added, removed,= or rearranged.=C2=A0 That's impossible in a rigid header definition, s= o it's perhaps no surprise that this community isn't exactly warm t= o the idea.

I'm assuming that I'm Paul. =C2=A0:)

I am thinking of prot= ocols like DNS, IP, TCP, but also standards that are higher up the stack li= ke some video protocols.=C2=A0 The latter standards often allow large scale= re-ordering of the individual chunks and streams of the video, but usually= have byte level constraints on the content of those chunks.=C2=A0 In my vi= ew that's exactly analogous to what I'm proposing here.

I'm also reco= gnizing that, once a standard has a binary component (i.e. hashes), the lev= el of flexibility that's being claimed no longer actually exists.=C2=A0= As a specific example, take any email message you like that has passed DKI= M.=C2=A0 Insert a single additional space between any two tags/value in a p= assing DKIM signature.=C2=A0 The message now fails DKIM.=C2=A0 That means t= he semantic content of the message (and more importantly, how receivers wil= l treat it) will change.

There seems to be a lot of confusion in this thread abou= t the difference between strictly specifying fields inside a single new hea= der, and changes that cross headers.=C2=A0 None of the above mentioned chan= ges to the header set - adding, deleting, duplicating, etc. - is impacted i= n any way by the proposal under discussion.=C2=A0 ARC already needs to hand= le those cases for the construction of the ARC seal, and much of the comple= xity of ARC is around canonicalizing the header set (specifying an order, e= liminating duplicates) and handling the corner cases in the face of such tr= aditional flexibility.

The question, then, is whether this= is a desirable path to follow: Is the value of a quick evaluation of a det= erministic signer high enough to surrender the flexibility of DKIM style of= tag spacing and ordering?=C2=A0 And, perhaps more importantly, what's = the cost of being wrong later?

Agreed.=C2= =A0 But I'd rephrase it as:

1. What is the val= ue of having a open, globally available test suite for ARC against which an= y implementer can test a new implementation or changes to an existing imple= mentation to ensure compatibility? =C2=A0 This is compared to the current s= ystem of ad hoc interops at industry events.
2. What is the value of the flexibility of DKIM style of tag spa= cing and ordering in the context of ARC? =C2=A0
3. What's the= cost of sacrificing #2 for #1?

I hope I've ma= de it clear why I think #1 is valuable.

I haven= 9;t actually heard much of an argument for #2 in this thread - I'd love= to understand the perceived benefits.

Most of the= arguments have centered around #3, and the idea that lots of ARC implement= ation will be adopted from existing DKIM implementations, which don't h= ave this constraint, and that the implementations will ignore the new const= raint.

Frankly I'm skeptical about this - DKIM= is made up of relatively simple components (RSA signing, Base64 encoding, = even canonicalization) - that are mostly available as standalone libraries = in many languages.=C2=A0 Moreover, if you survey the number of existing lib= raries per language that implement both DKIM signing and verification, you = come up with a pretty small number for most popular languages (1-3), and ma= ny of those projects are moribund.=C2=A0 In many cases it'll be easier = to start from scratch, especially given the bulk of ARC's complexity is= in areas that don't really exist in DKIM (header set ordering by i, et= c.).=C2=A0 I know that if I write a Ruby implementation, that's likely = how I'd approach it.

Even if the DKIM code is = adopted, we're talking about a very specific set of change to two isola= ted areas.=C2=A0 Looking at OpenARC in particular, that code is already imp= osing a preferred tag/value ordering and spacing on the signing side.=C2=A0= It's just buried in the implementation details.=C2=A0 Changing/standar= dizing it would not be particularly difficult.=C2=A0 Changing the verifying= code to validate the ordering/spacing would also not be particularly diffi= cult.=C2=A0 That's pretty much all of the work as applies to that imple= mentation.

Best,

Peter

--
=


=3D"logo

Bringing Trust to Email

Peter Goldstein | CTO & Co-Founder

peter@valimail.com

+1.415.793.5783
<= /div>
--001a113f49e82aa89d054bf4ee37-- From nobody Thu Mar 30 10:01:26 2017 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 4AA891299C9 for ; Thu, 30 Mar 2017 10:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-jR0nLYdWhk for ; Thu, 30 Mar 2017 10:01:13 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75E9F1299E4 for ; Thu, 30 Mar 2017 10:01:07 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id p22so45487216qka.3 for ; Thu, 30 Mar 2017 10:01:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=erDYH+nyzldSfz9S3vUorce8Cw+zkBW5slOgCF4JIF0=; b=Gc42hLXxkYGj4BClqR7RLg1uTUSdCNLlCEkajrKX3wsrjDdK+PVLCujgxo38vKJbQc hKPMP0KmNnlP6M/oMN7KWwAW1HE+tK/etNhJ3KQrFSU8jXUHWXo124qMEg6LyVYvM0KM KCjYHyAsXCmadnndUcTGrQZwcECdqr9EKbVfw0ns04IFDl+lNoVDXrYlQZM3LRr3IdFk URA/tScbJrQQ08n/bQApgDK1JhOJmcCcqdQejZXznKAYh/k/dH8LAB7njG9fwro8XtuG vmqonLhMHfPfdjNla761n+oPdQRIrGHqhnQMrblhJQRAMsaE8dP9kjV66sEnhdrvDctj fJTQ== 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=erDYH+nyzldSfz9S3vUorce8Cw+zkBW5slOgCF4JIF0=; b=duPAgcSG/f83L6WUBzcidLIOCxxivtUA50nX8KkKl1vFZiznv2/doAbZ5IryC6LrX/ NPXhHOBUDonw7Yp38nfljXysCmnV+BqO8OeXCGyd9BMppYz6VCYKsQUwQr4GTDkmdLmr 8Q5UTcuBiPVuU4cA3c00kfuEQOGsFw+gsu/p1xvFiFONPfJ9tdOdBcaoL14zQZPjnB8f J2XnfZmpbyBBCZ4wp1fI0uFzVPW4DLeJnpMUdlHOPhRZF6Q+rqZOFuTMcIaaNJIiFMJT Ra8JJSeQ4XTnRiYJRkMu+91ucYX+7QY4c7C+8HmzqrYEwwhOL1lSiXH05grdg2+V/Xa1 y59Q== X-Gm-Message-State: AFeK/H3rObzc/VgHG7rjXu9bgrxRS7nrFyYQTzTn/7RrqpBOblcvz/k2yrnX7/0aPPQKo+AaM6Qo/uno+1ojTA== X-Received: by 10.55.87.198 with SMTP id l189mr700339qkb.304.1490893266514; Thu, 30 Mar 2017 10:01:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.141.207 with HTTP; Thu, 30 Mar 2017 10:01:05 -0700 (PDT) In-Reply-To: <01QCKR5S5OXK0003XB@mauve.mrochek.com> References: <2978391.eJVbVTHBlo@kitterma-e6430> <01QCKR5S5OXK0003XB@mauve.mrochek.com> From: Peter Goldstein Date: Thu, 30 Mar 2017 10:01:05 -0700 Message-ID: To: ned+dmarc@mrochek.com Cc: "Murray S. Kucherawy" , "dmarc@ietf.org" , Scott Kitterman Content-Type: multipart/alternative; boundary=001a114dbb788ca870054bf5a38d Archived-At: Subject: Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 30 Mar 2017 17:01:25 -0000 --001a114dbb788ca870054bf5a38d Content-Type: text/plain; charset=UTF-8 > > > I think Peter's proposal (and he can correct me if I'm wrong) is only to > > constrain signers. Verifiers are still expected to handle everything > weird > > that the infrastructure might do. > This proposal creates a situation where verifiers are required to support > something that no compliant signer will generate. The result will be that a > test suite with reasonable coverage cannot be generated using compliant > software. > And since most people are not going to bother to create an incompliant > signer > specifically for purposes of testing, if anything this will create, rather > than > elimnate, interoperability problems. > Just to be clear, this is not what I was proposing. Specifically, I don't think the Robustness Principle applies in this case. Verification should check the RFC defined spacing, ordering, etc. of the tag/value pairs and reject non-compliant values As this is a new protocol, and these headers are all new and used exclusively for ARC, and for the reasons mentioned by Ned, there's no reason to be lenient in what is accepted. > That sort of organic validation of implementations seemed to work for > > DKIM. The unknown here is whether ARC will be as successful with that > > model. > Exactly. And given the success of the approach with DKIM, the burden is > on those proposing to use a different model for ARC to explain why it will > work better. A few quick comments on this. As per my earlier email, I have a lot less confidence in how well this 'seemed to work' than some of the other participants in this thread. One of the benefits of DMARC re:DKIM is it has exposed some issues with DKIM implementations that were not obvious prior to DMARC evaluation. Without DMARC reporting some of the problems with certain DKIM implementations were simply not very visible. So I don't actually think the DKIM model worked as well as is being asserted. Second, the existence of such a test suite would have had material benefits just within the last ~18 months over which ARC implementations have been developed. We know this because of the immediate benefits the current test suite (which does impose a canonical ordering, spacing, etc.) yielded almost immediately. The suite exposed a few minor but significant issues with the Python implementation that was submitted to dkimpy. Similarly, it exposed that the current OpenARC signing functionality is in a much less mature state than was generally understood. In terms of RFC definition, it exposed the fact that the current RFC as written required support for insecure 512 bit keys - and triggered a discussion on this very list. In our internal development it's forced us to look hard at some of the corner cases and raise them on this list or at interops. Note that most of these issues had escaped detection through multiple interops. None of the above is meant to insult the associated developers or spec authors. Their contributions have been essential, and the skill and dedication they've brought to their tasks is greatly appreciated. It is simply meant to demonstrate the material benefit that this kind of testing has already brought. This is what automated tests do - bring problems to light quickly. So yes, I think this approach works better. Much better. Best, Peter > -- [image: logo for sig file.png] Bringing Trust to Email Peter Goldstein | CTO & Co-Founder peter@valimail.com +1.415.793.5783 --001a114dbb788ca870054bf5a38d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> I think Peter's propos= al (and he can correct me if I'm wrong) is only to
> constrain signers.=C2=A0 Ver= ifiers are still expected to handle everything weird
> that the infrastructure might= do.
<= span style=3D"font-size:12.8px">This proposal creates a situation where ver= ifiers are required to support
s= omething that no compliant signer will generate. The result will be that a<= br>test suite with reasonable cover= age cannot be generated using compliant
software.
And since most people are not going to bother to create an inc= ompliant signer
specifically for= purposes of testing, if anything this will create, rather than
<= span style=3D"font-size:12.8px">elimnate, interoperability problems.=

Just to be clear, this is not what I was proposing.=C2=A0 Specifica= lly, I don't think the Robustness Principle applies in this case.=C2=A0 Verific= ation should check the RFC defined spacing, ordering, etc. of the tag/value= pairs and reject non-compliant values

As this is a new protocol, and thes= e headers are all new and used exclusively for ARC, and for the reasons men= tioned by Ned, there's no reason to be lenient in what is accepted.

> That sort of organic validation of implementations= seemed to work for
> DKIM.=C2=A0 The u= nknown here is whether ARC will be as successful with that
> model.
Exactl= y. And given the success of the approach with DKIM, the burden is
on tho= se proposing to use a different model for ARC to explain why it will
wor= k better.

A few quick comm= ents on this.

As per my earlier email, I have a lot less confidence in how well t= his 'seemed to work' than some of the other participants in this th= read.=C2=A0 One of the benefits of DMARC re:DKIM is it has exposed some iss= ues with DKIM implementations that were not obvious prior to DMARC evaluati= on.=C2=A0 Without DMARC reporting some of the problems with certain DKIM im= plementations were simply not very visible.=C2=A0 So I don't actually t= hink the DKIM model worked as well as is being asserted.

Second, the existence of= such a test suite would have had material benefits just within the last ~1= 8 months over which ARC implementations have been developed.=C2=A0 We know = this because of the immediate benefits the current test suite (which does i= mpose a canonical ordering, spacing, etc.) yielded almost immediately.
<= /div>

The su= ite exposed a few minor but significant issues with the Python implementati= on that was submitted to dkimpy.=C2=A0 Similarly, it exposed that the curre= nt OpenARC signing functionality is in a much less mature state than was ge= nerally understood.=C2=A0 In terms of RFC definition, it exposed the fact t= hat the current RFC as written required support for insecure 512 bit keys -= and triggered a discussion on this very list.=C2=A0 In our internal develo= pment it's forced us to look hard at some of the corner cases and raise= them on this list or at interops.=C2=A0 Note that most of these issues had= escaped detection through multiple interops.

None of the above is meant to insul= t the associated developers or spec authors.=C2=A0 Their contributions have= been essential, and the skill and dedication they've brought to their = tasks is greatly appreciated.=C2=A0 It is simply meant to demonstrate the m= aterial benefit that this kind of testing has already brought.=C2=A0 This i= s what automated tests do - bring problems to light quickly. =C2=A0

So yes, I thi= nk this approach works better.=C2=A0 Much better.

Best,

Peter

<= div class=3D"gmail-h5">


--
=

3D"logo

Bringing Trust to Email

Peter Goldstein | CTO &am= p; Co-Founder

peter@valimail.com

+1.415.793.5783
=
--001a114dbb788ca870054bf5a38d-- From nobody Thu Mar 30 10:25:37 2017 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 87E8F1299E3 for ; Thu, 30 Mar 2017 10:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 piDs1us4Sb6z for ; Thu, 30 Mar 2017 10:25:31 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (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 7B8FD126DFB for ; Thu, 30 Mar 2017 10:25:30 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QCKXWEQQV400VUEQ@mauve.mrochek.com> for dmarc@ietf.org; Thu, 30 Mar 2017 10:20:25 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QCKVA263Z40003XB@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Thu, 30 Mar 2017 10:20:18 -0700 (PDT) From: ned+dmarc@mrochek.com Cc: ned+dmarc@mrochek.com, Scott Kitterman , "dmarc@ietf.org" , "Murray S. Kucherawy" Message-id: <01QCKXW9MZ4Q0003XB@mauve.mrochek.com> Date: Thu, 30 Mar 2017 10:13:54 -0700 (PDT) In-reply-to: "Your message dated Thu, 30 Mar 2017 10:01:05 -0700" References: <2978391.eJVbVTHBlo@kitterma-e6430> <01QCKR5S5OXK0003XB@mauve.mrochek.com> To: Peter Goldstein Archived-At: Subject: Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 30 Mar 2017 17:25:34 -0000 > > > > > I think Peter's proposal (and he can correct me if I'm wrong) is only to > > > constrain signers. Verifiers are still expected to handle everything > > weird > > > that the infrastructure might do. > > This proposal creates a situation where verifiers are required to support > > something that no compliant signer will generate. The result will be that a > > test suite with reasonable coverage cannot be generated using compliant > > software. > > And since most people are not going to bother to create an incompliant > > signer > > specifically for purposes of testing, if anything this will create, rather > > than > > elimnate, interoperability problems. > > > Just to be clear, this is not what I was proposing. Specifically, I don't > think the Robustness Principle > applies in this case. > Verification should check the RFC defined spacing, ordering, etc. of the > tag/value pairs and reject non-compliant values > As this is a new protocol, and these headers are all new and used > exclusively for ARC, and for the reasons mentioned by Ned, there's no > reason to be lenient in what is accepted. On the contrary, there are very good reasons. People aren't going to magic up implementations of ARC out of nothing; they will undoubtedly use existing DKIM code as a starting point. Implementing an ordering requirement on top of such code could get interesting depending on how it works. And given the relationship with DKIM people are going to expect ARC to work in the same general way, maing such a change a least astonishment principle violation. > > That sort of organic validation of implementations seemed to work for > > > DKIM. The unknown here is whether ARC will be as successful with that > > > model. > > Exactly. And given the success of the approach with DKIM, the burden is > > on those proposing to use a different model for ARC to explain why it will > > work better. > A few quick comments on this. > As per my earlier email, I have a lot less confidence in how well this > 'seemed to work' than some of the other participants in this thread. One > of the benefits of DMARC re:DKIM is it has exposed some issues with DKIM > implementations that were not obvious prior to DMARC evaluation. Without > DMARC reporting some of the problems with certain DKIM implementations were > simply not very visible. So I don't actually think the DKIM model worked > as well as is being asserted. Which of these problems had anything to do with field ordering? Which of these problems would have been exposed by requiring a specific order? > Second, the existence of such a test suite would have had material benefits > just within the last ~18 months over which ARC implementations have been > developed. We know this because of the immediate benefits the current test > suite (which does impose a canonical ordering, spacing, etc.) yielded > almost immediately. > The suite exposed a few minor but significant issues with the Python > implementation that was submitted to dkimpy. Similarly, it exposed that > the current OpenARC signing functionality is in a much less mature state > than was generally understood. In terms of RFC definition, it exposed the > fact that the current RFC as written required support for insecure 512 bit > keys - and triggered a discussion on this very list. In our internal > development it's forced us to look hard at some of the corner cases and > raise them on this list or at interops. Note that most of these issues had > escaped detection through multiple interops. > None of the above is meant to insult the associated developers or spec > authors. Their contributions have been essential, and the skill and > dedication they've brought to their tasks is greatly appreciated. It is > simply meant to demonstrate the material benefit that this kind of testing > has already brought. This is what automated tests do - bring problems to > light quickly. > So yes, I think this approach works better. Much better. Simply put, I don't. I'm strongly opposed to this, to the point where I'm likely to significantly deprioritize implementation of this proposal because of it. I have better things to do that waste my time watching the sorts of bugs this is going to cause get shaken out. Ned From nobody Thu Mar 30 10:35:20 2017 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 53FC31293DA for ; Thu, 30 Mar 2017 10:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2kEhZXr4dGi for ; Thu, 30 Mar 2017 10:35:12 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0866A129443 for ; Thu, 30 Mar 2017 10:35:12 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id d10so46589785qke.1 for ; Thu, 30 Mar 2017 10:35:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vjZvPBb+pQFB/G8Put0En+66MUrMxHmIQXYSIGgrpgQ=; b=Zd/2NjpsZiWibqTw3rPNyaD9qmxSg/JgpvLgwAjfQ6woFpJb6vNQBNJ2skzLwNRsKF aPC54ts19FgvpmlaG3ALYZVxMgRrBDutYaYZdZvZoYyq/rkBsWip6LIkgRR9Q3A+4aM/ 6LZLHPG+AWe30uXeIMc5JvTM2VKrWCWAj6idHj2ydLitfIJOvt5SMs+gXVbtlCnnyabo FH6+H3eKP0Lo/It68zkbUu2SD0GXfyCmCylCiPXPi//mrfcRS923LMZ2cxraKYlqpSqH qaskNZ8UMS+nWL13uW6D3Pii2lxpCZ0ZSmGYzbGZ4pPsy7mXTabTIGiLxAa/YoVbypN3 CbUQ== 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=vjZvPBb+pQFB/G8Put0En+66MUrMxHmIQXYSIGgrpgQ=; b=i+VDYn2VTNrVXPZ0UFY9ZgxZA8UvXrZEQgLCDe2sn9Ak6t+olRzYZaNvjRinqKbnC6 YCUSQMvAXMEfTzpaZusYVDIkqDRPx/ty/E6F9O7ahRX+GB/y/OwzsQcVfOB1sXVd9eyL iiPLPKJ9/59FB/GGD23y7x08F+gaYToLj+aFdJnQ+09Oo7se4V9EdIW7s3iZ1rL0vxjp juwdclI1NrDroiYXzxKUEwE2CNVRE0ciWamPHNOY5UY9Dto03rrJBNkv3QlsBNsNpb4m RS603YYlpNsmPmcInDJ80deDaqHZk874Mi8fXjbBkMNeUVsIDcNeaJ4cS5Io6VwQSwMq vbWw== X-Gm-Message-State: AFeK/H0nfYqgAcEps/WneFjhX/zQzPhC++Ok5FTjw9N7Ej1HYvg9sSMcFZsKgdlHHPnZ1pOQXsPx5Rv1ItJcww== X-Received: by 10.55.176.135 with SMTP id z129mr891110qke.308.1490895311051; Thu, 30 Mar 2017 10:35:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.42.166 with HTTP; Thu, 30 Mar 2017 10:34:50 -0700 (PDT) In-Reply-To: <01QCKR5S5OXK0003XB@mauve.mrochek.com> References: <2978391.eJVbVTHBlo@kitterma-e6430> <01QCKR5S5OXK0003XB@mauve.mrochek.com> From: Seth Blank Date: Thu, 30 Mar 2017 10:34:50 -0700 Message-ID: To: "dmarc@ietf.org" Cc: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=94eb2c06569469b1a6054bf61d3e Archived-At: Subject: Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 30 Mar 2017 17:35:18 -0000 --94eb2c06569469b1a6054bf61d3e Content-Type: text/plain; charset=UTF-8 On Thu, Mar 30, 2017 at 7:01 AM, wrote: > > On Mon, Mar 27, 2017 at 11:49 PM, Scott Kitterman > > That sort of organic validation of implementations seemed to work for > > DKIM. The unknown here is whether ARC will be as successful with that > > model. > > Exactly. And given the success of the approach with DKIM, the burden is > on those proposing to use a different model for ARC to explain why it will > work better. > > And note that "this kind of test becomes possible" is not sufficient. All > kinds of tests become possible when you add constraints - the question is > what sort of real world problem will those additional tests find. > ARC is fundamentally different than DKIM in several key ways. If we were only talking about ARC Signing messages, I'd generally agree with the comments on this list. However, ARC is fundamentally different. It is about a chain of messages that validate each other. And ARC's complexity is not in the signing (where most of this conversation has been focused), but in this chain validation and the cascading issues that can be created by any member of the chain doing something slightly wrong. And since *everyone* in the chain except the initial signer is also a receiver, the final receiver simply can't make up for mistakes caused by a less savvy intermediary - the chain will already be broken and unrecoverable. ARC also has a lot of subtlety that is missable at interops because of this. For instance, if I'm modifying a message, I need to validate the incoming chain, then make my modifications, and then sign the outgoing message. An intermediary doing this wrong (say, validating and then signing after message modification) isn't a bug a final receiver can fix. And without a seriously complex interop with a ton of intermediaries and sending relationships mapped out for testing, it's not likely an error in any specific implementation here will be discovered until it's too late. To my understanding, working on the test suite shook these issues out because they were what caused problems running the test suite at the interop in the first place. So this is actually a good and healthy part of the process, and is the natural consequence of the interops. What worked here for DKIM is insufficient with the nuances of ARC. What we've been discussing doesn't just guarantee a test suite can be made that works for everyone (which is huge in itself), but constrains the problem space for everyone involved in an ARC chain. This is clean and desirable. Since the spec isn't finalized, this is the perfect time to impose some order that isn't necessary for DKIM but is critical when we're talking about multiple operators working together over multiple hops as part of a chain of trust. Seth -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols seth@valimail.com +1-415-894-2724 <415-894-2724> --94eb2c06569469b1a6054bf61d3e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Mar 30, 2017 at 7:01 AM, <ned+dmarc@mrochek.com> wrote:
<= span class=3D"gmail-m_1561402462663049053gmail-">> On Mon, Mar 27, 2017 = at 11:49 PM, Scott Kitterman <sklist@kitterman.com>
> That sort of organic validation of implementations seemed to work for<= br> > DKIM.=C2=A0 The unknown here is whether ARC will be as successful with= that
> model.

Exactly. And given the success of the approach with DKIM, the burden= is
on those proposing to use a different model for ARC to explain why it will<= br> work better.

And note that "this kind of test becomes possible" is not suffici= ent. All
kinds of tests become possible when you add constraints - the question is what sort of real world problem will those additional tests find.


ARC is fundamentally different th= an DKIM in several key ways. If we were only talking about ARC Signing mess= ages, I'd generally agree with the comments on this list.
However, ARC is fundamentally different. It is about a chain of= messages that validate each other. And ARC's complexity is not in the = signing (where most of this conversation has been focused), but in this cha= in validation and the cascading issues that can be created by any member of= the chain doing something slightly wrong. And since *everyone* in the chai= n except the initial signer is also a receiver, the final receiver simply c= an't make up for mistakes caused by a less savvy intermediary - the cha= in will already be broken and unrecoverable.

ARC a= lso has a lot of subtlety that is missable at interops because of this. For= instance, if I'm modifying a message, I need to validate the incoming = chain, then make my modifications, and then sign the outgoing message. An i= ntermediary doing this wrong (say, validating and then signing after messag= e modification) isn't a bug a final receiver can fix. And without a ser= iously complex interop with a ton of intermediaries and sending relationshi= ps mapped out for testing, it's not likely an error in any specific imp= lementation here will be discovered until it's too late.

=
To my understanding, working on the test suite shook these issue= s out because they were what caused problems running the test suite at the = interop in the first place. So this is actually a good and healthy part of = the process, and is the natural consequence of the interops. What worked he= re for DKIM is insufficient with the nuances of ARC.

What we've been discussing doesn't just guarantee a test suite c= an be made that works for everyone (which is huge in itself), but constrain= s the problem space for everyone involved in an ARC chain. This is clean an= d desirable.

Since the spec isn't finalized, t= his is the perfect time to impose some order that isn't necessary for D= KIM but is critical when we're talking about multiple operators working= together over multiple hops as part of a chain of trust.

Seth

--

3D"logo

Bringing Trust to Email

Seth Blank | Head = of Product for Open So= urce and Protocols

seth@valimail.com<= span style=3D"font-size:14px;white-space:pre-wrap">
+1-415-894-27= 24
--94eb2c06569469b1a6054bf61d3e-- From nobody Thu Mar 30 16:00:25 2017 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 043051279E5 for ; Thu, 30 Mar 2017 16:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 0S72FbeaSrpY for ; Thu, 30 Mar 2017 16:00:21 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::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 2661B129434 for ; Thu, 30 Mar 2017 16:00:21 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id b140so29577950iof.1 for ; Thu, 30 Mar 2017 16:00:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JGWvDTx9ixcMYrO8FYAVp3YpL0ot2IYer+7ItfcjriI=; b=fKkVFhQYE7XiY2iY0zYDn4VqPK+XIzC/P3/7Sfdm/AHjtFxTKRNl5fBLxNlBWOuvZJ us1hhIkmi/qh4jf65PnzD0FI9RPpFD6NXD6P4HdNKs2yAlGQpY+O245jPyOiYmp4ouoK tZBN6jkTRz8Q/diD6hKxP8Cu3NcjQS1kF9c2LJi8nFwUcM9GXQmIbtGTCc2XCM/DexpT PP7t+cr2sdK8bZcb867Sh83LSaSjrrvgizZkp5O3qnDZuw+3HE8rhIj5f36xl2JcRKiy 8UW8dily0SL+bl0tiDceGtKYyAXZKw3jGuwlE4EohHid7BbXfnGsulzTEybjYx+vGKA9 LdSA== 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=JGWvDTx9ixcMYrO8FYAVp3YpL0ot2IYer+7ItfcjriI=; b=BSSESPTqPLfKd/g9FMUv/OujDVLMJBp4mQRvYmsjJD+4O+JtVflhX5oQVxs+SWom5b ahDzslmkfIbsC/24rAx36XCeUuA6lkL/Sjuq+vXoy+T05b+YtxRxBLsZ7r3OTwnT26xn gDu0nNBPfkEGv9JYPPW5o6McF5k8nGk3jJX5q72/6MwhUlQr+GUVuYu8zXzlRuV7yS8p 1akahgtAOqJv6ZHGwMVk2cKysbrPEa8EgeRhXDXIxObxDEo9a6dtjAisqmuG1D9OGKVK ejCmIJlSHNApY9jn36o397jha618r2JAWsGQuuLzO+3gxVOD+YbvaW/RfOthY00lJHnA M+cA== X-Gm-Message-State: AFeK/H37DI0stq9EksWerrw8uK3X/OKdU4npzzkXuLut4NYu5EEBmsafH43UteTX/njR2el2UroI302/IMnSR1N3 X-Received: by 10.107.173.169 with SMTP id m41mr3592530ioo.190.1490914820099; Thu, 30 Mar 2017 16:00:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.35.97 with HTTP; Thu, 30 Mar 2017 16:00:19 -0700 (PDT) In-Reply-To: References: <20170324212304.85346.qmail@ary.lan> From: Brandon Long Date: Thu, 30 Mar 2017 16:00:19 -0700 Message-ID: To: "Murray S. Kucherawy" Cc: Gene Shuman , "dmarc@ietf.org" , John Levine Content-Type: multipart/alternative; boundary=001a11443ef63e86a4054bfaa858 Archived-At: Subject: Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 30 Mar 2017 23:00:24 -0000 --001a11443ef63e86a4054bfaa858 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 30, 2017 at 1:21 AM, Murray S. Kucherawy wrote: > I have to catch up on the rest of this thread still, but I wanted to chime > in here to get started: > > On Sun, Mar 26, 2017 at 5:23 PM, Gene Shuman wrote: > >> Ah that had slipped my mind & is a good point. However, I think the >> issue here is generally that ARC is more complex protocol than DKIM and >> therefore it's more important to reduce ambiguity & increase >> standardization while we have the chance. I think this is generally a good >> idea from a security perspective, however this is mostly relevant with >> respect to testing & validation, as ensuring cross-compatibility is a much >> bigger challenge. It's even more important than it was with DKIM to have a >> test suite that can verify signing behavior. If we don't agree on any sort >> of standard, a test suite will need to select a preferred format for the >> ARC headers & will fail all implementations that don't meet this form. >> We've discussed this with Murray, and he agrees with this conclusion. >> > > I agree that it's impossible to design a signer test suite that confirms > correct output, without doing crytpo checks of its own with a known-good > verifier, unless we nail down the syntax the output will use. For this to > work, we'd have to mandate a lot of things, including at least these: > > - the order of the tags as presented to the hash algorithm > This could imply two different things, either "alphabetize them in the header" like was done for the current test suite, or it could imply a canonicalization step when passing the header to signing. The latter seems unlikely to be what we'd want, given we have to sign a whole bunch of ARC headers, we probably don't want to interpret and sign each one, signing the string is easier. And I admit that I immediately disliked the alphabetized list upon seeing it, the main issue I had was with not having i= at the front, the rest just seemed ugly (ie, the b/bh tend to be at the end in implementations because they are long). That's probably not a valid argument against it, though I do think that i= at the front is useful for visual grouping without having to scan the full header to find it. > - which tags will be present (note that many are not required, including > "t=") > - the specific values they will all contain > - for ARC-Message-Signature, which canonicalization will be used > Does this also mean that my signer has to support all four combinations of canonicalization? Right now, it only does relaxed/relaxed. I have no intention of every generating anything with simple, and I could just fail all of those tests, I guess. > - the spacing between the tags; since "relaxed" header canonicalization > compresses spaces but does not add them, "a=foo;b=foo" is not the same as > "a=foo; b=foo", but "a=foo;\r\n\tb=foo" is > - similarly, how signature fields will be wrapped (if at all) > agreed. I think some of this also goes to what implementers think look good. I also think dkimpy uses certain spacing so that they can wrap it easier, as opposed to say Google's impl which hard codes most of it and has more specific or hard coded wrapping. > - what signing key will be used > - the body content to be signed > - the header content to be signed > These are implied by the test already, so no big deal. > - the set of header fields that will be signed (which becomes "h=") > And the order in which they're signed. Ie, our DKIM impl, because it was also a DomainKeys impl, could choose headers in either direction, but actually chooses them "backwards" for DKIM, requiring kind of a nasty loop that's also worst case (O(n^2)). For ARC, I chose to choose them bottom up, which matches the order to search, and means usually the dual loop has O(n) instead of O(n^2). Granted, it's a silly optimization, and doesn't help with other implementations we have to also handle. dkimpy just has a fixed list of fields, and adds them mostly in order. There's also the choice of whether to include a header or not, we removed content-type from our DKIM list at one point trying to work around Exchange's DKIM breaking behavior, for example. Some implementations double add Subject/etc to prevent duplicates, others don't. We can probably come to agreements on all of these things... well, maybe. I don't know how many potential implementations we'll curtail by doing so. Or maybe some of these won't be specified in the spec, but only for the test suite, so they'll be options to the signers but not required (ie, list of headers to prevent duplicates should be N for testing). There's also the fact that the current drafts basically incorporate all of this from the DKIM without specifying, if we do otherwise, we have to have a lot more exposition. We'll also most likely end up with things that aren't specified in the spec explicitly but are required by the test suite (which may be better than the alternative, something ambiguous in the spec without being explicit elsewhere). Also, I'm not clear on the statement that these aren't relying on dkim libraries. The dkimpy arc impl is clearly depending on shared code between them, I think Paul mentioned that the AOL one re-used code from their Java DKIM impl, and I know the Google impl shares a bunch of code. I don't think any of this precludes these changes, but they aren't free either. Brandon --001a11443ef63e86a4054bfaa858 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 30, 2017 at 1:21 AM, Murray S. Kucherawy = <superuser@gmai= l.com> wrote:
I have to catch up on the rest of this thread still, but I wanted to ch= ime in here to get started:

On Sun, Mar 26, 20= 17 at 5:23 PM, Gene Shuman <gene@valimail.com> wrote:
=
Ah that = had slipped my mind & is a good point.=C2=A0 However, I think the issue= here is generally that ARC is more complex protocol than DKIM and therefor= e it's more important to reduce ambiguity & increase standardizatio= n while we have the chance.=C2=A0 I think this is generally a good idea fro= m a security perspective, however this is mostly relevant with respect to t= esting & validation, as ensuring cross-compatibility is a much bigger c= hallenge.=C2=A0 It's even more important than it was with DKIM to have = a test suite that can verify signing behavior.=C2=A0 If we don't agree = on any sort of standard, a test suite will need to select a preferred forma= t for the ARC headers & will fail all implementations that don't me= et this form.=C2=A0 We've discussed this with Murray, and he agrees wit= h this conclusion.

I agree tha= t it's impossible to design a signer test suite that confirms correct o= utput, without doing crytpo checks of its own with a known-good verifier, u= nless we nail down the syntax the output will use.=C2=A0 For this to work, = we'd have to mandate a lot of things, including at least these:

=
- the order of the tags as presented= to the hash algorithm

This could imply two different things, either "alphabetize the= m in the header" like was done for the current test suite, or it could= imply a canonicalization step when passing the header to signing. The latt= er seems unlikely to be what we'd want, given we have to sign a whole b= unch of ARC headers, we probably don't want to interpret and sign each = one, signing the string is easier.

And I admit tha= t I immediately disliked the alphabetized list upon seeing it, the main iss= ue I had was with not having i=3D at the front, the rest just seemed ugly (= ie, the b/bh tend to be at the end in implementations because they are long= ).=C2=A0 That's probably not a valid argument against it, though I do t= hink that i=3D at the front is useful for visual grouping without having to= scan the full header to find it.
=C2=A0
- which tags will be pres= ent (note that many are not required, including "t=3D")
=
- the specific values they will all contain
<= /div>
- for ARC-Message-Signature, which canonica= lization will be used

Does this also mean that my signer has to support all four combinati= ons of canonicalization?=C2=A0 Right now, it only does relaxed/relaxed.=C2= =A0 I have no intention of every generating anything with simple, and I cou= ld just fail all of those tests, I guess.
=C2=A0
- the spacing between= the tags; since "relaxed" header canonicalization compresses spa= ces but does not add them, "a=3Dfoo;b=3Dfoo" is not the same as &= quot;a=3Dfoo; b=3Dfoo", but "a=3Dfoo;\r\n\tb=3Dfoo" is
- similarly, how signature fields will be wr= apped (if at all)

agreed.=C2=A0 I think some of this also goes to what implementers think = look good.=C2=A0 I also think dkimpy uses certain spacing so that they can = wrap it easier, as opposed to say Google's impl which hard codes most o= f it and has more specific or hard coded wrapping.
=C2=A0
- what signi= ng key will be used
- the body content = to be signed=C2=A0
- the header content to be signed

These are implied by the test already, so no= big deal.
=C2=A0
- the set of header fields that will be signed (whic= h becomes "h=3D")
And the order in which they're signed.=C2=A0 Ie, our DKIM = impl, because it was also a DomainKeys impl, could choose headers in either= direction, but actually chooses them "backwards" for DKIM, requi= ring kind of a nasty loop that's also worst case (O(n^2)).=C2=A0 For AR= C, I chose to choose them bottom up, which matches the order to search, and= means usually the dual loop has O(n) instead of O(n^2).=C2=A0 Granted, it&= #39;s a silly optimization, and doesn't help with other implementations= we have to also handle.

dkimpy just has a fixed l= ist of fields, and adds them mostly in order.=C2=A0 There's also the ch= oice of whether to include a header or not, we removed content-type from ou= r DKIM list at one point trying to work around Exchange's DKIM breaking= behavior, for example.=C2=A0 Some implementations double add Subject/etc t= o prevent duplicates, others don't.

We can pro= bably come to agreements on all of these things... well, maybe.=C2=A0 I don= 't know how many potential implementations we'll curtail by doing s= o.=C2=A0 Or maybe some of these won't be specified in the spec, but onl= y for the test suite, so they'll be options to the signers but not requ= ired (ie, list of headers to prevent duplicates should be N for testing).

There's also the fact that the current drafts b= asically incorporate all of this from the DKIM without specifying, if we do= otherwise, we have to have a lot more exposition.=C2=A0 We'll also mos= t likely end up with things that aren't specified in the spec explicitl= y but are required by the test suite (which may be better than the alternat= ive, something ambiguous in the spec without being explicit elsewhere).

Also, I'm not clear on the statement that these a= ren't relying on dkim libraries.=C2=A0 The dkimpy arc impl is clearly d= epending on shared code between them, I think Paul mentioned that the AOL o= ne re-used code from their Java DKIM impl, and I know the Google impl share= s a bunch of code.=C2=A0 I don't think any of this precludes these chan= ges, but they aren't free either.

Brandon

=C2=A0
--001a11443ef63e86a4054bfaa858-- From nobody Thu Mar 30 16:15:53 2017 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 D0344128B38 for ; Thu, 30 Mar 2017 16:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.792 X-Spam-Level: X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=dcrocker.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 uQKt2geK6HYX for ; Thu, 30 Mar 2017 16:15:51 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 22FD3126C23 for ; Thu, 30 Mar 2017 16:15:44 -0700 (PDT) Received: from [31.133.143.184] (dhcp-8fb8.meeting.ietf.org [31.133.143.184]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v2UNHjtY030983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 30 Mar 2017 16:17:46 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1490915867; bh=jTw/nJQJv+nZUUpnSi7xzIQMLsvukfJp+wjlkHsWQhM=; h=Subject:To:References:Cc:From:Reply-To:Date:In-Reply-To:From; b=Lip0NVlxhjgYHXLzikTeR7KAgGmlKSqk5mKDnhCqtBC79ZC0tbeslP4bUysvFsTKJ 9fmDh7QHrnxdCf35GKn0o/EJpQUxftWhe9eCtjVCOJJLJ4kHlBHBpM0pdKI83tc2KH INDYqoALwcXajaVmJ8FH3jFkFBeJKaHpvZr+iw9s= To: ned+dmarc@mrochek.com, Peter Goldstein References: <2978391.eJVbVTHBlo@kitterma-e6430> <01QCKR5S5OXK0003XB@mauve.mrochek.com> <01QCKXW9MZ4Q0003XB@mauve.mrochek.com> Cc: "Murray S. Kucherawy" , "dmarc@ietf.org" , Scott Kitterman From: Dave Crocker Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking Message-ID: <1cf7325b-6f77-7cda-e330-025b7ddb0b92@dcrocker.net> Date: Thu, 30 Mar 2017 18:15:33 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <01QCKXW9MZ4Q0003XB@mauve.mrochek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 30 Mar 2017 23:15:53 -0000 On 3/30/2017 12:13 PM, ned+dmarc@mrochek.com wrote: > And given the relationship with DKIM people are going to expect ARC > to work in the same general way, maing such a change a least astonishment > principle violation. +10. This thread has been active for 6 days. That is 5.5 days longer than it should have lasted, and I'm being generous. Internet technologies succeed through interoperability testing, not conformance tests, or the like. Conformance testing, and the like, are useful for early-stage bug-finding, but not for 'certification'. This point has been a distinguishing feature of Internet technical work since before the Internet. ARC is a small re-casting of DKIM. DKIM has worked for quite a few years. Some details of ARC need to be different from DKIM, but the basic paradigm -- including the model of achieving field operation through interoperability testing -- should be the same. My reading of this too-long message thread is that there is essentially no support for making ARC's header-related issues any different from DKIM's, so I encourage the chair to shut this thread down. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Mar 30 17:10:47 2017 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 111A71270A3 for ; Thu, 30 Mar 2017 17:10:46 -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 (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HyW7wmxGszDK for ; Thu, 30 Mar 2017 17:10:42 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2703112773A for ; Thu, 30 Mar 2017 17:10:41 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id n21so53479617qta.1 for ; Thu, 30 Mar 2017 17:10:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=axOxohi8mItnspmfKX4VLQt0Pj0TAb7pj/dG4wiWKiA=; b=GUYYnB1quAgSo9gW39l2XGr25TQcLZIMj8XxPqF8Y9QueTv6LJmSFBaUrkic3Xe3ov TytoeMfrm91P6AnEujVxuHik3ZNuwL3yE/PMRlZWcZJrDW9wuaoJxjPxjao8vwkmKsf5 C3FJo8B4bXDqKN/snRY3aIfrwlsVZgr5PJkW0ou+gYrG8iKC8n0KiSILu2jTZxETjD6g HODkNS99xZAjwGF7TD4TLUHECPDCiwkp3I4tyzYU8LtaTflfVEnpOO/Y39hLDSUo5KGO iSPQFaW3zxhVZxbbsoIn3g2edDdeOaO9Wral/F9p+KtoXhiL7GuQ8B5uIoBDQNW+IvXM r6hw== 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=axOxohi8mItnspmfKX4VLQt0Pj0TAb7pj/dG4wiWKiA=; b=Ti246pZlf3fX1Uk+mvocdr5aUxfFiDG6nvTee+rew4bzvr2RPbvGaKqCZUJKDcLgRX YUke9jMssgcsmgQnX9ARfBuJY1znIVbEpXQ6CgsGnMu6s4edsyIfG5rsAd+X8n8nQ5ka VQ8bx7T013WscOMDCZ+T7H4ou32WNnYAV1VQdCOK2gEEETLIlvsyUkl99aw5vL9b7Yow 5rZayp8dhdY+dCMG34StWKuG/SrMg8K0HtgT8d7QoZgKpHXlCf9kuyMqTZBz3DB9nn6Q vlhfGRVrV8xzHSf7SJLyaWI8/Z5BIAySSnLT+HGRqlBXPX2LG7Dt+ACaMGx/aoWaeSoH Rh5Q== X-Gm-Message-State: AFeK/H362Vcs7HxMsRXxa7OgG8hRECqZIVrbaimT7xqeZZ3trysh6lNjoY+LEaBJ1vhDcDL/ShDxWu6zR2GtUQ== X-Received: by 10.200.35.36 with SMTP id a33mr148372qta.216.1490919040045; Thu, 30 Mar 2017 17:10:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.42.166 with HTTP; Thu, 30 Mar 2017 17:10:19 -0700 (PDT) In-Reply-To: <1cf7325b-6f77-7cda-e330-025b7ddb0b92@dcrocker.net> References: <2978391.eJVbVTHBlo@kitterma-e6430> <01QCKR5S5OXK0003XB@mauve.mrochek.com> <01QCKXW9MZ4Q0003XB@mauve.mrochek.com> <1cf7325b-6f77-7cda-e330-025b7ddb0b92@dcrocker.net> From: Seth Blank Date: Thu, 30 Mar 2017 17:10:19 -0700 Message-ID: To: dcrocker@bbiw.net Cc: ned+dmarc@mrochek.com, Peter Goldstein , Scott Kitterman , "dmarc@ietf.org" , "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=001a113a7db8c5977f054bfba303 Archived-At: Subject: Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 31 Mar 2017 00:10:46 -0000 --001a113a7db8c5977f054bfba303 Content-Type: text/plain; charset=UTF-8 Dave, If we were only talking about ARC Signing messages, I'd generally agree with the comments on this list. However, ARC is fundamentally different. It is about a chain of messages that validate each other. And ARC's complexity is not in the signing (where most of this conversation has been focused), but in this chain validation and the cascading issues that can be created by any member of the chain doing something slightly wrong. And since *everyone* in the chain except the initial signer is also a receiver, the final receiver simply can't make up for mistakes caused by a less savvy intermediary - the chain will already be broken and unrecoverable. ARC also has a lot of subtlety that is missable at interops because of this. For instance, if I'm modifying a message, I need to validate the incoming chain, then make my modifications, and then sign the outgoing message. An intermediary doing this wrong (say, validating and then signing after message modification) isn't a bug a final receiver can fix. And without a seriously complex interop with a ton of intermediaries and sending relationships mapped out for testing, it's not likely an error in any specific implementation here will be discovered until it's too late. To my understanding, working on the test suite shook these issues out because they were what caused problems running the test suite at the interop in the first place. So this is actually a good and healthy part of the process, and is the natural consequence of the interops. What worked here for DKIM is insufficient with the nuances of ARC. What we've been discussing doesn't just guarantee a test suite can be made that works for everyone (which is huge in itself), but constrains the problem space for everyone involved in an ARC chain. This is clean and desirable. Since the spec is not finalized, this is the perfect time to set a deterministic order for headers that no one has even seen before. Seth On Thu, Mar 30, 2017 at 4:15 PM, Dave Crocker wrote: > On 3/30/2017 12:13 PM, ned+dmarc@mrochek.com wrote: > >> And given the relationship with DKIM people are going to expect ARC >> to work in the same general way, maing such a change a least astonishment >> principle violation. >> > > > +10. > > This thread has been active for 6 days. That is 5.5 days longer than it > should have lasted, and I'm being generous. > > Internet technologies succeed through interoperability testing, not > conformance tests, or the like. Conformance testing, and the like, are > useful for early-stage bug-finding, but not for 'certification'. This > point has been a distinguishing feature of Internet technical work since > before the Internet. > > ARC is a small re-casting of DKIM. DKIM has worked for quite a few > years. Some details of ARC need to be different from DKIM, but the basic > paradigm -- including the model of achieving field operation through > interoperability testing -- should be the same. > > My reading of this too-long message thread is that there is essentially no > support for making ARC's header-related issues any different from DKIM's, > so I encourage the chair to shut this thread down. > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols seth@valimail.com +1-415-894-2724 <415-894-2724> --001a113a7db8c5977f054bfba303 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dave, If we were only talking about ARC Signing messa= ges, I'd generally agree with the comments on this list.

=
However, ARC is fundamentally different. It is about a chain of = messages that validate each other. And ARC's complexity is not in the s= igning (where most of this conversation has been focused), but in this chai= n validation and the cascading issues that can be created by any member of = the chain doing something slightly wrong. And since *everyone* in the chain= except the initial signer is also a receiver, the final receiver simply ca= n't make up for mistakes caused by a less savvy intermediary - the chai= n will already be broken and unrecoverable.

ARC al= so has a lot of subtlety that is missable at interops because of this. For = instance, if I'm modifying a message, I need to validate the incoming c= hain, then make my modifications, and then sign the outgoing message. An in= termediary doing this wrong (say, validating and then signing after message= modification) isn't a bug a final receiver can fix. And without a seri= ously complex interop with a ton of intermediaries and sending relationship= s mapped out for testing, it's not likely an error in any specific impl= ementation here will be discovered until it's too late.

<= /div>
To my understanding, working on the test suite shook these issues= out because they were what caused problems running the test suite at the i= nterop in the first place. So this is actually a good and healthy part of t= he process, and is the natural consequence of the interops. What worked her= e for DKIM is insufficient with the nuances of ARC.

What we've been discussing doesn't just guarantee a test suite ca= n be made that works for everyone (which is huge in itself), but constrains= the problem space for everyone involved in an ARC chain. This is clean and= desirable.

Since the spec is not finalized, this = is the perfect time to set a deterministic order for headers that no one ha= s even seen before.

Seth


On Thu, Mar 30, = 2017 at 4:15 PM, Dave Crocker <dhc@dcrocker.net> wrote:
On 3/30/2017 12:13 PM, ned+dmarc@mrochek.co= m wrote:
And given the relationship with DKIM people are going to expect ARC
to work in the same general way, maing such a change a least astonishment principle violation.


 +10.

This thread has been active for 6 days.=C2=A0 That is 5.5 days longer than = it should have lasted, and I'm being generous.

Internet technologies succeed through interoperability testing, not conform= ance tests, or the like.=C2=A0 Conformance testing, and the like, are usefu= l for early-stage bug-finding, but not for 'certification'.=C2=A0 T= his point has been a distinguishing feature of Internet technical work sinc= e before the Internet.

ARC is a small re-casting of DKIM.=C2=A0 DKIM has worked for quite a few ye= ars.=C2=A0 Some details of ARC need to be different from DKIM, but the basi= c paradigm -- including the model of achieving field operation through inte= roperability testing -- should be the same.

My reading of this too-long message thread is that there is essentially no = support for making ARC's header-related issues any different from DKIM&= #39;s, so I encourage the chair to shut this thread down.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net


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



--
=

3D"logo

Bringing Trust to Email

Seth Blank | Head of Product for Open Source and Protocols

seth@valim= ail.com
+1-415-894-2724
=
--001a113a7db8c5977f054bfba303-- From nobody Thu Mar 30 18:11:37 2017 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 136A71296D1 for ; Thu, 30 Mar 2017 18:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.411 X-Spam-Level: X-Spam-Status: No, score=0.411 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAWe9Wq1mDtA for ; Thu, 30 Mar 2017 18:11:33 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 27F6D1296CA for ; Thu, 30 Mar 2017 18:11:29 -0700 (PDT) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v2V15OuM035887 for ; Thu, 30 Mar 2017 21:11:26 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049295.ppops.net-00191d01. with ESMTP id 29hcwardbb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 30 Mar 2017 21:11:26 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v2V1BPIF012115 for ; Thu, 30 Mar 2017 21:11:25 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v2V1BM0u012095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 30 Mar 2017 21:11:23 -0400 Received: from MISOUT7MSGHUBAB.ITServices.sbc.com (MISOUT7MSGHUBAB.itservices.sbc.com [130.9.129.146]) by mlpi409.sfdc.sbc.com (RSA Interceptor) for ; Fri, 31 Mar 2017 01:11:06 GMT Received: from MISOUT7MSGUSRCG.ITServices.sbc.com ([169.254.7.103]) by MISOUT7MSGHUBAB.ITServices.sbc.com ([130.9.129.146]) with mapi id 14.03.0319.002; Thu, 30 Mar 2017 21:11:05 -0400 From: "HANSEN, TONY L" CC: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] indeterminisim of ARC-Seal b= value Thread-Index: AQHSqTOwNlojcxrP6UqdME5V5qIDh6GtbQDngAByFoD//8PYb4AApMiAgAAPTYD//83uAA== Date: Fri, 31 Mar 2017 01:11:05 +0000 Message-ID: References: <2978391.eJVbVTHBlo@kitterma-e6430> <01QCKR5S5OXK0003XB@mauve.mrochek.com> <01QCKXW9MZ4Q0003XB@mauve.mrochek.com> <1cf7325b-6f77-7cda-e330-025b7ddb0b92@dcrocker.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.110.240.124] Content-Type: multipart/alternative; boundary="_000_E0354A1C462146A08F2DBB6621A758EFattcom_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-30_21:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703310008 Archived-At: Subject: Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 31 Mar 2017 01:11:36 -0000 --_000_E0354A1C462146A08F2DBB6621A758EFattcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T25lIG9mIHRoZSByZWFzb25zIERLSU0gd2FzIHN1Y2Nlc3NmdWwgaW4gYmVjb21pbmcgaW50ZXJv cGVyYWJsZSB3YXMgbm90IHRoYXQgd2UgaGFkIGEgdGVzdCBzdWl0ZSB0byBmb3JjZSBjb25mb3Jt YW5jZSwgYnV0IGluc3RlYWQgdGhhdCB3ZSBoYWQgPm11bHRpcGxlPCB0ZXN0IHN1aXRlcyB0aGF0 IHdlcmUgYWJsZSB0byBzdWNjZXNzZnVsbHkgdmFsaWRhdGUgREtJTSBzaWduYXR1cmVzIGZyb20g bXVsdGlwbGUgaW1wbGVtZW50YXRpb25zLiBNeSB0ZXN0IHN1aXRlIGNhdWdodCBjb3JuZXIgY2Fz ZXMgdGhhdCBOZWTigJlzIGFuZCBZYWhvb+KAmXMgYW5kIEdvb2dsZeKAmXMgZGlkIG5vdCwgYW5k IHZpY2UgdmVyc2EgZm9yIGVhY2ggb25lIG9mIHRoZW0uIChNeSBjb21wYW55IGFjdHVhbGx5IGhh ZCB0d28gdG90YWxseSBpbmRlcGVuZGVudCBpbXBsZW1lbnRhdGlvbnMgb2YgREtJTSBzbyB0aGF0 IHdlIGNvdWxkIGRvIGludGVybmFsIHRlc3RpbmcgYWdhaW5zdCBhIGRpZmZlcmVudCBwbGF0Zm9y bS4gSXQgd2FzIGp1c3QgcHJ1ZGVudCB0byBkbyBpdCB0aGF0IHdheS4pDQoNCldoZW4gdGhlcmUg d2FzIGFuIGlzc3VlIGluIHNvbWVvbmXigJlzIHRlc3Qgc3VpdGUsIHdlIHdlcmUgdGhlbiBhYmxl IHRvIGRpc2N1c3Mgd2hldGhlciBpdCB3YXMgYW4gaXNzdWUgaW4gdGhlIHRlc3Qgc3VpdGUgdGhh dCBuZWVkZWQgdG8gYmUgZml4ZWQsIG9yIGl0IHdhcyBhbiBpc3N1ZSBpbiB0aGUgaW1wbGVtZW50 YXRpb24uIEEgc2luZ2xlIHRlc3Qgc3VpdGUgaXMgbmV2ZXIgc3VmZmljaWVudCDigJMgdGhhdOKA mXMgb25lIHJlYXNvbiB3ZSBwcmVmZXIgbXVsdGlwbGUgaW50ZXJvcGVyYXRpbmcgaW1wbGVtZW50 YXRpb25zIGluIG9yZGVyIGZvciBzb21ldGhpbmcgdG8gYmUgY29uc2lkZXJlZCBhbiBpbnRlcm5l dCBzdGFuZGFyZC4NCg0KQnkgdGhlIHdheSwgbm9uZSBvZiB1cyB0aGF0IGltcGxlbWVudGVkIERL SU0gdGVzdCBzdWl0ZXMgaGFkIGFuIGlzc3VlIHdpdGggdGhlIGhlYWRlciBvcmRlciBiZWluZyBk ZXRlcm1pbmVkIGJ5IHRoZSBzZW5kZXIuIEl0IG1ha2VzIHRoZSB2YWxpZGF0aW9uIGluZmluaXRl c2ltYWxseSB0cmlja2llciB0aGFuIGhhdmluZyBhIHByZWRldGVybWluZWQgaGVhZGVyIG9yZGVy Lg0KDQotMTAwMCB0byB0aGUgc3VnZ2VzdGlvbiBvZiBoYXZpbmcgYSBzaW5nbGUgY29uZm9ybWFu Y2UgdGVzdCBzdWl0ZSB0aGF0IGV2ZXJ5b25lIGxpdmVzIGFuZCBkaWVzIGJ5LiArMTAwMCB0byBt dWx0aXBsZSB0ZXN0IHN1aXRlcyB0aGF0IG11bHRpcGxlIHBlb3BsZSB3cml0ZSBhbmQgY2FuIGJl IHVzZWQgdG8gdGVzdCBhZ2FpbnN0Lg0KDQpJ4oCZbSBhbGwgZm9yIHlvdSwgU2V0aCBhbmQgUGV0 ZXIsIHRvIHdyaXRlIGEgdGVzdCBzdWl0ZS4gQnV0IG5vdGhpbmcgeW914oCZdmUgc2FpZCBzbyBm YXIgaGFzIGNvbnZpbmNlZCBtZSB0aGF0IGEgcHJlZGV0ZXJtaW5lZCBoZWFkZXIgb3JkZXIgb3Ig YSBzaW5nbGUgY29uZm9ybWFuY2UgdGVzdCBzdWl0ZSBpcyB3b3J0aCBwdXJzdWluZy4gT25lIG9m IG1hbnksIHN1cmUuDQoNCiAgICAgICAgICAgICAgICBUb255IEhhbnNlbg0KDQpGcm9tOiBkbWFy YyA8ZG1hcmMtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIFNldGggQmxhbmsgPHNldGhA dmFsaW1haWwuY29tPg0KRGF0ZTogVGh1cnNkYXksIE1hcmNoIDMwLCAyMDE3IGF0IDg6MTAgUE0N ClRvOiAiZGNyb2NrZXJAYmJpdy5uZXQiIDxkY3JvY2tlckBiYml3Lm5ldD4NCkNjOiAiTXVycmF5 IFMuIEt1Y2hlcmF3eSIgPHN1cGVydXNlckBnbWFpbC5jb20+LCAiZG1hcmNAaWV0Zi5vcmciIDxk bWFyY0BpZXRmLm9yZz4sIFNjb3R0IEtpdHRlcm1hbiA8c2tsaXN0QGtpdHRlcm1hbi5jb20+LCBQ ZXRlciBHb2xkc3RlaW4gPHBldGVyQHZhbGltYWlsLmNvbT4sICJuZWQrZG1hcmNAbXJvY2hlay5j b20iIDxuZWQrZG1hcmNAbXJvY2hlay5jb20+DQpTdWJqZWN0OiBSZTogW2RtYXJjLWlldGZdIGlu ZGV0ZXJtaW5pc2ltIG9mIEFSQy1TZWFsIGI9IHZhbHVlDQoNCkRhdmUsIElmIHdlIHdlcmUgb25s eSB0YWxraW5nIGFib3V0IEFSQyBTaWduaW5nIG1lc3NhZ2VzLCBJJ2QgZ2VuZXJhbGx5IGFncmVl IHdpdGggdGhlIGNvbW1lbnRzIG9uIHRoaXMgbGlzdC4NCg0KSG93ZXZlciwgQVJDIGlzIGZ1bmRh bWVudGFsbHkgZGlmZmVyZW50LiBJdCBpcyBhYm91dCBhIGNoYWluIG9mIG1lc3NhZ2VzIHRoYXQg dmFsaWRhdGUgZWFjaCBvdGhlci4gQW5kIEFSQydzIGNvbXBsZXhpdHkgaXMgbm90IGluIHRoZSBz aWduaW5nICh3aGVyZSBtb3N0IG9mIHRoaXMgY29udmVyc2F0aW9uIGhhcyBiZWVuIGZvY3VzZWQp LCBidXQgaW4gdGhpcyBjaGFpbiB2YWxpZGF0aW9uIGFuZCB0aGUgY2FzY2FkaW5nIGlzc3VlcyB0 aGF0IGNhbiBiZSBjcmVhdGVkIGJ5IGFueSBtZW1iZXIgb2YgdGhlIGNoYWluIGRvaW5nIHNvbWV0 aGluZyBzbGlnaHRseSB3cm9uZy4gQW5kIHNpbmNlICpldmVyeW9uZSogaW4gdGhlIGNoYWluIGV4 Y2VwdCB0aGUgaW5pdGlhbCBzaWduZXIgaXMgYWxzbyBhIHJlY2VpdmVyLCB0aGUgZmluYWwgcmVj ZWl2ZXIgc2ltcGx5IGNhbid0IG1ha2UgdXAgZm9yIG1pc3Rha2VzIGNhdXNlZCBieSBhIGxlc3Mg c2F2dnkgaW50ZXJtZWRpYXJ5IC0gdGhlIGNoYWluIHdpbGwgYWxyZWFkeSBiZSBicm9rZW4gYW5k IHVucmVjb3ZlcmFibGUuDQoNCkFSQyBhbHNvIGhhcyBhIGxvdCBvZiBzdWJ0bGV0eSB0aGF0IGlz IG1pc3NhYmxlIGF0IGludGVyb3BzIGJlY2F1c2Ugb2YgdGhpcy4gRm9yIGluc3RhbmNlLCBpZiBJ J20gbW9kaWZ5aW5nIGEgbWVzc2FnZSwgSSBuZWVkIHRvIHZhbGlkYXRlIHRoZSBpbmNvbWluZyBj aGFpbiwgdGhlbiBtYWtlIG15IG1vZGlmaWNhdGlvbnMsIGFuZCB0aGVuIHNpZ24gdGhlIG91dGdv aW5nIG1lc3NhZ2UuIEFuIGludGVybWVkaWFyeSBkb2luZyB0aGlzIHdyb25nIChzYXksIHZhbGlk YXRpbmcgYW5kIHRoZW4gc2lnbmluZyBhZnRlciBtZXNzYWdlIG1vZGlmaWNhdGlvbikgaXNuJ3Qg YSBidWcgYSBmaW5hbCByZWNlaXZlciBjYW4gZml4LiBBbmQgd2l0aG91dCBhIHNlcmlvdXNseSBj b21wbGV4IGludGVyb3Agd2l0aCBhIHRvbiBvZiBpbnRlcm1lZGlhcmllcyBhbmQgc2VuZGluZyBy ZWxhdGlvbnNoaXBzIG1hcHBlZCBvdXQgZm9yIHRlc3RpbmcsIGl0J3Mgbm90IGxpa2VseSBhbiBl cnJvciBpbiBhbnkgc3BlY2lmaWMgaW1wbGVtZW50YXRpb24gaGVyZSB3aWxsIGJlIGRpc2NvdmVy ZWQgdW50aWwgaXQncyB0b28gbGF0ZS4NCg0KVG8gbXkgdW5kZXJzdGFuZGluZywgd29ya2luZyBv biB0aGUgdGVzdCBzdWl0ZSBzaG9vayB0aGVzZSBpc3N1ZXMgb3V0IGJlY2F1c2UgdGhleSB3ZXJl IHdoYXQgY2F1c2VkIHByb2JsZW1zIHJ1bm5pbmcgdGhlIHRlc3Qgc3VpdGUgYXQgdGhlIGludGVy b3AgaW4gdGhlIGZpcnN0IHBsYWNlLiBTbyB0aGlzIGlzIGFjdHVhbGx5IGEgZ29vZCBhbmQgaGVh bHRoeSBwYXJ0IG9mIHRoZSBwcm9jZXNzLCBhbmQgaXMgdGhlIG5hdHVyYWwgY29uc2VxdWVuY2Ug b2YgdGhlIGludGVyb3BzLiBXaGF0IHdvcmtlZCBoZXJlIGZvciBES0lNIGlzIGluc3VmZmljaWVu dCB3aXRoIHRoZSBudWFuY2VzIG9mIEFSQy4NCg0KV2hhdCB3ZSd2ZSBiZWVuIGRpc2N1c3Npbmcg ZG9lc24ndCBqdXN0IGd1YXJhbnRlZSBhIHRlc3Qgc3VpdGUgY2FuIGJlIG1hZGUgdGhhdCB3b3Jr cyBmb3IgZXZlcnlvbmUgKHdoaWNoIGlzIGh1Z2UgaW4gaXRzZWxmKSwgYnV0IGNvbnN0cmFpbnMg dGhlIHByb2JsZW0gc3BhY2UgZm9yIGV2ZXJ5b25lIGludm9sdmVkIGluIGFuIEFSQyBjaGFpbi4g VGhpcyBpcyBjbGVhbiBhbmQgZGVzaXJhYmxlLg0KDQpTaW5jZSB0aGUgc3BlYyBpcyBub3QgZmlu YWxpemVkLCB0aGlzIGlzIHRoZSBwZXJmZWN0IHRpbWUgdG8gc2V0IGEgZGV0ZXJtaW5pc3RpYyBv cmRlciBmb3IgaGVhZGVycyB0aGF0IG5vIG9uZSBoYXMgZXZlbiBzZWVuIGJlZm9yZS4NCg0KU2V0 aA0KDQoNCk9uIFRodSwgTWFyIDMwLCAyMDE3IGF0IDQ6MTUgUE0sIERhdmUgQ3JvY2tlciA8ZGhj QGRjcm9ja2VyLm5ldDxtYWlsdG86ZGhjQGRjcm9ja2VyLm5ldD4+IHdyb3RlOg0KT24gMy8zMC8y MDE3IDEyOjEzIFBNLCBuZWQrZG1hcmNAbXJvY2hlay5jb208bWFpbHRvOm5lZCUyQmRtYXJjQG1y b2NoZWsuY29tPiB3cm90ZToNCkFuZCBnaXZlbiB0aGUgcmVsYXRpb25zaGlwIHdpdGggREtJTSBw ZW9wbGUgYXJlIGdvaW5nIHRvIGV4cGVjdCBBUkMNCnRvIHdvcmsgaW4gdGhlIHNhbWUgZ2VuZXJh bCB3YXksIG1haW5nIHN1Y2ggYSBjaGFuZ2UgYSBsZWFzdCBhc3RvbmlzaG1lbnQNCnByaW5jaXBs ZSB2aW9sYXRpb24uDQoNCg0KKzEwLg0KDQpUaGlzIHRocmVhZCBoYXMgYmVlbiBhY3RpdmUgZm9y IDYgZGF5cy4gIFRoYXQgaXMgNS41IGRheXMgbG9uZ2VyIHRoYW4gaXQgc2hvdWxkIGhhdmUgbGFz dGVkLCBhbmQgSSdtIGJlaW5nIGdlbmVyb3VzLg0KDQpJbnRlcm5ldCB0ZWNobm9sb2dpZXMgc3Vj Y2VlZCB0aHJvdWdoIGludGVyb3BlcmFiaWxpdHkgdGVzdGluZywgbm90IGNvbmZvcm1hbmNlIHRl c3RzLCBvciB0aGUgbGlrZS4gIENvbmZvcm1hbmNlIHRlc3RpbmcsIGFuZCB0aGUgbGlrZSwgYXJl IHVzZWZ1bCBmb3IgZWFybHktc3RhZ2UgYnVnLWZpbmRpbmcsIGJ1dCBub3QgZm9yICdjZXJ0aWZp Y2F0aW9uJy4gIFRoaXMgcG9pbnQgaGFzIGJlZW4gYSBkaXN0aW5ndWlzaGluZyBmZWF0dXJlIG9m IEludGVybmV0IHRlY2huaWNhbCB3b3JrIHNpbmNlIGJlZm9yZSB0aGUgSW50ZXJuZXQuDQoNCkFS QyBpcyBhIHNtYWxsIHJlLWNhc3Rpbmcgb2YgREtJTS4gIERLSU0gaGFzIHdvcmtlZCBmb3IgcXVp dGUgYSBmZXcgeWVhcnMuICBTb21lIGRldGFpbHMgb2YgQVJDIG5lZWQgdG8gYmUgZGlmZmVyZW50 IGZyb20gREtJTSwgYnV0IHRoZSBiYXNpYyBwYXJhZGlnbSAtLSBpbmNsdWRpbmcgdGhlIG1vZGVs IG9mIGFjaGlldmluZyBmaWVsZCBvcGVyYXRpb24gdGhyb3VnaCBpbnRlcm9wZXJhYmlsaXR5IHRl c3RpbmcgLS0gc2hvdWxkIGJlIHRoZSBzYW1lLg0KDQpNeSByZWFkaW5nIG9mIHRoaXMgdG9vLWxv bmcgbWVzc2FnZSB0aHJlYWQgaXMgdGhhdCB0aGVyZSBpcyBlc3NlbnRpYWxseSBubyBzdXBwb3J0 IGZvciBtYWtpbmcgQVJDJ3MgaGVhZGVyLXJlbGF0ZWQgaXNzdWVzIGFueSBkaWZmZXJlbnQgZnJv bSBES0lNJ3MsIHNvIEkgZW5jb3VyYWdlIHRoZSBjaGFpciB0byBzaHV0IHRoaXMgdGhyZWFkIGRv d24uDQoNCmQvDQoNCi0tDQpEYXZlIENyb2NrZXINCkJyYW5kZW5idXJnIEludGVybmV0V29ya2lu Zw0KYmJpdy5uZXQ8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0 dHAtM0FfX2JiaXcubmV0JmQ9RHdNRmFRJmM9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZyPUt6OFZk Z1BWY3RETlNOUEo2UHNCYXcmbT1NNXp6Vl9BazNHQ1I4bFpoQUhMRmZNQTBTdkdxU3p0V0VQSTBI NmE1WTJFJnM9WlgxQzg1bEZEb1dpWDBKODZGVWVMR1F4MzdFM1lRY0lUM0xJR3lDYWVXVSZlPT4N Cg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZG1h cmMgbWFpbGluZyBsaXN0DQpkbWFyY0BpZXRmLm9yZzxtYWlsdG86ZG1hcmNAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtYXJjPGh0dHBzOi8vdXJsZGVm ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxt YW5fbGlzdGluZm9fZG1hcmMmZD1Ed01GYVEmYz1MRllaLW85X0hVTWVNVFNRaWN2aklnJnI9S3o4 VmRnUFZjdEROU05QSjZQc0JhdyZtPU01enpWX0FrM0dDUjhsWmhBSExGZk1BMFN2R3FTenRXRVBJ MEg2YTVZMkUmcz1tSjU3RHRrcWVlOFJjWWtRblo5eXg2RWR5Tzh5Y0hodUpUbWVtM3RaeHk4JmU9 Pg0KDQoNCg0KLS0NCg0KW21hZ2UgcmVtb3ZlZCBieSBzZW5kZXIuIGxvZ28gZm9yIHNpZyBmaWxl LnBuZ10NCg0KQnJpbmdpbmcgVHJ1c3QgdG8gRW1haWwNCg0KU2V0aCBCbGFuayB8IEhlYWQgb2Yg UHJvZHVjdCBmb3IgT3BlbiBTb3VyY2UgYW5kIFByb3RvY29scw0Kc2V0aEB2YWxpbWFpbC5jb208 bWFpbHRvOnNldGhAdmFsaW1haWwuY29tPg0KKzEtNDE1LTg5NC0yNzI0PHRlbDo0MTUtODk0LTI3 MjQ+DQo= --_000_E0354A1C462146A08F2DBB6621A758EFattcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxuczptdj0iaHR0cDovL21hY1ZtbFNj aGVtYVVyaSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPGhlYWQ+ DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh cnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJUaXRsZSIgY29udGVudD0iIj4NCjxtZXRhIG5hbWU9 IktleXdvcmRzIiBjb250ZW50PSIiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJN aWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8IS0tW2lmICFtc29dPjxzdHls ZT52XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoqIHtiZWhhdmlvcjp1cmwo I2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQouc2hh cGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+PCFbZW5kaWZdLS0+PHN0 eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6QXJpYWw7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0 ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0Kc3Bh bi5ob2VuemINCgl7bXNvLXN0eWxlLW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0K CWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5 IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+T25lIG9mIHRoZSBy ZWFzb25zIERLSU0gd2FzIHN1Y2Nlc3NmdWwgaW4gYmVjb21pbmcgaW50ZXJvcGVyYWJsZSB3YXMg bm90IHRoYXQgd2UgaGFkIGEgdGVzdCBzdWl0ZSB0byBmb3JjZSBjb25mb3JtYW5jZSwgYnV0IGlu c3RlYWQgdGhhdCB3ZSBoYWQgJmd0O211bHRpcGxlJmx0OyB0ZXN0IHN1aXRlcyB0aGF0IHdlcmUg YWJsZSB0bw0KIHN1Y2Nlc3NmdWxseSB2YWxpZGF0ZSBES0lNIHNpZ25hdHVyZXMgZnJvbSBtdWx0 aXBsZSBpbXBsZW1lbnRhdGlvbnMuIE15IHRlc3Qgc3VpdGUgY2F1Z2h0IGNvcm5lciBjYXNlcyB0 aGF0IE5lZOKAmXMgYW5kIFlhaG9v4oCZcyBhbmQgR29vZ2xl4oCZcyBkaWQgbm90LCBhbmQgdmlj ZSB2ZXJzYSBmb3IgZWFjaCBvbmUgb2YgdGhlbS4gKE15IGNvbXBhbnkgYWN0dWFsbHkgaGFkIHR3 byB0b3RhbGx5IGluZGVwZW5kZW50IGltcGxlbWVudGF0aW9ucyBvZiBES0lNDQogc28gdGhhdCB3 ZSBjb3VsZCBkbyBpbnRlcm5hbCB0ZXN0aW5nIGFnYWluc3QgYSBkaWZmZXJlbnQgcGxhdGZvcm0u IEl0IHdhcyBqdXN0IHBydWRlbnQgdG8gZG8gaXQgdGhhdCB3YXkuKTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNhbGlicmkiPldoZW4gdGhlcmUgd2FzIGFuIGlzc3VlIGluIHNvbWVvbmXigJlzIHRlc3Qgc3Vp dGUsIHdlIHdlcmUgdGhlbiBhYmxlIHRvIGRpc2N1c3Mgd2hldGhlciBpdCB3YXMgYW4gaXNzdWUg aW4gdGhlIHRlc3Qgc3VpdGUgdGhhdCBuZWVkZWQgdG8gYmUgZml4ZWQsIG9yIGl0IHdhcyBhbiBp c3N1ZSBpbiB0aGUgaW1wbGVtZW50YXRpb24uDQogQSBzaW5nbGUgdGVzdCBzdWl0ZSBpcyBuZXZl ciBzdWZmaWNpZW50IOKAkyB0aGF04oCZcyBvbmUgcmVhc29uIHdlIHByZWZlciBtdWx0aXBsZSBp bnRlcm9wZXJhdGluZyBpbXBsZW1lbnRhdGlvbnMgaW4gb3JkZXIgZm9yIHNvbWV0aGluZyB0byBi ZSBjb25zaWRlcmVkIGFuIGludGVybmV0IHN0YW5kYXJkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGli cmkiPkJ5IHRoZSB3YXksIG5vbmUgb2YgdXMgdGhhdCBpbXBsZW1lbnRlZCBES0lNIHRlc3Qgc3Vp dGVzIGhhZCBhbiBpc3N1ZSB3aXRoIHRoZSBoZWFkZXIgb3JkZXIgYmVpbmcgZGV0ZXJtaW5lZCBi eSB0aGUgc2VuZGVyLiBJdCBtYWtlcyB0aGUgdmFsaWRhdGlvbiBpbmZpbml0ZXNpbWFsbHkgdHJp Y2tpZXIgdGhhbiBoYXZpbmcNCiBhIHByZWRldGVybWluZWQgaGVhZGVyIG9yZGVyLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OkNhbGlicmkiPi0xMDAwIHRvIHRoZSBzdWdnZXN0aW9uIG9mIGhhdmluZyBhIHNp bmdsZSBjb25mb3JtYW5jZSB0ZXN0IHN1aXRlIHRoYXQgZXZlcnlvbmUgbGl2ZXMgYW5kIGRpZXMg YnkuICYjNDM7MTAwMCB0byBtdWx0aXBsZSB0ZXN0IHN1aXRlcyB0aGF0IG11bHRpcGxlIHBlb3Bs ZSB3cml0ZSBhbmQgY2FuIGJlIHVzZWQgdG8gdGVzdCBhZ2FpbnN0LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNhbGlicmkiPknigJltIGFsbCBmb3IgeW91LCBTZXRoIGFuZCBQZXRlciwgdG8gd3JpdGUgYSB0 ZXN0IHN1aXRlLiBCdXQgbm90aGluZyB5b3XigJl2ZSBzYWlkIHNvIGZhciBoYXMgY29udmluY2Vk IG1lIHRoYXQgYSBwcmVkZXRlcm1pbmVkIGhlYWRlciBvcmRlciBvciBhIHNpbmdsZSBjb25mb3Jt YW5jZSB0ZXN0IHN1aXRlIGlzIHdvcnRoIHB1cnN1aW5nLg0KIE9uZSBvZiBtYW55LCBzdXJlLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBUb255IEhhbnNlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2NvbG9y OmJsYWNrIj5Gcm9tOiA8L3NwYW4+DQo8L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGli cmk7Y29sb3I6YmxhY2siPmRtYXJjICZsdDtkbWFyYy1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBi ZWhhbGYgb2YgU2V0aCBCbGFuayAmbHQ7c2V0aEB2YWxpbWFpbC5jb20mZ3Q7PGJyPg0KPGI+RGF0 ZTogPC9iPlRodXJzZGF5LCBNYXJjaCAzMCwgMjAxNyBhdCA4OjEwIFBNPGJyPg0KPGI+VG86IDwv Yj4mcXVvdDtkY3JvY2tlckBiYml3Lm5ldCZxdW90OyAmbHQ7ZGNyb2NrZXJAYmJpdy5uZXQmZ3Q7 PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDtNdXJyYXkgUy4gS3VjaGVyYXd5JnF1b3Q7ICZsdDtzdXBl cnVzZXJAZ21haWwuY29tJmd0OywgJnF1b3Q7ZG1hcmNAaWV0Zi5vcmcmcXVvdDsgJmx0O2RtYXJj QGlldGYub3JnJmd0OywgU2NvdHQgS2l0dGVybWFuICZsdDtza2xpc3RAa2l0dGVybWFuLmNvbSZn dDssIFBldGVyIEdvbGRzdGVpbiAmbHQ7cGV0ZXJAdmFsaW1haWwuY29tJmd0OywgJnF1b3Q7bmVk JiM0MztkbWFyY0Btcm9jaGVrLmNvbSZxdW90OyAmbHQ7bmVkJiM0MztkbWFyY0Btcm9jaGVrLmNv bSZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtkbWFyYy1pZXRmXSBpbmRldGVybWluaXNp bSBvZiBBUkMtU2VhbCBiPSB2YWx1ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRhdmUsIElmIHdlIHdlcmUgb25seSB0 YWxraW5nIGFib3V0IEFSQyBTaWduaW5nIG1lc3NhZ2VzLCBJJ2QgZ2VuZXJhbGx5IGFncmVlIHdp dGggdGhlIGNvbW1lbnRzIG9uIHRoaXMgbGlzdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93ZXZlciwgQVJDIGlzIGZ1bmRhbWVudGFsbHkg ZGlmZmVyZW50LiBJdCBpcyBhYm91dCBhIGNoYWluIG9mIG1lc3NhZ2VzIHRoYXQgdmFsaWRhdGUg ZWFjaCBvdGhlci4gQW5kIEFSQydzIGNvbXBsZXhpdHkgaXMgbm90IGluIHRoZSBzaWduaW5nICh3 aGVyZSBtb3N0IG9mIHRoaXMgY29udmVyc2F0aW9uIGhhcyBiZWVuIGZvY3VzZWQpLCBidXQgaW4g dGhpcyBjaGFpbiB2YWxpZGF0aW9uIGFuZCB0aGUgY2FzY2FkaW5nDQogaXNzdWVzIHRoYXQgY2Fu IGJlIGNyZWF0ZWQgYnkgYW55IG1lbWJlciBvZiB0aGUgY2hhaW4gZG9pbmcgc29tZXRoaW5nIHNs aWdodGx5IHdyb25nLiBBbmQgc2luY2UgKmV2ZXJ5b25lKiBpbiB0aGUgY2hhaW4gZXhjZXB0IHRo ZSBpbml0aWFsIHNpZ25lciBpcyBhbHNvIGEgcmVjZWl2ZXIsIHRoZSBmaW5hbCByZWNlaXZlciBz aW1wbHkgY2FuJ3QgbWFrZSB1cCBmb3IgbWlzdGFrZXMgY2F1c2VkIGJ5IGEgbGVzcyBzYXZ2eSBp bnRlcm1lZGlhcnkgLQ0KIHRoZSBjaGFpbiB3aWxsIGFscmVhZHkgYmUgYnJva2VuIGFuZCB1bnJl Y292ZXJhYmxlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5BUkMgYWxzbyBoYXMgYSBsb3Qgb2Ygc3VidGxldHkgdGhhdCBpcyBtaXNzYWJsZSBh dCBpbnRlcm9wcyBiZWNhdXNlIG9mIHRoaXMuIEZvciBpbnN0YW5jZSwgaWYgSSdtIG1vZGlmeWlu ZyBhIG1lc3NhZ2UsIEkgbmVlZCB0byB2YWxpZGF0ZSB0aGUgaW5jb21pbmcgY2hhaW4sIHRoZW4g bWFrZSBteSBtb2RpZmljYXRpb25zLCBhbmQgdGhlbiBzaWduIHRoZSBvdXRnb2luZyBtZXNzYWdl LiBBbiBpbnRlcm1lZGlhcnkNCiBkb2luZyB0aGlzIHdyb25nIChzYXksIHZhbGlkYXRpbmcgYW5k IHRoZW4gc2lnbmluZyBhZnRlciBtZXNzYWdlIG1vZGlmaWNhdGlvbikgaXNuJ3QgYSBidWcgYSBm aW5hbCByZWNlaXZlciBjYW4gZml4LiBBbmQgd2l0aG91dCBhIHNlcmlvdXNseSBjb21wbGV4IGlu dGVyb3Agd2l0aCBhIHRvbiBvZiBpbnRlcm1lZGlhcmllcyBhbmQgc2VuZGluZyByZWxhdGlvbnNo aXBzIG1hcHBlZCBvdXQgZm9yIHRlc3RpbmcsIGl0J3Mgbm90IGxpa2VseSBhbiBlcnJvcg0KIGlu IGFueSBzcGVjaWZpYyBpbXBsZW1lbnRhdGlvbiBoZXJlIHdpbGwgYmUgZGlzY292ZXJlZCB1bnRp bCBpdCdzIHRvbyBsYXRlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UbyBteSB1bmRlcnN0YW5kaW5nLCB3b3JraW5nIG9uIHRoZSB0ZXN0IHN1 aXRlIHNob29rIHRoZXNlIGlzc3VlcyBvdXQgYmVjYXVzZSB0aGV5IHdlcmUgd2hhdCBjYXVzZWQg cHJvYmxlbXMgcnVubmluZyB0aGUgdGVzdCBzdWl0ZSBhdCB0aGUgaW50ZXJvcCBpbiB0aGUgZmly c3QgcGxhY2UuIFNvIHRoaXMgaXMgYWN0dWFsbHkgYSBnb29kIGFuZCBoZWFsdGh5IHBhcnQgb2Yg dGhlIHByb2Nlc3MsIGFuZCBpcyB0aGUNCiBuYXR1cmFsIGNvbnNlcXVlbmNlIG9mIHRoZSBpbnRl cm9wcy4gV2hhdCB3b3JrZWQgaGVyZSBmb3IgREtJTSBpcyBpbnN1ZmZpY2llbnQgd2l0aCB0aGUg bnVhbmNlcyBvZiBBUkMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPldoYXQgd2UndmUgYmVlbiBkaXNjdXNzaW5nIGRvZXNuJ3QganVzdCBndWFy YW50ZWUgYSB0ZXN0IHN1aXRlIGNhbiBiZSBtYWRlIHRoYXQgd29ya3MgZm9yIGV2ZXJ5b25lICh3 aGljaCBpcyBodWdlIGluIGl0c2VsZiksIGJ1dCBjb25zdHJhaW5zIHRoZSBwcm9ibGVtIHNwYWNl IGZvciBldmVyeW9uZSBpbnZvbHZlZCBpbiBhbiBBUkMgY2hhaW4uIFRoaXMgaXMgY2xlYW4gYW5k IGRlc2lyYWJsZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+U2luY2UgdGhlIHNwZWMgaXMgbm90IGZpbmFsaXplZCwgdGhpcyBpcyB0aGUgcGVy ZmVjdCB0aW1lIHRvIHNldCBhIGRldGVybWluaXN0aWMgb3JkZXIgZm9yIGhlYWRlcnMgdGhhdCBu byBvbmUgaGFzIGV2ZW4gc2VlbiBiZWZvcmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNldGg8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIE1hciAzMCwgMjAxNyBhdCA0OjE1 IFBNLCBEYXZlIENyb2NrZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpkaGNAZGNyb2NrZXIubmV0IiB0 YXJnZXQ9Il9ibGFuayI+ZGhjQGRjcm9ja2VyLm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDMvMzAvMjAxNyAxMjox MyBQTSwgPGEgaHJlZj0ibWFpbHRvOm5lZCUyQmRtYXJjQG1yb2NoZWsuY29tIiB0YXJnZXQ9Il9i bGFuayI+DQpuZWQmIzQzO2RtYXJjQG1yb2NoZWsuY29tPC9hPiB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmQgZ2l2ZW4gdGhlIHJlbGF0 aW9uc2hpcCB3aXRoIERLSU0gcGVvcGxlIGFyZSBnb2luZyB0byBleHBlY3QgQVJDPGJyPg0KdG8g d29yayBpbiB0aGUgc2FtZSBnZW5lcmFsIHdheSwgbWFpbmcgc3VjaCBhIGNoYW5nZSBhIGxlYXN0 IGFzdG9uaXNobWVudDxicj4NCnByaW5jaXBsZSB2aW9sYXRpb24uPG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQomIzQzOzEwLjxi cj4NCjxicj4NClRoaXMgdGhyZWFkIGhhcyBiZWVuIGFjdGl2ZSBmb3IgNiBkYXlzLiZuYnNwOyBU aGF0IGlzIDUuNSBkYXlzIGxvbmdlciB0aGFuIGl0IHNob3VsZCBoYXZlIGxhc3RlZCwgYW5kIEkn bSBiZWluZyBnZW5lcm91cy48YnI+DQo8YnI+DQpJbnRlcm5ldCB0ZWNobm9sb2dpZXMgc3VjY2Vl ZCB0aHJvdWdoIGludGVyb3BlcmFiaWxpdHkgdGVzdGluZywgbm90IGNvbmZvcm1hbmNlIHRlc3Rz LCBvciB0aGUgbGlrZS4mbmJzcDsgQ29uZm9ybWFuY2UgdGVzdGluZywgYW5kIHRoZSBsaWtlLCBh cmUgdXNlZnVsIGZvciBlYXJseS1zdGFnZSBidWctZmluZGluZywgYnV0IG5vdCBmb3IgJ2NlcnRp ZmljYXRpb24nLiZuYnNwOyBUaGlzIHBvaW50IGhhcyBiZWVuIGEgZGlzdGluZ3Vpc2hpbmcgZmVh dHVyZSBvZiBJbnRlcm5ldA0KIHRlY2huaWNhbCB3b3JrIHNpbmNlIGJlZm9yZSB0aGUgSW50ZXJu ZXQuPGJyPg0KPGJyPg0KQVJDIGlzIGEgc21hbGwgcmUtY2FzdGluZyBvZiBES0lNLiZuYnNwOyBE S0lNIGhhcyB3b3JrZWQgZm9yIHF1aXRlIGEgZmV3IHllYXJzLiZuYnNwOyBTb21lIGRldGFpbHMg b2YgQVJDIG5lZWQgdG8gYmUgZGlmZmVyZW50IGZyb20gREtJTSwgYnV0IHRoZSBiYXNpYyBwYXJh ZGlnbSAtLSBpbmNsdWRpbmcgdGhlIG1vZGVsIG9mIGFjaGlldmluZyBmaWVsZCBvcGVyYXRpb24g dGhyb3VnaCBpbnRlcm9wZXJhYmlsaXR5IHRlc3RpbmcgLS0gc2hvdWxkIGJlIHRoZSBzYW1lLjxi cj4NCjxicj4NCk15IHJlYWRpbmcgb2YgdGhpcyB0b28tbG9uZyBtZXNzYWdlIHRocmVhZCBpcyB0 aGF0IHRoZXJlIGlzIGVzc2VudGlhbGx5IG5vIHN1cHBvcnQgZm9yIG1ha2luZyBBUkMncyBoZWFk ZXItcmVsYXRlZCBpc3N1ZXMgYW55IGRpZmZlcmVudCBmcm9tIERLSU0ncywgc28gSSBlbmNvdXJh Z2UgdGhlIGNoYWlyIHRvIHNodXQgdGhpcyB0aHJlYWQgZG93bi48c3BhbiBzdHlsZT0iY29sb3I6 Izg4ODg4OCI+PGJyPg0KPGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+ZC88L3NwYW4+PGJyPg0K PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+LS0gPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJo b2VuemIiPkRhdmUgQ3JvY2tlcjwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj5CcmFu ZGVuYnVyZyBJbnRlcm5ldFdvcmtpbmc8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+ PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAt M0FfX2JiaXcubmV0JmFtcDtkPUR3TUZhUSZhbXA7Yz1MRllaLW85X0hVTWVNVFNRaWN2aklnJmFt cDtyPUt6OFZkZ1BWY3RETlNOUEo2UHNCYXcmYW1wO209TTV6elZfQWszR0NSOGxaaEFITEZmTUEw U3ZHcVN6dFdFUEkwSDZhNVkyRSZhbXA7cz1aWDFDODVsRkRvV2lYMEo4NkZVZUxHUXgzN0UzWVFj SVQzTElHeUNhZVdVJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPmJiaXcubmV0PC9hPjwvc3Bhbj48 L3NwYW4+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpkbWFyYyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86ZG1hcmNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kbWFyY0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVm PSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3 dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2RtYXJjJmFtcDtkPUR3TUZhUSZhbXA7Yz1MRlla LW85X0hVTWVNVFNRaWN2aklnJmFtcDtyPUt6OFZkZ1BWY3RETlNOUEo2UHNCYXcmYW1wO209TTV6 elZfQWszR0NSOGxaaEFITEZmTUEwU3ZHcVN6dFdFUEkwSDZhNVkyRSZhbXA7cz1tSjU3RHRrcWVl OFJjWWtRblo5eXg2RWR5Tzh5Y0hodUpUbWVtM3RaeHk4JmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1hcmM8L2E+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+LS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9t Oi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkFyaWFs O2NvbG9yOmJsYWNrO2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIj48 aW1nIGJvcmRlcj0iMCIgd2lkdGg9IjIzOSIgaGVpZ2h0PSI2MSIgaWQ9Il94MDAwMF9pMTAyNSIg c3JjPSJjaWQ6V29yZCUyMFdvcmslMjBGaWxlJTIwRF8uanBnIiBhbHQ9Im1hZ2UgcmVtb3ZlZCBi eSBzZW5kZXIuIGxvZ28gZm9yIHNpZyBmaWxlLnBuZyI+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS41cHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGlu O21hcmdpbi1ib3R0b206LjAwMDFwdCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiM4Mzg5ODAiPkJyaW5naW5nIFRydXN0IHRvIEVtYWls PC9zcGFuPjwvaT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOiM4Mzg5ODAi PlNldGggQmxhbmsgfCBIZWFkIG9mIFByb2R1Y3QgZm9yIE9wZW4gU291cmNlIGFuZCBQcm90b2Nv bHM8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6QXJpYWwiPjxhIGhyZWY9Im1haWx0bzpzZXRoQHZhbGltYWlsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPnNldGhAdmFsaW1haWwuY29tPC9hPjxzcGFuIHN0eWxlPSJjb2xvcjojODM4 OTgwIj48YnI+DQo8L3NwYW4+PGEgaHJlZj0idGVsOjQxNS04OTQtMjcyNCIgdGFyZ2V0PSJfYmxh bmsiPiYjNDM7MS00MTUtODk0LTI3MjQ8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E0354A1C462146A08F2DBB6621A758EFattcom_-- From nobody Thu Mar 30 18:46:03 2017 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 9116B1286CA for ; Thu, 30 Mar 2017 18:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Ps7BVVykWCP for ; Thu, 30 Mar 2017 18:45:58 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8F79129566 for ; Thu, 30 Mar 2017 18:45:55 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id r142so55923618qke.2 for ; Thu, 30 Mar 2017 18:45:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+xcvvr1wW1HC1zRTwbyOTko+rZj/1CbkxLVTSEoJ3xw=; b=FFdytoCpVDoTq3Qy/+CNLcStgUomV6vArY0LrvNIoQ6KolwLxwjGFWbEAkAB77jnUq iIxcFFQzEajCQUejAT6IsfsYe+3itvaJKE6spv9YS2F3jiH+2TxX/y7vkM8UCcStOZH7 QZu9NL5WJaYH5GqUaXzvuSxir6m8dX1BwN3NHkdNKfJ/WufclUmbX+Z0QFqddzlR031+ mJmf4aWYZTjdBFqQ76bwSIIfMTBYAR5excnfSu4kk5Lxk1eyCBxyonbXXrw5DGHQopOI 63GebRJ/wLIaZ+i4h0FVACFJbH1WBKNiF6QVeAcdC8CzRJ+wmyFHGm6PfdjY/iSS9F0t KGNw== 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=+xcvvr1wW1HC1zRTwbyOTko+rZj/1CbkxLVTSEoJ3xw=; b=Rx/zEg0xCQMj4UDBstKMjDUOVbsc0JiNNYedLHHPXcG8R9YyeO70uXStUUx3AGLSsi nrzNfTMfkl6V2qJXUGPkSnKBEHjrkLIgM0jA1/O0lKYqglXAGPt/KThaER/Lwr1Vn/i3 3+GQXH8nvOR0J9A1/1TS5B+dF3qip3vKYDAZdrLjvhuSiIab6aO/uUjU1ZOkDWKxdU7L 7uFQY1BtvibpMBuAb0F443f/xNNVE99aE40FIR5bKya0poGdjj0hP2oNHP5Ed4pTQ4gp KAhWJn7da5ZX2P8nMxmuwkisYlB/ZjGdHVf4IMta6KYXRbCFII7AiY5MZY07pLWvSZ1s oyJA== X-Gm-Message-State: AFeK/H0uxuQw5eML/eNlUlbuajgchbDlMG3U7NQmVfGnqY6vthoC/FNqLpZLyNmH+v1QF9xXbAx5xhQWbbhF9g== X-Received: by 10.55.157.67 with SMTP id g64mr417692qke.192.1490924754888; Thu, 30 Mar 2017 18:45:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.42.166 with HTTP; Thu, 30 Mar 2017 18:45:34 -0700 (PDT) In-Reply-To: References: <2978391.eJVbVTHBlo@kitterma-e6430> <01QCKR5S5OXK0003XB@mauve.mrochek.com> <01QCKXW9MZ4Q0003XB@mauve.mrochek.com> <1cf7325b-6f77-7cda-e330-025b7ddb0b92@dcrocker.net> From: Seth Blank Date: Thu, 30 Mar 2017 18:45:34 -0700 Message-ID: To: "HANSEN, TONY L" Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c05626e671b91054bfcf85b Archived-At: Subject: Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 31 Mar 2017 01:46:01 -0000 --94eb2c05626e671b91054bfcf85b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, +1000 to many test suites. But no test suite can function without a deterministic order of fields in the header unless it also includes an ARC implementation for signing/validating, which is where this conversation started and why we care so much about discussing this ordering. On Thu, Mar 30, 2017 at 6:11 PM, HANSEN, TONY L wrote: > One of the reasons DKIM was successful in becoming interoperable was not > that we had a test suite to force conformance, but instead that we had > >multiple< test suites that were able to successfully validate DKIM > signatures from multiple implementations. My test suite caught corner cas= es > that Ned=E2=80=99s and Yahoo=E2=80=99s and Google=E2=80=99s did not, and = vice versa for each one of > them. (My company actually had two totally independent implementations of > DKIM so that we could do internal testing against a different platform. I= t > was just prudent to do it that way.) > > > > When there was an issue in someone=E2=80=99s test suite, we were then abl= e to > discuss whether it was an issue in the test suite that needed to be fixed= , > or it was an issue in the implementation. A single test suite is never > sufficient =E2=80=93 that=E2=80=99s one reason we prefer multiple interop= erating > implementations in order for something to be considered an internet > standard. > > > > By the way, none of us that implemented DKIM test suites had an issue wit= h > the header order being determined by the sender. It makes the validation > infinitesimally trickier than having a predetermined header order. > > > > -1000 to the suggestion of having a single conformance test suite that > everyone lives and dies by. +1000 to multiple test suites that multiple > people write and can be used to test against. > > > > I=E2=80=99m all for you, Seth and Peter, to write a test suite. But nothi= ng you=E2=80=99ve > said so far has convinced me that a predetermined header order or a singl= e > conformance test suite is worth pursuing. One of many, sure. > > > > Tony Hansen > > > > *From: *dmarc on behalf of Seth Blank < > seth@valimail.com> > *Date: *Thursday, March 30, 2017 at 8:10 PM > *To: *"dcrocker@bbiw.net" > *Cc: *"Murray S. Kucherawy" , "dmarc@ietf.org" < > dmarc@ietf.org>, Scott Kitterman , Peter Goldstein = < > peter@valimail.com>, "ned+dmarc@mrochek.com" > *Subject: *Re: [dmarc-ietf] indeterminisim of ARC-Seal b=3D value > > > > Dave, If we were only talking about ARC Signing messages, I'd generally > agree with the comments on this list. > > > > However, ARC is fundamentally different. It is about a chain of messages > that validate each other. And ARC's complexity is not in the signing (whe= re > most of this conversation has been focused), but in this chain validation > and the cascading issues that can be created by any member of the chain > doing something slightly wrong. And since *everyone* in the chain except > the initial signer is also a receiver, the final receiver simply can't ma= ke > up for mistakes caused by a less savvy intermediary - the chain will > already be broken and unrecoverable. > > > > ARC also has a lot of subtlety that is missable at interops because of > this. For instance, if I'm modifying a message, I need to validate the > incoming chain, then make my modifications, and then sign the outgoing > message. An intermediary doing this wrong (say, validating and then signi= ng > after message modification) isn't a bug a final receiver can fix. And > without a seriously complex interop with a ton of intermediaries and > sending relationships mapped out for testing, it's not likely an error in > any specific implementation here will be discovered until it's too late. > > > > To my understanding, working on the test suite shook these issues out > because they were what caused problems running the test suite at the > interop in the first place. So this is actually a good and healthy part o= f > the process, and is the natural consequence of the interops. What worked > here for DKIM is insufficient with the nuances of ARC. > > > > What we've been discussing doesn't just guarantee a test suite can be mad= e > that works for everyone (which is huge in itself), but constrains the > problem space for everyone involved in an ARC chain. This is clean and > desirable. > > > > Since the spec is not finalized, this is the perfect time to set a > deterministic order for headers that no one has even seen before. > > > > Seth > > > > > > On Thu, Mar 30, 2017 at 4:15 PM, Dave Crocker wrote: > > On 3/30/2017 12:13 PM, ned+dmarc@mrochek.com wrote: > > And given the relationship with DKIM people are going to expect ARC > to work in the same general way, maing such a change a least astonishment > principle violation. > > > > +10. > > This thread has been active for 6 days. That is 5.5 days longer than it > should have lasted, and I'm being generous. > > Internet technologies succeed through interoperability testing, not > conformance tests, or the like. Conformance testing, and the like, are > useful for early-stage bug-finding, but not for 'certification'. This > point has been a distinguishing feature of Internet technical work since > before the Internet. > > ARC is a small re-casting of DKIM. DKIM has worked for quite a few > years. Some details of ARC need to be different from DKIM, but the basic > paradigm -- including the model of achieving field operation through > interoperability testing -- should be the same. > > My reading of this too-long message thread is that there is essentially n= o > support for making ARC's header-related issues any different from DKIM's, > so I encourage the chair to shut this thread down. > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > > > > > > -- > > [image: mage removed by sender. logo for sig file.png] > > *Bringing Trust to Email* > > Seth Blank | Head of Product for Open Source and Protocols > > seth@valimail.com > +1-415-894-2724 <415-894-2724> > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --=20 [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols seth@valimail.com +1-415-894-2724 <415-894-2724> --94eb2c05626e671b91054bfcf85b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, +1000 to many test suites.

But no = test suite can function without a deterministic order of fields in the head= er unless it also includes an ARC implementation for signing/validating, wh= ich is where this conversation started and why we care so much about discus= sing this ordering.

On Thu, Mar 30, 2017 at 6:11 PM, HANSEN, TONY L <tony@att.com= > wrote:

One of the reasons DKIM was successful in becoming interoperable was not t= hat we had a test suite to force conformance, but instead that we had >m= ultiple< test suites that were able to successfully validate DKIM signatures from multiple implementations. My te= st suite caught corner cases that Ned=E2=80=99s and Yahoo=E2=80=99s and Goo= gle=E2=80=99s did not, and vice versa for each one of them. (My company act= ually had two totally independent implementations of DKIM so that we could do internal testing against a different platform. It was = just prudent to do it that way.)

=C2=A0

When there was an issue in someone=E2=80=99s test suite, we were then able= to discuss whether it was an issue in the test suite that needed to be fix= ed, or it was an issue in the implementation. A single test suite is never sufficient =E2=80=93 that=E2=80=99s one reaso= n we prefer multiple interoperating implementations in order for something = to be considered an internet standard.

=C2=A0

By the way, none of us that implemented DKIM test suites had an issue with= the header order being determined by the sender. It makes the validation i= nfinitesimally trickier than having a predetermined header order.

=C2=A0

-1000 to the suggestion of having a single conformance test suite that eve= ryone lives and dies by. +1000 to multiple test suites that multiple people= write and can be used to test against.

=C2=A0

I=E2=80=99m all for you, Seth and Peter, to write a test suite. But nothin= g you=E2=80=99ve said so far has convinced me that a predetermined header o= rder or a single conformance test suite is worth pursuing. One of many, sure.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Tony Hansen

=C2=A0

F= rom: dmarc <dmarc-bounces@ietf.org&g= t; on behalf of Seth Blank <seth@valimail.com>
Date: Thursday, March 30, 2017 at 8:10 PM
To: "dcr= ocker@bbiw.net" <dcrocker@bbiw.net>
Cc: "Murray S. Kucherawy" <superuser@gmail.com>, "dmarc@ietf.org" <dmarc@ietf.org>, Scot= t Kitterman <s= klist@kitterman.com>, Peter Goldstein <peter@valimail.com>, "ned+dmarc@mrochek.com= " <ned= +dmarc@mrochek.com>
Subject: Re: [dmarc-ietf] indeterminisim of ARC-Seal b=3D value

=C2=A0

Dave, If we were only talking about ARC Signing mess= ages, I'd generally agree with the comments on this list.=

=C2=A0

However, ARC is fundamentally different. It is about= a chain of messages that validate each other. And ARC's complexity is = not in the signing (where most of this conversation has been focused), but = in this chain validation and the cascading issues that can be created by any member of the chain doing something slig= htly wrong. And since *everyone* in the chain except the initial signer is = also a receiver, the final receiver simply can't make up for mistakes c= aused by a less savvy intermediary - the chain will already be broken and unrecoverable.

=C2=A0

ARC also has a lot of subtlety that is missable at i= nterops because of this. For instance, if I'm modifying a message, I ne= ed to validate the incoming chain, then make my modifications, and then sig= n the outgoing message. An intermediary doing this wrong (say, validating and then signing after message modificat= ion) isn't a bug a final receiver can fix. And without a seriously comp= lex interop with a ton of intermediaries and sending relationships mapped o= ut for testing, it's not likely an error in any specific implementation here will be discovered until it's too = late.

=C2=A0

To my understanding, working on the test suite shook= these issues out because they were what caused problems running the test s= uite at the interop in the first place. So this is actually a good and heal= thy part of the process, and is the natural consequence of the interops. What worked here for DKIM is insuffic= ient with the nuances of ARC.

=C2=A0

What we've been discussing doesn't just guar= antee a test suite can be made that works for everyone (which is huge in it= self), but constrains the problem space for everyone involved in an ARC cha= in. This is clean and desirable.

=C2=A0

Since the spec is not finalized, this is the perfect= time to set a deterministic order for headers that no one has even seen be= fore.

=C2=A0

Seth

=C2=A0

=C2=A0

On Thu, Mar 30, 2017 at 4:15 PM, Dave Crocker <dhc@dcrocker.net>= ; wrote:

On 3/30/2017 12:13 PM, ned+dmarc@mrochek.com wrote:

And given the relationship with DKIM people are goin= g to expect ARC
to work in the same general way, maing such a change a least astonishment principle violation.



+10.

This thread has been active for 6 days.=C2=A0 That is 5.5 days longer than = it should have lasted, and I'm being generous.

Internet technologies succeed through interoperability testing, not conform= ance tests, or the like.=C2=A0 Conformance testing, and the like, are usefu= l for early-stage bug-finding, but not for 'certification'.=C2=A0 T= his point has been a distinguishing feature of Internet technical work since before the Internet.

ARC is a small re-casting of DKIM.=C2=A0 DKIM has worked for quite a few ye= ars.=C2=A0 Some details of ARC need to be different from DKIM, but the basi= c paradigm -- including the model of achieving field operation through inte= roperability testing -- should be the same.

My reading of this too-long message thread is that there is essentially no = support for making ARC's header-related issues any different from DKIM&= #39;s, so I encourage the chair to shut this thread down.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net



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



=C2=A0

--

3D"mage=

Bringing Trust to Email<= span style=3D"font-size:9.5pt">

Seth Blank | Head of Product for Open S= ource and Protocols

<= a href=3D"mailto:seth@valimail.com" target=3D"_blank">seth@valimail.com=
+1-415-894-2724


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




--
=

3D"logo

Bringing Trust to Email

Seth Blank | Head of Product for Open Source and Protocols

<= a href=3D"mailto:seth@valimail.com" target=3D"_blank">seth@valimail.com= <= br>+1-415-894-2724
--94eb2c05626e671b91054bfcf85b-- From nobody Thu Mar 30 19:35:27 2017 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 27EA2129692 for ; Thu, 30 Mar 2017 19:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=bbiw.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 94lphu53YQFk for ; Thu, 30 Mar 2017 19:35:23 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 0EE23127A90 for ; Thu, 30 Mar 2017 19:35:23 -0700 (PDT) Received: from [192.168.0.158] (50-232-11-130-static.hfc.comcastbusiness.net [50.232.11.130]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v2V2bQ2p005336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 30 Mar 2017 19:37:26 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bbiw.net; s=default; t=1490927848; bh=4IETOQqj0WpVH9f4wMCrXoDN4iRt1rCT6Y3DkahiYZw=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=gcqGs4mzcwZ+0ZD0+cLM4rLJ2My3eUkcmV9shcoC8Vi9P4fv5c1AsxtZ/xlI+9OP6 09GuKvFjHIcInPxK4Ils9EM9UnnrmJUrDiJu++s9DLIsRGEljJE6oLrHcmpDDJmXAO DH5MLA0TUrlSeBEEwwePTqQw4AYCBfFzzuKb7bNI= To: Seth Blank References: <2978391.eJVbVTHBlo@kitterma-e6430> <01QCKR5S5OXK0003XB@mauve.mrochek.com> <01QCKXW9MZ4Q0003XB@mauve.mrochek.com> <1cf7325b-6f77-7cda-e330-025b7ddb0b92@dcrocker.net> Cc: ned+dmarc@mrochek.com, Peter Goldstein , Scott Kitterman , "dmarc@ietf.org" , "Murray S. Kucherawy" From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <2f516997-7c5e-2fad-1aeb-51590383f9c7@bbiw.net> Date: Thu, 30 Mar 2017 21:35:18 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 31 Mar 2017 02:35:24 -0000 On 3/30/2017 7:10 PM, Seth Blank wrote: > Dave, If we were only talking about ARC Signing messages, I'd generally > agree with the comments on this list. > > However, ARC is fundamentally different. It is about a chain of messages Either you are correct, in which case ARC has been made far too fragile to be able to work with any serious degree of reliability at scale, or you are wrong, in which case the fact of there being a sequence of DKIM-ish signatures has the same requirements as for individual signatures. What you have been getting told by a range of folk with quite a lengthy history of DKIM and email deployment experience is in line with the latter. So to the extent that you are sure things really are that fragile, the answer is not going to be a test suite or excessively demanding algorithms, but a re-thinking of the details, to make the implementation and deployment issues simpler. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Mar 30 19:54:43 2017 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 7C81C120046 for ; Thu, 30 Mar 2017 19:54:42 -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 c9q6x5O023m5 for ; Thu, 30 Mar 2017 19:54:41 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A11C126CE8 for ; Thu, 30 Mar 2017 19:54:40 -0700 (PDT) Received: (qmail 49145 invoked from network); 31 Mar 2017 02:54:39 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 31 Mar 2017 02:54:39 -0000 Date: 31 Mar 2017 02:54:17 -0000 Message-ID: <20170331025417.6484.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org Cc: dcrocker@bbiw.net In-Reply-To: <1cf7325b-6f77-7cda-e330-025b7ddb0b92@dcrocker.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 31 Mar 2017 02:54:43 -0000 >My reading of this too-long message thread is that there is essentially >no support for making ARC's header-related issues any different from >DKIM's, so I encourage the chair to shut this thread down. What he said. Can we please limit subsequent discussion of testing about how to test ARC as defined and implemented, not some not-ARC that is not defined and certainly will not be implemented? R's, John From nobody Thu Mar 30 20:41:57 2017 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 943A512762F for ; Thu, 30 Mar 2017 20:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DhEmooIV1w6 for ; Thu, 30 Mar 2017 20:41:52 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EA5412970F for ; Thu, 30 Mar 2017 20:41:52 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id r142so57304042qke.2 for ; Thu, 30 Mar 2017 20:41:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tCJUyoKHfsjs4CnfaEahfqfOkJhi2S2ZHvguYIkNXzE=; b=FDqGZxinH/UDvHjVS+gObjWaoF1zxo0J4r0YHNlXQPEko4EmRPYt6vrvlmENofqOc+ qKeELlVILWfFYa0BbNOYWpDzwRjIDFvL8MBjk8yowy5R9U9Yt5ZXuJ8/bujUBfsDc1Yj jurIbkRIOO9N7kYXrEUx97DBG/IOeSKUMVvLFnNE/hKT155lTjB+UgkXOLRf9331NsN7 7Sy1bwHLNrfXsE65u4d6kw1ZcaTGWhoY0MRg7Mg00jmJqitcxkGeP5kqM2nsbM52qS2D PKHoCFbzGqFr8tl5IkHnBLprjg9Vvp7p5l86tb3ULfm+UqzuJx2ej1xTfynHB71H4OvT KjIg== 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=tCJUyoKHfsjs4CnfaEahfqfOkJhi2S2ZHvguYIkNXzE=; b=VY4KypId3U78u07b/Lh4izBYZtcBICi1NOhp/cAV5OC6CYxKOnGWYWF16eGwHo2Iwc /qig9B7kWvduxCImpvpzq6HunaEV4KKVZtT3VUdrsfrSBdP4EelTPSDMI50EXfu+blDr /NfrnABJkj9O/tUxWtI1rjy0NEGw6ITZ2BRkeQNQu3Rz1lVCBYPTAbEyQT4PuRiD6GZA 3MsnPnPwOuh6eRau57/c+VxcU3ypkxA0qH75lqBWO8C9sggifvuIr/PUuXn6IlgDL956 11FIWCboqokWhgG4fXU9t6eLQhA74X7/wMNs/1N6Tk3xkwr6lpMKkamC2bRZ5DRkkTBa aDYQ== X-Gm-Message-State: AFeK/H07hI2JlwX1mktJO7+3ByX7yOpHDIluoc2Qz9x0S61i+tHc5a6Xak1VQ3afmxlWmxZwqkIbDwigMG/CeQ== X-Received: by 10.55.125.68 with SMTP id y65mr710067qkc.83.1490931711453; Thu, 30 Mar 2017 20:41:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.42.166 with HTTP; Thu, 30 Mar 2017 20:41:30 -0700 (PDT) In-Reply-To: <2f516997-7c5e-2fad-1aeb-51590383f9c7@bbiw.net> References: <2978391.eJVbVTHBlo@kitterma-e6430> <01QCKR5S5OXK0003XB@mauve.mrochek.com> <01QCKXW9MZ4Q0003XB@mauve.mrochek.com> <1cf7325b-6f77-7cda-e330-025b7ddb0b92@dcrocker.net> <2f516997-7c5e-2fad-1aeb-51590383f9c7@bbiw.net> From: Seth Blank Date: Thu, 30 Mar 2017 20:41:30 -0700 Message-ID: To: Dave Crocker Cc: "Murray S. Kucherawy" , "dmarc@ietf.org" , Scott Kitterman , Peter Goldstein , ned+dmarc@mrochek.com Content-Type: multipart/alternative; boundary=94eb2c05ae500c00c5054bfe97af Archived-At: Subject: Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 31 Mar 2017 03:41:56 -0000 --94eb2c05ae500c00c5054bfe97af Content-Type: text/plain; charset=UTF-8 On Thu, Mar 30, 2017 at 7:35 PM, Dave Crocker wrote: > > So to the extent that you are sure things really are that fragile, the > answer is not going to be a test suite or excessively demanding algorithms, > but a re-thinking of the details, to make the implementation and deployment > issues simpler. Exactly; we are in agreement. Where some discussion after the last interop panned out was that deterministic behavior in the new headers would remove this fragility. That's why the conversation was raised to this list instead of happening off to the side. If the consensus here is that the matter is not worth pursuing further, that is fine - I just want to make sure we're all talking about the same thing. Seth On Thu, Mar 30, 2017 at 7:35 PM, Dave Crocker wrote: > On 3/30/2017 7:10 PM, Seth Blank wrote: > >> Dave, If we were only talking about ARC Signing messages, I'd generally >> agree with the comments on this list. >> >> However, ARC is fundamentally different. It is about a chain of messages >> > > > Either you are correct, in which case ARC has been made far too fragile to > be able to work with any serious degree of reliability at scale, > > or you are wrong, in which case the fact of there being a sequence of > DKIM-ish signatures has the same requirements as for individual signatures. > > What you have been getting told by a range of folk with quite a lengthy > history of DKIM and email deployment experience is in line with the latter. > > So to the extent that you are sure things really are that fragile, the > answer is not going to be a test suite or excessively demanding algorithms, > but a re-thinking of the details, to make the implementation and deployment > issues simpler. > > > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols seth@valimail.com +1-415-894-2724 <415-894-2724> --94eb2c05ae500c00c5054bfe97af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 30, 2017 at 7:35 PM, Dave Crocker=C2=A0<dcroc= ker@bbiw.net>=C2=A0wrote:
So to the extent that you are sure things really are that fra= gile, the answer is not going to be a test suite or excessively demanding a= lgorithms, but a re-thinking of the details, to make the implementation and= deployment issues simpler.
=C2=A0
Exactly; we a= re in agreement. Where some discussion after the last interop panned out wa= s that deterministic behavior in the new headers would remove this fragilit= y. That's why the conversation was raised to this list instead of happe= ning off to the side.

If the consensus here is tha= t the matter is not worth pursuing further, that is fine - I just want to m= ake sure we're all talking about the same thing.

Seth


On Thu, Mar 30, 2017 at 7:35 PM, Dave Crocker = <dcrocker@bbiw.ne= t> wrote:
On 3/30/2017 7:10 PM, Seth Blank wrote:
Dave, If we were only talking about ARC Signing messages, I'd generally=
agree with the comments on this list.

However, ARC is fundamentally different. It is about a chain of messages


Either you are correct, in which case ARC has been made far too fragile to = be able to work with any serious degree of reliability at scale,

or you are wrong, in which case the fact of there being a sequence of DKIM-= ish signatures has the same requirements as for individual signatures.

What you have been getting told by a range of folk with quite a lengthy his= tory of DKIM and email deployment experience is in line with the latter.
So to the extent that you are sure things really are that fragile, the answ= er is not going to be a test suite or excessively demanding algorithms, but= a re-thinking of the details, to make the implementation and deployment is= sues simpler.



d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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



--
=
=

3D"logo

Bringing Trust to Email

Seth Blank | Head of = Product for Open Sourc= e and Protocols

seth@valimail.com
+1-415-894-2724<= /a>
--94eb2c05ae500c00c5054bfe97af-- From nobody Fri Mar 31 08:56:08 2017 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 371851294DF for ; Fri, 31 Mar 2017 08:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=dcrocker.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 8nkhOx7Yczck for ; Fri, 31 Mar 2017 08:56:05 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 B0DE81294FC for ; Fri, 31 Mar 2017 08:56:03 -0700 (PDT) Received: from [31.133.143.184] (dhcp-8fb8.meeting.ietf.org [31.133.143.184]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v2VFw8W4016816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 31 Mar 2017 08:58:08 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1490975889; bh=v2TYD2xaG7GAvZSIoMv+8wGSNhPNqBN/vy6enDFxuKs=; h=Subject:To:References:Cc:Reply-To:From:Date:In-Reply-To:From; b=EbpaCc+fpnuSjvU4Uyn/vBEmNafqZ0pv42CrxYagiaRq17wqSglQXXnFKQD4FnvKx 4x51MRUR97GW0AO31urye3wSbyjK65y2kaZSRJNAoYIFhiUOAlh/E/g/7qcBxHrUG8 rIj7PruUtiDvZh6tCTRwNTUNINVI9qEgb7bmzshI= To: Seth Blank References: <2978391.eJVbVTHBlo@kitterma-e6430> <01QCKR5S5OXK0003XB@mauve.mrochek.com> <01QCKXW9MZ4Q0003XB@mauve.mrochek.com> <1cf7325b-6f77-7cda-e330-025b7ddb0b92@dcrocker.net> <2f516997-7c5e-2fad-1aeb-51590383f9c7@bbiw.net> Cc: "Murray S. Kucherawy" , "dmarc@ietf.org" , Scott Kitterman , Peter Goldstein , ned+dmarc@mrochek.com Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <37056495-806d-b2c1-c5be-05dfbb7dda21@dcrocker.net> Date: Fri, 31 Mar 2017 10:55:54 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 31 Mar 2017 15:56:06 -0000 On 3/30/2017 10:41 PM, Seth Blank wrote: > If the consensus here is that the matter is not worth pursuing further, > that is fine - I just want to make sure we're all talking about the same > thing. Except that 'the matter is not worth pursuing' isn't what I heard anyone saying and it definitely wasn't what I meant... I'm not sure whether it's been presented here sufficiently, but I believe your underlying concern is based on observed problems with implementation of the current ARC specification. That is, from interoperability testing, the actual use of ARC is proving far too fragile. If that's true, then there needs to be an effort to a) understand the fragility better, and b) consider ways to make ARC more robust. So while there has been strong push-back against the /solution/ that you proferred, I am not clear whether there is working group understanding of the motivating concern or with the way to resolve it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Mar 31 09:14:23 2017 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 07EDE12968B for ; Fri, 31 Mar 2017 09:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlEI5Qsy_dsX for ; Fri, 31 Mar 2017 09:14:18 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::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 3B11A1296DC for ; Fri, 31 Mar 2017 09:13:47 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id d10so71063874qke.1 for ; Fri, 31 Mar 2017 09:13:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HFqNX17cwc8IEOMM38s5j2rcc41ANuC8ukHsSLBItmc=; b=eBz247FwU4xz157a9BcuVACVHRmrb2dqcZ74kvJ7JnfxKSTwxGGlew/Bj7AUFszzq8 6AjeWqf7y9n1pFfcvWH+Ck3njpNaA+byXg2kMJzIsa+VN3OYZQyf/wXzgsjUeEXUY5yI N6I5DUuJYB8U+IhTDKI6vmS7kfgoiYxsFFReN7JbqzOR5azDpDWaj2vqWNtp/FPWIJNb v4XN+SvwqnEZIBFOl2vMaLZTY4h7OkXXtZEP+3osBinJgCWmXbGVfc9/4qWJh7KsXU69 9fFl6PY07Q668PnXwIDfzKfqJI4x9BB0WRlxjcFeR20zHPFOtnWB6ULupcbGHKXfv/26 eXlg== 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=HFqNX17cwc8IEOMM38s5j2rcc41ANuC8ukHsSLBItmc=; b=fCuMikn+mnjMAr/5JCGJJXYunivDlLJOK0EXSaoRpMUjpXZ8NN9DYbDlPmEVcs9xDu 4kTjY3mXfKHBYjA8vAZtLtB5izzVmOhE4jSUZttnDHtemhDF4YGCgIfc0bXdCRxvO+MU oyEx+fbJeeNsLp6CpwHLNx7b8AvLaDHyyotrUoCYytrv5aZpXnT/bk5eM/rDFtqVtuvc 8JZnY2LrPcs6AedshhVdgqfw41S0M4T0FqJHLNX5ig06RypOSNAqidsqcDI8ORv1era7 9txOQoQDD1LM9Cx8eFSqkF4C8mvx1fKZ5yhVeUq1qwxjjItMnGVm2qkpbG0A/PpbPcVL uUjg== X-Gm-Message-State: AFeK/H1pnWIU/fDcx4dUyHMp8vOS3U28iwviYHNYxC9OK2NxUamaELTStEwkmLnY3bVqccIAColJmKsAhl5htg== X-Received: by 10.55.72.7 with SMTP id v7mr3690166qka.47.1490976826298; Fri, 31 Mar 2017 09:13:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.42.166 with HTTP; Fri, 31 Mar 2017 09:13:25 -0700 (PDT) In-Reply-To: <37056495-806d-b2c1-c5be-05dfbb7dda21@dcrocker.net> References: <2978391.eJVbVTHBlo@kitterma-e6430> <01QCKR5S5OXK0003XB@mauve.mrochek.com> <01QCKXW9MZ4Q0003XB@mauve.mrochek.com> <1cf7325b-6f77-7cda-e330-025b7ddb0b92@dcrocker.net> <2f516997-7c5e-2fad-1aeb-51590383f9c7@bbiw.net> <37056495-806d-b2c1-c5be-05dfbb7dda21@dcrocker.net> From: Seth Blank Date: Fri, 31 Mar 2017 09:13:25 -0700 Message-ID: To: Dave Crocker Cc: Scott Kitterman , "dmarc@ietf.org" , "Murray S. Kucherawy" , ned+dmarc@mrochek.com, Peter Goldstein Content-Type: multipart/alternative; boundary=001a114a8e6819fde5054c0918f8 Archived-At: Subject: Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 31 Mar 2017 16:14:22 -0000 --001a114a8e6819fde5054c0918f8 Content-Type: text/plain; charset=UTF-8 Thank you, Dave. What's the best way to proceed from here for the working group? On Fri, Mar 31, 2017 at 8:55 AM, Dave Crocker wrote: > On 3/30/2017 10:41 PM, Seth Blank wrote: > >> If the consensus here is that the matter is not worth pursuing further, >> that is fine - I just want to make sure we're all talking about the same >> thing. >> > > > > Except that 'the matter is not worth pursuing' isn't what I heard anyone > saying and it definitely wasn't what I meant... > > I'm not sure whether it's been presented here sufficiently, but I believe > your underlying concern is based on observed problems with implementation > of the current ARC specification. That is, from interoperability testing, > the actual use of ARC is proving far too fragile. > > If that's true, then there needs to be an effort to a) understand the > fragility better, and b) consider ways to make ARC more robust. > > So while there has been strong push-back against the /solution/ that you > proferred, I am not clear whether there is working group understanding of > the motivating concern or with the way to resolve it. > > > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols seth@valimail.com +1-415-894-2724 <415-894-2724> --001a114a8e6819fde5054c0918f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you, Dave.

What's the best wa= y to proceed from here for the working group?

On Fri, Mar 31, 2017 at 8:55 AM, Da= ve Crocker <dhc@dcrocker.net> wrote:
On 3/30/2017 10:41 PM, Seth Blank wrote:
If the consensus here is that the matter is not worth pursuing further,
that is fine - I just want to make sure we're all talking about the sam= e
thing.



 Except that 'the matter is not worth pursuing' isn't what I hea= rd anyone saying and it definitely wasn't what I meant...

I'm not sure whether it's been presented here sufficiently, but I b= elieve your underlying concern is based on observed problems with implement= ation of the current ARC specification.=C2=A0 That is, from interoperabilit= y testing, the actual use of ARC is proving far too fragile.

If that's true, then there needs to be an effort to a) understand the f= ragility better, and b) consider ways to make ARC more robust.

So while there has been strong push-back against the /solution/ that you pr= oferred, I am not clear whether there is working group understanding of the= motivating concern or with the way to resolve it.



d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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



--
=

3D"logo

Bringing Trust to Email

Seth Blank | Head of Product for Open Source and Protocols

seth@valim= ail.com
+1-415-894-2724
=
--001a114a8e6819fde5054c0918f8-- From nobody Fri Mar 31 10:08:48 2017 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 D94F8128B88 for ; Fri, 31 Mar 2017 10:08:46 -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 Ea7XoE0R1MTr for ; Fri, 31 Mar 2017 10:08:43 -0700 (PDT) Received: from lepidum.jp (lepidum.jp [60.32.83.213]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12AFA1294C7 for ; Fri, 31 Mar 2017 10:08:42 -0700 (PDT) Received: from dhcp-8cc3.meeting.ietf.org (dhcp-8cc3.meeting.ietf.org [31.133.140.195]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: okd@lepidum.co.jp) by mail06.server.lepidum.net (Postfix) with ESMTPSA id F0AA12F8000C5; Sat, 1 Apr 2017 02:08:36 +0900 (JST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Kouji Okada In-Reply-To: <076e78c0-f52f-d0d4-934d-e4477e27f388@americangreetings.com> Date: Sat, 1 Apr 2017 02:08:33 +0900 Cc: Kouji Okada , dmarc@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <8559BB82-3951-4B14-A3D9-011936AEAD9E@lepidum.co.jp> <2153663.3j7HfnN8Lr@kitterma-e6430> <076e78c0-f52f-d0d4-934d-e4477e27f388@americangreetings.com> To: mhammer@americangreetings.com X-Mailer: Apple Mail (2.3273) X-Clamav-Info: Checked(Clean) X-LepidumMailFilterAgent-by: mailfromd (5.1) X-LepidumMailFilterAgent-Info: Original (mailfrom:Inbound) Archived-At: Subject: Re: [dmarc-ietf] updating draft-akagiri-dmarc-virtual-verification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 31 Mar 2017 17:08:47 -0000 Mark Thank you for your comment. The authors are now discussing which authentication-method or authentication-code is suitable to be marked in the authentication-results. > Trying to guess where to send (unasked for) reports is guaranteed to = end with poor outcomes. I totally agree. Best regards, Kouji Okada > 2017/03/28 22:26=E3=80=81mhammer@americangreetings.com=E3=81=AE=E3=83=A1= =E3=83=BC=E3=83=AB: >=20 > On 3/25/2017 12:45 AM, Scott Kitterman wrote: >> For SPF, we had "best guess" [1], which we chose not to standardize = at all >> because we didn't think it appropriate to break the opt-in nature of = SPF. >> This concerns me a bit here, but I'm mostly writing to support the = idea of >> distinguishing between some kind of guess and an actual DMARC result. >>=20 >> I think "dmarc=3Dbestguesspass" is far superior to "dmarc=3Dpass", = since this is >> not a DMARC pass. I think "dmarcguess=3Dpass" would be better since = this isn't >> properly a DMARC check at all. >>=20 >> Scott k >=20 > I absolutely agree with Scott on this. "bestguesspass" is NOT DMARC. = It is local policy applied in a DMARC like manner. >=20 > This is also why there is no legitimate place to send reports. The = sender did not publish a DMARC record and did not ask for reports. = Trying to guess where to send (unasked for) reports is guaranteed to end = with poor outcomes. >=20 > Mike >=20 >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Fri Mar 31 10:30:33 2017 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 9AA77129644 for ; Fri, 31 Mar 2017 10:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.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 VyH7_dbCGbEM for ; Fri, 31 Mar 2017 10:30:31 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 8F1701294BF for ; Fri, 31 Mar 2017 10:30:30 -0700 (PDT) Received: from [192.168.1.158] (50-232-11-130-static.hfc.comcastbusiness.net [50.232.11.130]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v2VHWZo5023287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 31 Mar 2017 10:32:35 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1490981556; bh=wNBbgJR5Yt1mpWhxhV5FfbwqZG96K7nmEsnTwfDYYAk=; h=Subject:To:References:Cc:Reply-To:From:Date:In-Reply-To:From; b=BjcITLQGE5rFFqPRH8RI7Ddm8MUWVnXkYcq0HE0nflQSgy26vR1RWlSFbamxe/PYa j+sJiIi8m95IuTOmv4J10P7ytxnVkH0AG+Apqm68MfwtHPAxR7UWYVLT8q1Lu+sD+w 2oYD+ScZTWSAOzObvA9C2bBNIJHJvzA1E5iP1tmU= To: Takehito Akagiri , Kouji Okada References: <1091919919.43972.1458233931938.JavaMail.zimbra@peachymango.org> <233B51DD-C6BB-464F-8206-D3D0CDD032DE@lepidum.co.jp> Cc: dmarc Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <8a05b71f-8f38-cd2e-4a3c-e49acd62dbe1@dcrocker.net> Date: Fri, 31 Mar 2017 12:30:26 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 31 Mar 2017 17:30:33 -0000 On 10/3/2016 9:21 AM, Takehito Akagiri wrote: > We have updated the draft based on comments on ML when we submitted > draft 00. I'll show small comments about that. I'm confused. First, this is not a task within the working group charter, as I read it, and I haven't seen a wg discussion to adopt it. Second, I've seen a range of specific arguments against this work, with only a tiny amount of support for it, and no follow-up discussion of those arguments, nevermind accomplishing reasonable resolution of those concerns. All of which tells me that this activity is out of scope for this IETF mailing list. I encourage the chairs to chime in and either confirm or correct this assessment. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Mar 31 13:15:46 2017 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 700D81299D4 for ; Fri, 31 Mar 2017 13:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 AmtFReaSkzMM for ; Fri, 31 Mar 2017 13:15:38 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::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 05A331267BB for ; Fri, 31 Mar 2017 13:15:37 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id r69so102634704vke.2 for ; Fri, 31 Mar 2017 13:15:36 -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=1zAF+j13ONpVDhgAbSkQ3g//0njBmubW+SE0Z074VgI=; b=HLj+xyMQEdc7bekGtn5tqVykxo/0jAzyTUfWcoVQ6kmXtb2utNh4p7785dZrO/N3tE 1Jbm0bgiBlB39jUhoninxIOXPaFdE6AqcGXlMnMXAjgu/iCnslGSxQx3yFu5xNZiCXNu 5Srn743pQKqV0MS28lRs0vINR4QbIw8Gjxwir4Eu+wDqoyWxt2lEauGbbT39e0L4BHEJ SGn4dfrbaGryrz/9DPzc4HNUtamlaDaKUBWhzP+yUyrEbyfJcQsgVwoIU7bxm536PTw4 inbIiIIop8soddCCF2Pxzs97XKWPEwOS9a/WZQjKyko6N5Rpf88OVy36aUb5p0db/aMM LC8g== 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=1zAF+j13ONpVDhgAbSkQ3g//0njBmubW+SE0Z074VgI=; b=UWDK8pKd3DL+kiDg8Txdm8z/zMDgTCr6JRFkms00u2VwiVPJRCIBpPK3B/M3gISHLm d+BsZMEPlzhNoAby7SRMm3woNaiGBxsIL9EIf8Ch2lp6TlJYlGBORb2Vtkw4KU4ixWAI Rlx4kXlvL5XeG5PFS48KjEUEA7bVh/0fw29/VVBVn3Li6Im5cvP7p965/MsmuXoDmHtr M5ofXo2S6yaO9UV04V4zUFx2qv3c9N9XjFqRIrN0UXNBM2TZgRUOWKbclE9pyebJe+Vu EgoDfh6KtoH3YFijlmfzF6IRexzPN87U3zlmNqdJXCE2GBTsrvFxBUl5ExasMac+D667 ObrQ== X-Gm-Message-State: AFeK/H0g0EIInTaAxW6YPFDHHkhSD23TzGe1byaKRx7AWDsg7DXucpKOGOrlf9dgGLGz53BNckhULnZ/qhoFoA== X-Received: by 10.31.61.194 with SMTP id k185mr2346851vka.141.1490991336050; Fri, 31 Mar 2017 13:15:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.130.70 with HTTP; Fri, 31 Mar 2017 13:15:35 -0700 (PDT) In-Reply-To: References: <2978391.eJVbVTHBlo@kitterma-e6430> <01QCKR5S5OXK0003XB@mauve.mrochek.com> <01QCKXW9MZ4Q0003XB@mauve.mrochek.com> <1cf7325b-6f77-7cda-e330-025b7ddb0b92@dcrocker.net> <2f516997-7c5e-2fad-1aeb-51590383f9c7@bbiw.net> <37056495-806d-b2c1-c5be-05dfbb7dda21@dcrocker.net> From: "Murray S. Kucherawy" Date: Fri, 31 Mar 2017 15:15:35 -0500 Message-ID: To: Seth Blank Cc: Dave Crocker , Scott Kitterman , "dmarc@ietf.org" , Ned Freed , Peter Goldstein Content-Type: multipart/alternative; boundary=001a114dbd70f2d4ec054c0c7807 Archived-At: Subject: Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 31 Mar 2017 20:15:40 -0000 --001a114dbd70f2d4ec054c0c7807 Content-Type: text/plain; charset=UTF-8 Hi Seth, Can you describe in detail the fragility you've observed? I saw Peter (sorry for "Paul", it was 4am) upthread somewhere say that a few different projects had various problems found, but I don't recall him saying exactly what they were. -MSK On Fri, Mar 31, 2017 at 11:13 AM, Seth Blank wrote: > Thank you, Dave. > > What's the best way to proceed from here for the working group? > > On Fri, Mar 31, 2017 at 8:55 AM, Dave Crocker wrote: > >> On 3/30/2017 10:41 PM, Seth Blank wrote: >> >>> If the consensus here is that the matter is not worth pursuing further, >>> that is fine - I just want to make sure we're all talking about the same >>> thing. >>> >> >> >> >> Except that 'the matter is not worth pursuing' isn't what I heard anyone >> saying and it definitely wasn't what I meant... >> >> I'm not sure whether it's been presented here sufficiently, but I believe >> your underlying concern is based on observed problems with implementation >> of the current ARC specification. That is, from interoperability testing, >> the actual use of ARC is proving far too fragile. >> >> If that's true, then there needs to be an effort to a) understand the >> fragility better, and b) consider ways to make ARC more robust. >> >> So while there has been strong push-back against the /solution/ that you >> proferred, I am not clear whether there is working group understanding of >> the motivating concern or with the way to resolve it. >> >> >> >> d/ >> >> -- >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > > > > -- > > [image: logo for sig file.png] > > Bringing Trust to Email > > Seth Blank | Head of Product for Open Source and Protocols > seth@valimail.com > +1-415-894-2724 <415-894-2724> > --001a114dbd70f2d4ec054c0c7807 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Seth,

Can you describe in detail the fragil= ity you've observed?=C2=A0 I saw Peter (sorry for "Paul", it = was 4am) upthread somewhere say that a few different projects had various p= roblems found, but I don't recall him saying exactly what they were.
-MSK

On Fri, Mar 31, 2017 at 11:13 AM, Seth Blank <= seth@valimail.com> wrote:
Than= k you, Dave.

What's the best way to proceed from her= e for the working group?

On 3/30/2017 10:41 PM,= Seth Blank wrote:
If the consensus here is that the matter is not worth pursuing further,
that is fine - I just want to make sure we're all talking about the sam= e
thing.



 Except that 'the matter is not worth pursuing' isn't what I hea= rd anyone saying and it definitely wasn't what I meant...

I'm not sure whether it's been presented here sufficiently, but I b= elieve your underlying concern is based on observed problems with implement= ation of the current ARC specification.=C2=A0 That is, from interoperabilit= y testing, the actual use of ARC is proving far too fragile.

If that's true, then there needs to be an effort to a) understand the f= ragility better, and b) consider ways to make ARC more robust.

So while there has been strong push-back against the /solution/ that you pr= oferred, I am not clear whether there is working group understanding of the= motivating concern or with the way to resolve it.
<= div class=3D"h5">


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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



--
=

3D"=

Bringing Trust to Email

Seth Blank | Head = of Product for Open S= ource and Protocols

seth@valimail.com=
+1-415-894-2= 724

--001a114dbd70f2d4ec054c0c7807-- From nobody Fri Mar 31 13:16:59 2017 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 4989F12951D for ; Fri, 31 Mar 2017 13:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 iWa66AAjQJ05 for ; Fri, 31 Mar 2017 13:16:55 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::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 1EFAD1294FE for ; Fri, 31 Mar 2017 13:16:55 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id d188so102093489vka.0 for ; Fri, 31 Mar 2017 13:16:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=n8Fnqxx+HNn1/mJ1w+HQpBiL/O2M/Z3HqVB9I3M9/vs=; b=NO85RLPVBOwbHiG170h33hVpss8AcnX2ufOCuEG8yIMwh5ch+0kmPTdw3s3P0a5iSn QZDu/Y6UR9ljXbh1vxJPgoHXdxV9rqoIHTtNKxC0SHQe3gPeb6e8lwJ5OwvcgGNCr7C9 tdjZjjK6JK/HCFB0N7kIZzswAi/jiKPB2r8wqKNO0eXkSR6+d1iE3ANR0/YukLRRSHcu erzrSyJZ19Ptb4wcmWI889LYKhhp34fcoQcdx4m0sPmaH+VRQVfS3DrxlerfHWsgi65z MF40PCABCfnp/bgsyS4Gqnj0KQtK1YVA6Bc8ut7AXkPPQAHr3nBsZNdY+uTcOyl8aC55 okwQ== 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=n8Fnqxx+HNn1/mJ1w+HQpBiL/O2M/Z3HqVB9I3M9/vs=; b=r0VIGEi5jnUKBXadjVN3OLEKb0sZ2XJzUy6BVHJXZ7yojwMQjlyYRHUMSFFVbEvmf/ A/aNqRs23Yd+2xVBdaHUnM1ckVILh3DLPHKkWqq5arB+9tUbBvkLtWXUw5iJQ8VaBs8u vEogtaHkBbZpCJjRyil+HS+WI6jYOEYpDpkIDdQBhNXCsw5pVv5E3hmtvR6LedhNmiJt KMgR8zhIL5docsAJbE1Vp3iZ/F2e7RB/Cfi6qmdq+nJeQ/AgkH2lLrb4PKebJ1jxkU3J aZ1zjJxcl+rJHrViQpqgLl01Pt5nBNaDHYZx0NL+r7b6iybgZ2inx0T7N07ytZXgTPRp G6mA== X-Gm-Message-State: AFeK/H0PhVuBgeidnDctY3k5l/8FJJsCxJioUC1vjBHD0dTPbtbQ7ugki1lEsQqAv9XFqryLBhA1nanCRgFI7w== X-Received: by 10.31.76.129 with SMTP id z123mr2416186vka.117.1490991414198; Fri, 31 Mar 2017 13:16:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.130.70 with HTTP; Fri, 31 Mar 2017 13:16:53 -0700 (PDT) In-Reply-To: References: <8559BB82-3951-4B14-A3D9-011936AEAD9E@lepidum.co.jp> <2153663.3j7HfnN8Lr@kitterma-e6430> <076e78c0-f52f-d0d4-934d-e4477e27f388@americangreetings.com> From: "Murray S. Kucherawy" Date: Fri, 31 Mar 2017 15:16:53 -0500 Message-ID: To: Kouji Okada Cc: mhammer@americangreetings.com, "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a114dd13e9b4d4b054c0c7d3f Archived-At: Subject: Re: [dmarc-ietf] updating draft-akagiri-dmarc-virtual-verification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 31 Mar 2017 20:16:57 -0000 --001a114dd13e9b4d4b054c0c7d3f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Please be sure to read RFC7601 while deciding, as it sets out the rules for the registries related to Authentication-Results and what's appropriate to put in them. On Fri, Mar 31, 2017 at 12:08 PM, Kouji Okada wrote: > Mark > > Thank you for your comment. > > The authors are now discussing which > authentication-method or authentication-code is suitable > to be marked in the authentication-results. > > > Trying to guess where to send (unasked for) reports is guaranteed to en= d > with poor outcomes. > > I totally agree. > > Best regards, > Kouji Okada > > > 2017/03/28 22:26=E3=80=81mhammer@americangreetings.com=E3=81=AE=E3=83= =A1=E3=83=BC=E3=83=AB: > > > > On 3/25/2017 12:45 AM, Scott Kitterman wrote: > >> For SPF, we had "best guess" [1], which we chose not to standardize at > all > >> because we didn't think it appropriate to break the opt-in nature of > SPF. > >> This concerns me a bit here, but I'm mostly writing to support the ide= a > of > >> distinguishing between some kind of guess and an actual DMARC result. > >> > >> I think "dmarc=3Dbestguesspass" is far superior to "dmarc=3Dpass", sin= ce > this is > >> not a DMARC pass. I think "dmarcguess=3Dpass" would be better since t= his > isn't > >> properly a DMARC check at all. > >> > >> Scott k > > > > I absolutely agree with Scott on this. "bestguesspass" is NOT DMARC. It > is local policy applied in a DMARC like manner. > > > > This is also why there is no legitimate place to send reports. The > sender did not publish a DMARC record and did not ask for reports. Trying > to guess where to send (unasked for) reports is guaranteed to end with po= or > outcomes. > > > > Mike > > > > > > _______________________________________________ > > 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 > --001a114dd13e9b4d4b054c0c7d3f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Please be sure to read RFC7601 while deciding, as it sets = out the rules for the registries related to Authentication-Results and what= 's appropriate to put in them.

=
On Fri, Mar 31, 2017 at 12:08 PM, Kouji Okada <= okd@lepidum.co.jp> wrote:
M= ark

Thank you for your comment.

The authors are now discussing which
authentication-method or authentication-code is suitable
to be marked in the authentication-results.

> Trying to guess where to send (unasked for) reports is guaranteed to e= nd with poor outcomes.

I totally agree.

Best regards,
Kouji Okada

> 2017/03/28 22:26=E3=80=81mhammer@americangreetings.com=E3=81=AE=E3=83=A1=E3=83=BC=E3=83= =AB:
>
> On 3/25/2017 12:45 AM, Scott Kitterman wrote:
>> For SPF, we had "best guess" [1], which we chose not to = standardize at all
>> because we didn't think it appropriate to break the opt-in nat= ure of SPF.
>> This concerns me a bit here, but I'm mostly writing to support= the idea of
>> distinguishing between some kind of guess and an actual DMARC resu= lt.
>>
>> I think "dmarc=3Dbestguesspass" is far superior to "= ;dmarc=3Dpass", since this is
>> not a DMARC pass.=C2=A0 I think "dmarcguess=3Dpass" woul= d be better since this isn't
>> properly a DMARC check at all.
>>
>> Scott k
>
> I absolutely agree with Scott on this. "bestguesspass" is NO= T DMARC. It is local policy applied in a DMARC like manner.
>
> This is also why there is no legitimate place to send reports. The sen= der did not publish a DMARC record and did not ask for reports. Trying to g= uess where to send (unasked for) reports is guaranteed to end with poor out= comes.
>
> Mike
>
>
> _______________________________________________
> 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

--001a114dd13e9b4d4b054c0c7d3f-- From nobody Fri Mar 31 14:29:58 2017 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 0E956129537 for ; Fri, 31 Mar 2017 14:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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=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 UW9OLNGy35mm for ; Fri, 31 Mar 2017 14:29:54 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B95741270FC for ; Fri, 31 Mar 2017 14:29:53 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id o67so74966556oib.1 for ; Fri, 31 Mar 2017 14:29:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=O3fgcs/R5bDHzicWnnW3ttN4E7+GP9AFYo/8ic5JfM8=; b=Myhd0cWXrsdeJG1YQAzwbC/lP9pu5uKsMxvQIADJAqxIR2g7JOsrE8rbx0nDINwwSq VFfhI1gPEEkKYCeC5bvgW1x9fBde8EApCtzwTXaDR36lwNFNfFzKFAEh5SSsYHmuP2Qc UbUPMa52HEIM7cgZQ/ek0t5qyOia6KMZo9VNJcfd7bZ62TbWVjNOLDsBkdWWsZhwqgkB PRIiEVxhIefAiIPsCW+DSJNZWdolLtXBWhZzadW5Br8sBdKdgovJpYzON+kn16XEtAgL Ix7N3xJiPjS1RQb2f2krBI+gqIL2MpjOrswPerFqiefDGVZx7ouArSEkOS8AtdPWIm+Y 3Qdw== 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=O3fgcs/R5bDHzicWnnW3ttN4E7+GP9AFYo/8ic5JfM8=; b=EJv4h7B/TJ5MtH14V0sJauVzNIT2jSh+tsVUpjBEX71wieX12Jmp+JV2yp9S4B9U5L jZXfUwbaBq3/Lcvds7G8OEXEgjVm1T/c0ecGKVnkCrvcMfhocOYOILlKGxUrEtD0iJvw yuaiFe6NAjt5c/aYgY8N/R9ost2Qixf0fZSZw9MnM+lm2d0bNpdsCCkSxosAwLzL/xnI nXofxXKM8iL9bRAIu4MKGB2jgViJUADxDjij/Aq3seNhG57UbM5jsSbj9zyolVSJOUC+ yUEUhaLk9Mt2aKmXevtAy1XNLQ91fq60crMFJcoVtrdujDOgkfDP0ciMGAHrjMVQg8k5 RccA== X-Gm-Message-State: AFeK/H2RGWcPlduM3NuYGrO19f9WTiWrrFFRRBBFxcLCNQlwm/th7paMM5sKl09E+HGPyUTOTgAkl2Gd7o44ZvkL X-Received: by 10.202.216.84 with SMTP id p81mr425079oig.193.1490995792645; Fri, 31 Mar 2017 14:29:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.120.72 with HTTP; Fri, 31 Mar 2017 14:29:51 -0700 (PDT) In-Reply-To: References: <8559BB82-3951-4B14-A3D9-011936AEAD9E@lepidum.co.jp> <2153663.3j7HfnN8Lr@kitterma-e6430> <076e78c0-f52f-d0d4-934d-e4477e27f388@americangreetings.com> From: Brandon Long Date: Fri, 31 Mar 2017 14:29:51 -0700 Message-ID: To: "Murray S. Kucherawy" Cc: Kouji Okada , "dmarc@ietf.org" , mhammer@americangreetings.com Content-Type: multipart/alternative; boundary=001a113d283095805b054c0d8255 Archived-At: Subject: Re: [dmarc-ietf] updating draft-akagiri-dmarc-virtual-verification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 31 Mar 2017 21:29:57 -0000 --001a113d283095805b054c0d8255 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It's unclear to me why this needs to be an RFC. Is the point to register specific Authentication-Results header values in IANA? Otherwise, this seems like nothing more than some local special anti-spam sauce. Like Scott says, this sounds like SPF bestguess, perhaps he can point out any discussion that was had about bestguess and why it was left out of the SPF RFC. Brandon On Fri, Mar 31, 2017 at 1:16 PM, Murray S. Kucherawy wrote: > Please be sure to read RFC7601 while deciding, as it sets out the rules > for the registries related to Authentication-Results and what's appropria= te > to put in them. > > On Fri, Mar 31, 2017 at 12:08 PM, Kouji Okada wrote: > >> Mark >> >> Thank you for your comment. >> >> The authors are now discussing which >> authentication-method or authentication-code is suitable >> to be marked in the authentication-results. >> >> > Trying to guess where to send (unasked for) reports is guaranteed to >> end with poor outcomes. >> >> I totally agree. >> >> Best regards, >> Kouji Okada >> >> > 2017/03/28 22:26=E3=80=81mhammer@americangreetings.com=E3=81=AE=E3=83= =A1=E3=83=BC=E3=83=AB: >> > >> > On 3/25/2017 12:45 AM, Scott Kitterman wrote: >> >> For SPF, we had "best guess" [1], which we chose not to standardize a= t >> all >> >> because we didn't think it appropriate to break the opt-in nature of >> SPF. >> >> This concerns me a bit here, but I'm mostly writing to support the >> idea of >> >> distinguishing between some kind of guess and an actual DMARC result. >> >> >> >> I think "dmarc=3Dbestguesspass" is far superior to "dmarc=3Dpass", si= nce >> this is >> >> not a DMARC pass. I think "dmarcguess=3Dpass" would be better since >> this isn't >> >> properly a DMARC check at all. >> >> >> >> Scott k >> > >> > I absolutely agree with Scott on this. "bestguesspass" is NOT DMARC. I= t >> is local policy applied in a DMARC like manner. >> > >> > This is also why there is no legitimate place to send reports. The >> sender did not publish a DMARC record and did not ask for reports. Tryin= g >> to guess where to send (unasked for) reports is guaranteed to end with p= oor >> outcomes. >> > >> > Mike >> > >> > >> > _______________________________________________ >> > 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 >> > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --001a113d283095805b054c0d8255 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It's unclear to me why this needs to be an RFC.=C2=A0 = Is the point to register specific Authentication-Results header values in I= ANA?

Otherwise, this seems like nothing more than some l= ocal special anti-spam sauce.=C2=A0 Like Scott says, this sounds like SPF b= estguess, perhaps he can point out any discussion that was had about bestgu= ess and why it was left out of the SPF RFC.

Brando= n

On F= ri, Mar 31, 2017 at 1:16 PM, Murray S. Kucherawy <superuser@gmail.com> wrote:
Plea= se be sure to read RFC7601 while deciding, as it sets out the rules for the= registries related to Authentication-Results and what's appropriate to= put in them.

On Fri, Mar 31, 2017 at 12:= 08 PM, Kouji Okada <okd@lepidum.co.jp> wrote:
Mark

Thank you for your comment.

The authors are now discussing which
authentication-method or authentication-code is suitable
to be marked in the authentication-results.

> Trying to guess where to send (unasked for) reports is guaranteed to e= nd with poor outcomes.

I totally agree.

Best regards,
Kouji Okada

> 2017/03/28 22:26=E3=80=81mhammer@americangreetings.com=E3=81=AE=E3=83= =A1=E3=83=BC=E3=83=AB:
>
> On 3/25/2017 12:45 AM, Scott Kitterman wrote:
>> For SPF, we had "best guess" [1], which we chose not to = standardize at all
>> because we didn't think it appropriate to break the opt-in nat= ure of SPF.
>> This concerns me a bit here, but I'm mostly writing to support= the idea of
>> distinguishing between some kind of guess and an actual DMARC resu= lt.
>>
>> I think "dmarc=3Dbestguesspass" is far superior to "= ;dmarc=3Dpass", since this is
>> not a DMARC pass.=C2=A0 I think "dmarcguess=3Dpass" woul= d be better since this isn't
>> properly a DMARC check at all.
>>
>> Scott k
>
> I absolutely agree with Scott on this. "bestguesspass" is NO= T DMARC. It is local policy applied in a DMARC like manner.
>
> This is also why there is no legitimate place to send reports. The sen= der did not publish a DMARC record and did not ask for reports. Trying to g= uess where to send (unasked for) reports is guaranteed to end with poor out= comes.
>
> Mike
>
>
> _______________________________________________
> 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


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


--001a113d283095805b054c0d8255--