From nobody Sat Apr 1 13:25: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 AE6271294C1 for ; Sat, 1 Apr 2017 13:25:32 -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 IDMlAWTDesCd for ; Sat, 1 Apr 2017 13: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 C8C491293FB for ; Sat, 1 Apr 2017 13:25:30 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QCNWS622HS00X91L@mauve.mrochek.com> for dmarc@ietf.org; Sat, 1 Apr 2017 13:20:21 -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; Sat, 01 Apr 2017 13:20:14 -0700 (PDT) From: ned+dmarc@mrochek.com Cc: Dave Crocker , "Murray S. Kucherawy" , "dmarc@ietf.org" , Scott Kitterman , Peter Goldstein , ned+dmarc@mrochek.com Message-id: <01QCNWS0LANY0003XB@mauve.mrochek.com> Date: Sat, 01 Apr 2017 13:13:44 -0700 (PDT) In-reply-to: "Your message dated Fri, 31 Mar 2017 09:13:25 -0700" 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> To: Seth Blank 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: Sat, 01 Apr 2017 20:25:33 -0000 > What's the best way to proceed from here for the working group? That's easy: The way to proceed is by describing the actual interoperability problem that came up. In detail. What you have done so far, AFAICT, is propose a change that at most facilities a type of testing decades of experience have shown to have limited value. This is a far cry from describing an actual interoperability problem. This is, or at least is supposed to be, a technical list. Noone here is going to be put off by complicated technical details. In fact the absence of such discussion was and is a major problem with the advancement of this specification, and unless that changes fairly soon I'm going to put on my working group chair hat and say some stuff that people are really not going to like. Ned > 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> From nobody Sat Apr 1 13:41: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 BC07A12968E for ; Sat, 1 Apr 2017 13:41:35 -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 gZrA0vCOrWXw for ; Sat, 1 Apr 2017 13:41:34 -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 661E012968B for ; Sat, 1 Apr 2017 13:41:34 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QCNXC4AXC000WF1B@mauve.mrochek.com> for dmarc@ietf.org; Sat, 1 Apr 2017 13:36:25 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed 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; Sat, 01 Apr 2017 13:36:18 -0700 (PDT) From: ned+dmarc@mrochek.com Cc: Takehito Akagiri , Kouji Okada , dmarc Message-id: <01QCNXBZDS520003XB@mauve.mrochek.com> Date: Sat, 01 Apr 2017 13:25:48 -0700 (PDT) In-reply-to: "Your message dated Fri, 31 Mar 2017 12:30:26 -0500" <8a05b71f-8f38-cd2e-4a3c-e49acd62dbe1@dcrocker.net> References: <1091919919.43972.1458233931938.JavaMail.zimbra@peachymango.org> <233B51DD-C6BB-464F-8206-D3D0CDD032DE@lepidum.co.jp> <8a05b71f-8f38-cd2e-4a3c-e49acd62dbe1@dcrocker.net> To: Dave Crocker 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: Sat, 01 Apr 2017 20:41:36 -0000 Normally I'm not a stickler for avoiding side discussion of related items on working lists. But this case I'm going to have to agree with Dave: This group is not making sufficient progress on its core work, which currently is to review and progress the ARC specifications. This needs to happen sooner rather than later, and we cannot afford to spend time on this specification at this time. If and when we get that far, we can discuss whether or not this is a fit for the third track of this WG (documentation of actual and possible operational practices). Ned > 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 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Mon Apr 3 16:49: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 E1CB91289C3 for ; Mon, 3 Apr 2017 16:49:42 -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 Hf27PrUHUt0t for ; Mon, 3 Apr 2017 16:49:41 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1801127077 for ; Mon, 3 Apr 2017 16:49:40 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id r69so157691319vke.2 for ; Mon, 03 Apr 2017 16:49:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Q0ivXTeGCL5BTBHTFDuSAYnr72aLOEypIKTV6V+Dxhc=; b=txwONpkrLMy45x615RQbbzy0xYyXoWZOjNUaloQHWGcputl39PwZ53Bml/Xb0EX+7E Xf7S8XhfVx4qrLntas5GKeBOpGa7ngmEvlMOo/TfgkYnXxWSgxxYZeUelPkub8kIUj8X Nvseh0XYSk/35hEsqlKrEhN3r4Geh0uf0/OSKdW0cxLvnMEPjAbSb9A8WLK/Htvj5cgM hLH09vaTbHEUXDOCbflaZxL+6HqJmpGTuiFoKeZe/TUVICtn6ODnEw+wY3/ov9h5rqzm FWmqmDTH04PvBPVfa6a5N07MEKinM+PrFMBC6DzGaWIvekV9BQIiWL36/e17e6kxY8d1 8zwQ== 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=Q0ivXTeGCL5BTBHTFDuSAYnr72aLOEypIKTV6V+Dxhc=; b=pXRVbp5piGuHRlAPsZSnSuyN16bbfbCxyKs2NTMhS+sbRyyqJmkjZ3B/5Tj4loWsCz vO+Klu895FvONt+Bvf9gdIxtE92NfeNfto6NQWHtDp2VvntkyawFQWhNSvAm/2U48bEY LmBS7XfpB/V6yqroAxdcWroTCYgTBPx9DcsAoaLv15vazA9B1jHhC1q5sJjQbRe+SDWS Q+bGhZ8n+rZ2Wy3SEJSuNMtLhiHqiTCSHJ6h7YT90Uw/g3A2aRBVq1NNrCfNs3vGwhqa P+xzbAr7+dum+UOgt6qy+MjgZSJyd1XG6VgLNv+5dr/BWD94+yVPeBTwjxk1JEgyvC7X hzsg== X-Gm-Message-State: AFeK/H0Rnhtueo7iE+cuBYIPfnadJ1tJV1WJxEPFkVIoeHKryHOUNRoX4wW0kTSnyrkrJG9tdV3ThU07PeQDwg== X-Received: by 10.176.92.13 with SMTP id q13mr10455987uaf.149.1491263379683; Mon, 03 Apr 2017 16:49:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.130.70 with HTTP; Mon, 3 Apr 2017 16:49:39 -0700 (PDT) From: "Murray S. Kucherawy" Date: Mon, 3 Apr 2017 16:49:39 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=f403043614160340ad054c4bd09a Archived-At: Subject: [dmarc-ietf] ARC-Authentication-Results 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, 03 Apr 2017 23:49:43 -0000 --f403043614160340ad054c4bd09a Content-Type: text/plain; charset=UTF-8 The latest ARC base document says this about the ARC-Authentication-Results field: ARC-Authentication-Results is a direct copy of the Authentication- Results header field [RFC7601 ] created for archival purposes by the each MTA outside of the trust boundary of the originating system which is contributing to the chain of ARC header fields. The corresponding instance ("i=") tag value MUST be prefixed to the Authentication-Results. Apart from the grammatical glitch ("the each"), this appears to me to be saying: "Collect the contents of the A-R fields that already exist and re-record those results into a new A-A-R field." Should that include the results computed by the ADMD that's doing this work? Either way, is this even possible? Since A-A-R is (apart from the "i=" tag) syntactically identical to an A-R (RFC7601) header field, and an A-R field has a single authserv-id, and the authserv-id is presumably integral to the final recipient deciding whether to trust the message, what does an implementer do with this?: A-R: admd1; dkim=pass header.d=example.com A-R: admd2; dkim=fail header.d=example.com What A-A-R am I supposed to generate from that? Does order matter? It seems to me that, at a minimum, the name(s) of the ADMD(s) will be lost; assuming that's okay, here's what I get: A-A-R: i=N; my-authserv-id; dkim=pass header.d=example.com; dkim=fail header.d=example.com As a final recipient, I'd have no idea what to do with that. Confused, -MSK --f403043614160340ad054c4bd09a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The latest ARC base document says this about the ARC-= Authentication-Results field:

   ARC-Au=
thentication-Results is a direct copy of the Authentication-
   Results header field [RFC7601] created for archival purposes by the
   each MTA outside of the trust boundary of the originating system
   which is contributing to the chain of ARC header fields.  The
   corresponding instance ("i=3D") tag value MUST be prefixed to =
the
   Authentication-Results.
Apart from the grammatical glitch ("the each"), this ap= pears to me to be saying:=C2=A0 "Collect the contents of the A-R field= s that already exist and re-record those results into a new A-A-R field.&qu= ot;

Should that include the results computed by the ADMD = that's doing this work?

Either way, is this even poss= ible?=C2=A0 Since A-A-R is (apart from the "i=3D" tag) syntactica= lly identical to an A-R (RFC7601) header field, and an A-R field has a sing= le authserv-id, and the authserv-id is presumably integral to the final rec= ipient deciding whether to trust the message, what does an implementer do w= ith this?:

A-R: admd1; dkim=3Dpass header.d=3Dexample.com
A-R: admd2; dkim=3Dfail h= eader.d=3Dexample.com

= What A-A-R am I supposed to generate from that?=C2=A0 Does order matter?=C2= =A0 It seems to me that, at a minimum, the name(s) of the ADMD(s) will be l= ost; assuming that's okay, here's what I get:

A-A= -R: i=3DN; my-authserv-id; dkim=3Dpass header.d=3Dexample.com; dkim=3Dfail header.d=3Dexample.com

As a final recipient, I'd have no i= dea what to do with that.

Confused,

-M= SK
--f403043614160340ad054c4bd09a-- From nobody Mon Apr 3 17:21: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 2694412940D for ; Mon, 3 Apr 2017 17:21:49 -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 ty6FLT2auD_M for ; Mon, 3 Apr 2017 17:21:46 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B640D1293F3 for ; Mon, 3 Apr 2017 17:21:46 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id r203so145833083oib.3 for ; Mon, 03 Apr 2017 17:21:46 -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=cNh4EQbQq2rkGlshLd3INx5yAhcmrYt78gWwgtb5aJc=; b=voJ5jIY3wGLfEhbJOgP9xUR3JCk8EIDqwsHCb8uncN7RUYnsq+atr8fAdPgqC7S6R+ 0X03q6iT/7Rwce9dQWil73LO7VqJL9Rlxg1QctqxIEr8fjdqIqPHfx7X2A3XQZRWte8k c8YUxL+uZTiIUIXUd1OWHu7+J1d51/XAYYELvoVdLIM0RmvZeZTk7ks0XyDnh5h6rHla ej8HkX+tItYvyQkZYijSHlpnTi/pDd+x+GwTC3CSDksa+ERlj46Y0GYRuizo8vZ7QxRs JlpUWMxJUOQtWwI48iIdJZUYYut8AWrNo/qay6nDZPJnDTj4I4mftpYmJBg4eY34XjwL 1ZFQ== 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=cNh4EQbQq2rkGlshLd3INx5yAhcmrYt78gWwgtb5aJc=; b=DcJ9aQ0zqNYeUbHhO7F6e+X+A+//35di//KIoF4vIWHJmzuYUT28q+DEELhrtYAboc RBlGwehVixVTS9MUq5oftdh6zUmmJNCBql2ECiWTyPH2aeIeGr8wEzwZAtW7R3V/K6KV d79y/hQ0tjksgZ6dJl3ozgyTrga4tXW4Dt2c/gUMsQdFoE34BUWCycUO1Ddct1Zjj9F5 t4jTuqFVCS6tMOe2DzSVs02XhsjzI1aNktREQhFibze+NL+YFx5uQySLe5Ggv9J6+NWl be/hEf0xN2aS3aE4sfENI5CKOmkuBsWuXajLZt9RhaCUBLE4GbuBY+y99Mdl/AM5CPCD 4kEA== X-Gm-Message-State: AFeK/H2I488hCL+eZz1AqQTvPTzwd7fYqDwlWgvtIlOzxrrooEgybG4G1+lNN4URYEDjxtq51eQ7ycOEviX7RcUn X-Received: by 10.157.38.229 with SMTP id i34mr9763643otd.97.1491265305546; Mon, 03 Apr 2017 17:21:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.120.72 with HTTP; Mon, 3 Apr 2017 17:21:45 -0700 (PDT) In-Reply-To: References: From: Brandon Long Date: Mon, 3 Apr 2017 17:21:45 -0700 Message-ID: To: "Murray S. Kucherawy" Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a11393f36ce0c4b054c4c42bb Archived-At: Subject: Re: [dmarc-ietf] ARC-Authentication-Results 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, 04 Apr 2017 00:21:49 -0000 --001a11393f36ce0c4b054c4c42bb Content-Type: text/plain; charset=UTF-8 My goal for this is that you would only collect the auth-res header for the same admd and the same delivery step as is doing the arc-signing. Ie, if you assumed that there was a single Auth-Res header added during the smtp phase, you would copy that authres header. I realize with the milters, there are often multiple ones for each one, so you would collect all the ones for this admd and hop. So, in your example, if you are admd1, then you only include that one. An interesting question is what to do when re-signing, ie on the outbound side of mailing list expansion. For us, we just copied the inbound aar to the next "hop". You could also imagine that an outbound hop could remove and replace the inbound hop, and re-use the AAR. Since you are only allowed one "set" of AuthRes per authserv-id, presumably somewhere in the milter chain, all the existing authres headers for that admd would be removed, prior to new ones being added, so if you collect all of the existing ones for your admd, that should be fine. Brandon On Mon, Apr 3, 2017 at 4:49 PM, Murray S. Kucherawy wrote: > The latest ARC base document says this about the > ARC-Authentication-Results field: > > ARC-Authentication-Results is a direct copy of the Authentication- > Results header field [RFC7601 ] created for archival purposes by the > each MTA outside of the trust boundary of the originating system > which is contributing to the chain of ARC header fields. The > corresponding instance ("i=") tag value MUST be prefixed to the > Authentication-Results. > > Apart from the grammatical glitch ("the each"), this appears to me to be > saying: "Collect the contents of the A-R fields that already exist and > re-record those results into a new A-A-R field." > > Should that include the results computed by the ADMD that's doing this > work? > > Either way, is this even possible? Since A-A-R is (apart from the "i=" > tag) syntactically identical to an A-R (RFC7601) header field, and an A-R > field has a single authserv-id, and the authserv-id is presumably integral > to the final recipient deciding whether to trust the message, what does an > implementer do with this?: > > A-R: admd1; dkim=pass header.d=example.com > A-R: admd2; dkim=fail header.d=example.com > > What A-A-R am I supposed to generate from that? Does order matter? It > seems to me that, at a minimum, the name(s) of the ADMD(s) will be lost; > assuming that's okay, here's what I get: > > A-A-R: i=N; my-authserv-id; dkim=pass header.d=example.com; dkim=fail > header.d=example.com > > As a final recipient, I'd have no idea what to do with that. > > Confused, > > -MSK > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --001a11393f36ce0c4b054c4c42bb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My goal for this is that you would only collect the auth-r= es header for the same admd and the same delivery step as is doing the arc-= signing.

Ie, if you assumed that there was a single Auth-Res header= added during the smtp phase, you would copy that authres header.=C2=A0 I r= ealize with the milters, there are often multiple ones for each one, so you= would collect all the ones for this admd and hop.

So, in your example, if you are admd1, then you only include that one.

An interesting question is what to do when re-signing= , ie on the outbound side of mailing list expansion.=C2=A0 For us, we just = copied the inbound aar to the next "hop".=C2=A0 You could also im= agine that an outbound hop could remove and replace the inbound hop, and re= -use the AAR.

Since you are only allowed one "= ;set" of AuthRes per authserv-id, presumably somewhere in the milter c= hain, all the existing authres headers for that admd would be removed, prio= r to new ones being added, so if you collect all of the existing ones for y= our admd, that should be fine.

Brandon
=

On Mon, Apr 3, 20= 17 at 4:49 PM, Murray S. Kucherawy <superuser@gmail.com> w= rote:
The latest AR= C base document says this about the ARC-Authentication-Results field:
   ARC-Authentication-=
Results is a direct copy of the Authentication-
   Results header field [RFC7601] created for archival purposes by =
the
   each MTA outside of the trust boundary of the originating system
   which is contributing to the chain of ARC header fields.  The
   corresponding instance ("i=3D") tag value MUST be prefixed to =
the
   Authentication-Results.
Apart from the grammatical glitch ("the each"), this ap= pears to me to be saying:=C2=A0 "Collect the contents of the A-R field= s that already exist and re-record those results into a new A-A-R field.&qu= ot;

Should that include the results computed by the ADMD = that's doing this work?

Either way, is this even poss= ible?=C2=A0 Since A-A-R is (apart from the "i=3D" tag) syntactica= lly identical to an A-R (RFC7601) header field, and an A-R field has a sing= le authserv-id, and the authserv-id is presumably integral to the final rec= ipient deciding whether to trust the message, what does an implementer do w= ith this?:

A-R: admd1; dkim=3Dpass header.d=3Dexample.com
A-R: ad= md2; dkim=3Dfail header.d=3Dexample.com

What A-A-R am I supposed to generate fr= om that?=C2=A0 Does order matter?=C2=A0 It seems to me that, at a minimum, = the name(s) of the ADMD(s) will be lost; assuming that's okay, here'= ;s what I get:

A-A-R: i=3DN; my-authserv-id; dkim=3Dpass = header.d=3Dexample.com= ; dkim=3Dfail header.d=3De= xample.com

As a final recipient, I'd have no idea= what to do with that.

Confused,

-MSK<= br>

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


--001a11393f36ce0c4b054c4c42bb-- From nobody Mon Apr 3 17:22: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 4E9A51294CD for ; Mon, 3 Apr 2017 17:22:06 -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 3iw3yalebIuu for ; Mon, 3 Apr 2017 17:21:59 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::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 D9D4A129480 for ; Mon, 3 Apr 2017 17:21:57 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id z204so158543937vkd.1 for ; Mon, 03 Apr 2017 17:21:57 -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; bh=di6CTzO0f8NST46Sw7vH/alpxnkc4ASg26qc+XTE864=; b=Hem2DcWuiU7wF25cFannu3jXdKdHtl31pYyJpGvkUszuXdvEz9fdlx1CPoa9Cddw8J 0o4FGlx3gD7h6v5YOBAddtj1MjgmD640YogveP/Sm+2BrbmDcoiHMm3wvfTsRvc1WDB/ FC3M2BbBWSwWS0MtDe/mcQH0QngNUKmDyhjTFGVuRHdD0oBfwCJ0i74acDZVFIVTUTkf iYWWu2MbFmtoR7qo4FO7QogaHfjsZi4lWNG8KbOkCthTOQG20uXWKVBz5cl+t7rqjw8/ fYWfizVOorS8ElCoF6m7PBCTqNwfun02PnMdGCYsoMDgrmA4TEwIevYkt6mylR2+rhAG z4pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=di6CTzO0f8NST46Sw7vH/alpxnkc4ASg26qc+XTE864=; b=Q/9EyVrCNgDo95tpLqhVxr5uZfhjfewhw1O73PrGJnC+VJxq4knCOlX8cZJ5I4/iqO 6NgxiWcJ0b5TAYFWJM//Epkhy7Fo/axTym0VDKGGGCNBJYA7aXP6hDowLzM4j/mxcL3x sHf2t67+TjQMaODZjXkRYaWZyXfeZfQ0+J/c6bctWdGcgxMvF+CyFZ7niXJ6M90R7xx/ At2cUm4IaVRPSCekwYfD8OHALblfxpAkuePnAI0lm0kGj8o8G/NBFHhUNC+E+gdC9Vek t7FLZWnpWB1VyxOPftT4ESJmb1VdHUbiO7eMd7zTrEo9BFG+MsI4xsrRH+R9E80Uj+qv jM/g== X-Gm-Message-State: AFeK/H10JB9wc3ybHXF682iGKMuhUsMEhOm3h3udNk8p7j4Z1wTBNOL1rwGJfEPFD7cXpui/P2mWzgyqe7rcAQ== X-Received: by 10.31.96.198 with SMTP id u189mr5961743vkb.117.1491265316832; Mon, 03 Apr 2017 17:21:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.130.70 with HTTP; Mon, 3 Apr 2017 17:21:56 -0700 (PDT) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Mon, 3 Apr 2017 17:21:56 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a114e330279edab054c4c4344 Archived-At: Subject: Re: [dmarc-ietf] ARC-Authentication-Results 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, 04 Apr 2017 00:22:06 -0000 --001a114e330279edab054c4c4344 Content-Type: text/plain; charset=UTF-8 On Mon, Apr 3, 2017 at 4:49 PM, Murray S. Kucherawy wrote: > > As a final recipient, I'd have no idea what to do with that. > I'd be happy to propose alternative text to what's there, but first I'd like to understand what the downstream receivers want to get out of it. -MSK --001a114e330279edab054c4c4344 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 3, 2017 at 4:49 PM, Murray S. Kucherawy <su= peruser@gmail.com> wrote:

<= div>As a final recipient, I'd have no idea what to do with that.

I'd be happy to propose alter= native text to what's there, but first I'd like to understand what = the downstream receivers want to get out of it.

-MSK
=
--001a114e330279edab054c4c4344-- From nobody Mon Apr 3 17:25:21 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 64E86129467 for ; Mon, 3 Apr 2017 17:25:19 -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 cVk0NFICZgn2 for ; Mon, 3 Apr 2017 17:25:17 -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 78AFA129432 for ; Mon, 3 Apr 2017 17:25:17 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id d188so156914112vka.0 for ; Mon, 03 Apr 2017 17:25:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UJK2sacYA6czrBcwex7rdt8eKyaYMiXhfmiqheFAMyI=; b=axFgtybB5E3j5AJb4j0ULDg8AuuvcvOQOQLoWJNC8BzsusoXKLtG1Es2JS3RxjAd7h aezA7lw2ySmZecRhEbYKwzsuMycwBwn8BgJHvCGy/rUPBZSpaKZcz22mcXqJGQAklf+3 tyKgfL6jG2lChY6SzWT5M4z+sUp3yVF663HGNb8PkB+VNyljdW8NpD5nhMHrCkjDISke 6bqOUWshpF9qdf7yPwfAiHq4Nd75jlgyWDWmTfCnYCoNLvRoWbxoXBrofP2QDQI70g8m ieFvcIT96twkFNbAVnDcxPBILME5MivF/NhHz7eL/wLCBzJi4udu4u7XMYWLBnVMs3i+ eCbg== 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=UJK2sacYA6czrBcwex7rdt8eKyaYMiXhfmiqheFAMyI=; b=tuaK0sch6kxnkx+LswHkkjUBaM1BnNNAk3IpVowFGpLkOGevjxFhd2St8K1aohDMet rPpXEMJE8iPR/uVUHzs5K0tUOVJF3CZDVQJgUhT+t0Gh+2/y011Ymvw9pCrbbsmaVY0L KUcf2PdBqH0DydvKG39j3DFthzH8b+nkNp6tDgWYhd36GNngR0rc5A0Swvpr9uZfwE5I /SVwoKTGfZUpBFNe9HE+DjpYD2WkdIZvYQAitS3rcPFj4SYg8Wc/BduJi0KvC0uou4Yi 9/QkuHkXuAW1wPQmHUGxSPIF7D/lUuoxFIp3rrjBjLQ3c6RD2uDRsMHXkRnotYiycrp0 LMog== X-Gm-Message-State: AFeK/H00/jW9RuPBrUhbIf4XtcWDPl/B+x9vx9FaFeZfMrbPXtg2fUPfLEimNTaQfRwbazi9qK5+wUWLDeBXQQ== X-Received: by 10.31.139.79 with SMTP id n76mr9499978vkd.57.1491265516503; Mon, 03 Apr 2017 17:25:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.130.70 with HTTP; Mon, 3 Apr 2017 17:25:16 -0700 (PDT) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Mon, 3 Apr 2017 17:25:16 -0700 Message-ID: To: Brandon Long Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a11458ee660c13c054c4c4f61 Archived-At: Subject: Re: [dmarc-ietf] ARC-Authentication-Results 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, 04 Apr 2017 00:25:19 -0000 --001a11458ee660c13c054c4c4f61 Content-Type: text/plain; charset=UTF-8 On Mon, Apr 3, 2017 at 5:21 PM, Brandon Long wrote: > My goal for this is that you would only collect the auth-res header for > the same admd and the same delivery step as is doing the arc-signing. > > Ie, if you assumed that there was a single Auth-Res header added during > the smtp phase, you would copy that authres header. I realize with the > milters, there are often multiple ones for each one, so you would collect > all the ones for this admd and hop. > > So, in your example, if you are admd1, then you only include that one. > I'm wondering if I'm admd3 and there are A-Rs from admd1 and admd2, what do I add? Just mine? Theirs and mine? How do I combine them, especially if they disagree? An interesting question is what to do when re-signing, ie on the outbound > side of mailing list expansion. For us, we just copied the inbound aar to > the next "hop". You could also imagine that an outbound hop could remove > and replace the inbound hop, and re-use the AAR. > > Since you are only allowed one "set" of AuthRes per authserv-id, > presumably somewhere in the milter chain, all the existing authres headers > for that admd would be removed, prior to new ones being added, so if you > collect all of the existing ones for your admd, that should be fine. > OK so you're only adding your own here? If that's the case then the existing text is quite wrong because it's talking about collecting all the results form "each MTA outside of the trust boundary of the originating system" which to me means everything prior to you. -MSK --001a11458ee660c13c054c4c4f61 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 3, 2017 at 5:21 PM, Brandon Long <blong@google= .com> wrote:
My goal for this i= s that you would only collect the auth-res header for the same admd and the= same delivery step as is doing the arc-signing.

Ie, if you assumed= that there was a single Auth-Res header added during the smtp phase, you w= ould copy that authres header.=C2=A0 I realize with the milters, there are = often multiple ones for each one, so you would collect all the ones for thi= s admd and hop.

So, in your example, if you are ad= md1, then you only include that one.

I'm wondering if I'm admd3 and there are A-Rs from admd1 and = admd2, what do I add?=C2=A0 Just mine?=C2=A0 Theirs and mine?=C2=A0 How do = I combine them, especially if they disagree?

An interesting question is what to do w= hen re-signing, ie on the outbound side of mailing list expansion.=C2=A0 Fo= r us, we just copied the inbound aar to the next "hop".=C2=A0 You= could also imagine that an outbound hop could remove and replace the inbou= nd hop, and re-use the AAR.

Since you are only all= owed one "set" of AuthRes per authserv-id, presumably somewhere i= n the milter chain, all the existing authres headers for that admd would be= removed, prior to new ones being added, so if you collect all of the exist= ing ones for your admd, that should be fine.
<= br>
OK so you're only adding your own here?=C2=A0 If that'= ;s the case then the existing text is quite wrong because it's talking = about collecting all the results form "each MTA outside of the trust b= oundary of the originating system" which to me means everything prior = to you.

-MSK
--001a11458ee660c13c054c4c4f61-- From nobody Mon Apr 3 17:37:04 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 401A712940D for ; Mon, 3 Apr 2017 17:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 (2048-bit key) header.d=crash.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3TdNjhTGYnB for ; Mon, 3 Apr 2017 17:37:00 -0700 (PDT) Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C85781293F4 for ; Mon, 3 Apr 2017 17:37:00 -0700 (PDT) Received: from [10.10.10.41] (70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26]) (authenticated bits=0) by segv.crash.com (8.14.5/8.14.5/cci-colo-1.6) with ESMTP id v340aq6D023697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 3 Apr 2017 17:36:58 -0700 (PDT) (envelope-from smj@crash.com) X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com v340aq6D023697 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1491266218; bh=ksFWUqkQDaVtkZSiRjHHzcYc6jQPlo2KE/AEbPB2xQw=; h=Subject:To:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type; b=QfRrUX2cj8y6S7lLrcUxwDq3UZgTvRlft6f/PFeeeKPSOJGdhocAskX0wXG1YT8cP y0JoSVvLlOAZS2yrADGJPS17vCEGiaL+kS2TiuXpicZC/416C2jcXK7p0+oLhUrBvG z/sqRFs7LDwP5FcRFgOpkCHHaobMzIUafdMIG3REyYrB7/GAAqrZqPjDhbkE7blYoK uexwI8HSzJcT1+ttLlDP4hCMN0PM96B177uCK0FzlCFfs0MGYAf25bfecZfM+RNA2N 1Sf9LddGP3r9pJpUWTTIhwTnBS/IAQcfa0FPktvXL2cqfO/EwWa1vWwnCBDea3COxL bw1rJyDvdGfrg== X-Authentication-Warning: segv.crash.com: Host 70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26] claimed to be [10.10.10.41] To: dmarc@ietf.org References: From: Steven M Jones Organization: Crash Computing Message-ID: <44ca5ba1-e1ee-c485-d812-eb3b5ba23c35@crash.com> Date: Mon, 3 Apr 2017 17:36:54 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4FE83F58CC83E540069ADF5C" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (segv.crash.com [72.52.75.15]); Mon, 03 Apr 2017 17:36:58 -0700 (PDT) Archived-At: Subject: Re: [dmarc-ietf] ARC-Authentication-Results 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, 04 Apr 2017 00:37:03 -0000 This is a multi-part message in MIME format. --------------4FE83F58CC83E540069ADF5C Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 04/03/2017 16:49, Murray S. Kucherawy wrote: > The latest ARC base document says this about the > ARC-Authentication-Results field: > > ARC-Authentication-Results is a direct copy of the Authentication- > Results header field [RFC7601 ] created for archival purposes by the > each MTA outside of the trust boundary of the originating system > which is contributing to the chain of ARC header fields. The > corresponding instance ("i=") tag value MUST be prefixed to the > Authentication-Results. > > Apart from the grammatical glitch ("the each"), this appears to me to > be saying: "Collect the contents of the A-R fields that already exist > and re-record those results into a new A-A-R field." > > Should that include the results computed by the ADMD that's doing this > work? My POV, there is a strong 1:1 correlation between a set of ARC headers and a given ADMD. In this world view, the A-A-R would *not* collect all A-R values from all preceding ADMDs. The A-A-R attached by a given ADMD is meant to include the A-R value computed by that ADMD during receipt/validation of the message in question. So I would suggest language more like the following for 5.1.3's first paragraph: "ARC-Authentication-Results is a copy of the Authentication-Results header field [RFC7601] created during the receipt/validation of the message by an ADMD from a source external to that ADMD. In other words, a message is received by an ADMD and has an A-R computed and attached to the message. When an ADMD is creating an A-A-R, it takes the contents of the A-R header created by the same ADMD, prefixes it with the appropriate instance ("i=") tag value, and records it in the A-A-R." This probably needs language to handle the case where a given ADMD creates multiple A-R headers, at minimum. But before tackling that, let's have any objections to the general sense of the above paragraph, or the assertions before it? --S. --------------4FE83F58CC83E540069ADF5C Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 04/03/2017 16:49, Murray S. Kucherawy wrote:
The latest ARC base document says this about the ARC-Authentication-Results field:

   ARC-Authentication-Results is a direct copy of the Authentication-
   Results header field [RFC7601] created for archival purposes by the
   each MTA outside of the trust boundary of the originating system
   which is contributing to the chain of ARC header fields.  The
   corresponding instance ("i=") tag value MUST be prefixed to the
   Authentication-Results.
Apart from the grammatical glitch ("the each"), this appears to me to be saying:  "Collect the contents of the A-R fields that already exist and re-record those results into a new A-A-R field."

Should that include the results computed by the ADMD that's doing this work?

My POV, there is a strong 1:1 correlation between a set of ARC headers and a given ADMD. In this world view, the A-A-R would *not* collect all A-R values from all preceding ADMDs.

The A-A-R attached by a given ADMD is meant to include the A-R value computed by that ADMD during receipt/validation of the message in question. So I would suggest language more like the following for 5.1.3's first paragraph:

"ARC-Authentication-Results is a copy of the Authentication-Results header field [RFC7601] created during the receipt/validation of the message by an ADMD from a source external to that ADMD. In other words, a message is received by an ADMD and has an A-R computed and attached to the message. When an ADMD is creating an A-A-R, it takes the contents of the A-R header created by the same ADMD, prefixes it with the appropriate instance ("i=") tag value, and records it in the A-A-R."

This probably needs language to handle the case where a given ADMD creates multiple A-R headers, at minimum. But before tackling that, let's have any objections to the general sense of the above paragraph, or the assertions before it?

--S.
--------------4FE83F58CC83E540069ADF5C-- From nobody Mon Apr 3 17:42: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 7DBB31294CD for ; Mon, 3 Apr 2017 17:42: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 y_YMP9d4RtlD for ; Mon, 3 Apr 2017 17:42:54 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::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 A5418126B7F for ; Mon, 3 Apr 2017 17:42:54 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id d188so157215050vka.0 for ; Mon, 03 Apr 2017 17:42:54 -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=eXbvDY3U4n3rvHUjKIiRcKm3p16UvJnY1Sypbf/ioYU=; b=Fl/H3Q+FXsbmlq+192RTpUMg5dh0xRR8+6/jQXgkePpz4xV7Ko1TG/uERonwfBNu1/ btrASXWXvkNSJTnNqCwWCANt5HmK8vwpf7fIYwwdU/6IshbSHbjttHAf1sPktOJthK8P hGwf+xcDkEGTpr2BbdkDrKX6xKEzrMfrrldi+U9P1K9Z/QoI0cG90PL0NWFapZItSOo3 QwtNQoxTbmPGLQXdyosTCCMK/mT0sRczcahSfszlTD2izThJNvGGZLz1u0HSrkhbrpGC DtHNa7/uqUhEbYSOaz6VKhzO3YL1I5xD0YRnYv38AzuXlap3wQ5GHiJ2LzbgYKzemap0 trIw== 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=eXbvDY3U4n3rvHUjKIiRcKm3p16UvJnY1Sypbf/ioYU=; b=pDgMMyf5XnkNRPY3phDRzFr4St9H01mWxqEUhSXmAb2UprA56jMbKVJoqAtMPEYkvq dnmtaUX9BW4l89TrI0BXxyVjnosjhKcXdVLGd/tovrRE9YVxFEFIrDduZ2f/VbqgEIqf Jl9nQ21Ue4qixZSFDnSlWqIl7gC0BDzXzLFdH0PkknRR7YE5rxzBaBSxucHUlDXO2hu2 EcpshOf1x5Zvd0ACKP0sWMA4ySqf4y9BMQkrhRkbi2Nml/hrMN2hHKNynBqWhjyV5Rlm Fv02B2k+DyTInVYm48Y7bA+UXA0v1gLLanIC1HXLjuvd1TWC84IiTchX5ANjKVuTKRZX F6Ag== X-Gm-Message-State: AFeK/H2aKsTR32NFQW5YYzwWDLq24hEZyMVZIDfR5XkRnGmoieCARtCbZSOOsl1Y9+zfFaupNSWEhkuGX3Y1uQ== X-Received: by 10.31.33.75 with SMTP id h72mr9069181vkh.26.1491266573748; Mon, 03 Apr 2017 17:42:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.130.70 with HTTP; Mon, 3 Apr 2017 17:42:53 -0700 (PDT) In-Reply-To: <44ca5ba1-e1ee-c485-d812-eb3b5ba23c35@crash.com> References: <44ca5ba1-e1ee-c485-d812-eb3b5ba23c35@crash.com> From: "Murray S. Kucherawy" Date: Mon, 3 Apr 2017 17:42:53 -0700 Message-ID: To: Steven M Jones Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a11c01bca64d5eb054c4c8eac Archived-At: Subject: Re: [dmarc-ietf] ARC-Authentication-Results 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, 04 Apr 2017 00:42:57 -0000 --001a11c01bca64d5eb054c4c8eac Content-Type: text/plain; charset=UTF-8 On Mon, Apr 3, 2017 at 5:36 PM, Steven M Jones wrote: > My POV, there is a strong 1:1 correlation between a set of ARC headers and > a given ADMD. In this world view, the A-A-R would *not* collect all A-R > values from all preceding ADMDs. > It depends on what the goal is. If you only want to record what the ADMD itself directly evaluated, your proposal is fine. If you want to record what the ADMD thinks prior ADMDs claimed (e.g., GMail saying "Yahoo! claims this was fine when they got it"), then we must go deeper. But I don't know if that's what's actually needed, or would even be useful, or how one would evaluate the meaning of such an indirect claim without a lot of reputation data. -MSK --001a11c01bca64d5eb054c4c8eac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 3, 2017 at 5:36 PM, Steven M Jones <smj@crash.c= om> wrote:
=20 =20 =20
My POV,= there is a strong 1:1 correlation between a set of ARC headers and a given ADMD. In this world view, the A-A-R would *not* collect all A-R values from all preceding ADMDs.
=

It depends on what the goal is.=C2=A0 If you only want = to record what the ADMD itself directly evaluated, your proposal is fine.= =C2=A0 If you want to record what the ADMD thinks prior ADMDs claimed (e.g.= , GMail saying "Yahoo! claims this was fine when they got it"), t= hen we must go deeper.=C2=A0 But I don't know if that's what's = actually needed, or would even be useful, or how one would evaluate the mea= ning of such an indirect claim without a lot of reputation data.

-MSK
--001a11c01bca64d5eb054c4c8eac-- From nobody Mon Apr 3 17:47:42 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 4B96E12702E for ; Mon, 3 Apr 2017 17:47:41 -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=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 qRg4LmoduRM8 for ; Mon, 3 Apr 2017 17:47:39 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29B0D12952E for ; Mon, 3 Apr 2017 17:47:28 -0700 (PDT) Received: from [10.12.97.131] (unknown [166.170.30.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id B8D21C40023; Mon, 3 Apr 2017 19:48:37 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1491266917; bh=a7ikim1RX9rzKvnYeFBF9T0ihVOMoSNzK3tmejbJDEE=; h=Date:In-Reply-To:References:Subject:To:From:From; b=W0UImWTmhit76ILf8vnY6mUWuQ5XsAewsQgO1YVtrSgYipa/8OCBYV6zC+mTjR2uY 3bEsT31rsE/uuYzkcWS9PegJKrXtGUg3Qyc8gdSwm22nm9K2G0BXyLukhCe7Ukfcmp JgueWglAlihzMNGQKD2TJhk7ZfE6XeHeLRziBzo8= Date: Tue, 04 Apr 2017 00:47:24 +0000 In-Reply-To: References: <44ca5ba1-e1ee-c485-d812-eb3b5ba23c35@crash.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: <90A17C68-4ED2-4333-8927-B8F614174C73@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] ARC-Authentication-Results 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, 04 Apr 2017 00:47:41 -0000 On April 3, 2017 8:42:53 PM EDT, "Murray S=2E Kucherawy" wrote: >On Mon, Apr 3, 2017 at 5:36 PM, Steven M Jones wrote: > >> My POV, there is a strong 1:1 correlation between a set of ARC >headers and >> a given ADMD=2E In this world view, the A-A-R would *not* collect all >A-R >> values from all preceding ADMDs=2E >> > >It depends on what the goal is=2E If you only want to record what the >ADMD >itself directly evaluated, your proposal is fine=2E If you want to >record >what the ADMD thinks prior ADMDs claimed (e=2Eg=2E, GMail saying "Yahoo! >claims >this was fine when they got it"), then we must go deeper=2E But I don't >know >if that's what's actually needed, or would even be useful, or how one >would >evaluate the meaning of such an indirect claim without a lot of >reputation >data=2E I'm also not clear why we need a new header field=2E Why can ARC be a new= method for A-R? Scott K From nobody Mon Apr 3 18:16:28 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 49DCE12702E for ; Mon, 3 Apr 2017 18:16:27 -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 AsIb_Qi0cd00 for ; Mon, 3 Apr 2017 18:16:25 -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 73FE112940D for ; Mon, 3 Apr 2017 18:16:24 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id r69so159179159vke.2 for ; Mon, 03 Apr 2017 18:16:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=B6o48MegftkLL+AX0Kgl3mX4nT5RL3twoIyJzJdrupA=; b=UZZMM/hWv/t5DSTi7XM6BsBGEvxQeFTdE0bbgpJDDzpsPcTBHKD20dLi4T9j9Qebtq Ko7aiPIdeNaiZP9XB/lSQZqQ0Kivl8yCxTVCgxUT9lecQhrqPxB1/4ZNqhU14S0tJmrA DU+J7ueejRPqYGpSs7kC8tUo086FaaJd0cvgWD1lg6z3FFH738wAq1L065ol+Ym9zn+N JnOQDJTFp0wVF0zh96AZ3TgStrxLm53In4BBiwUkfgEnjCYhsBqUvPumh/60VjAAERfs OxkRM9vQoivwO49FFt5zbW7cQzXLNyABVBF1GSqXqEM9IkMQ6Ta4n1ejzxOaqq8QBDIo Gg+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=B6o48MegftkLL+AX0Kgl3mX4nT5RL3twoIyJzJdrupA=; b=FZ0pJGekbWiybArvQUyDn7fAtKrDVLNskrDYdW3rAoYm9s9BO+IqLjSGnPbmKMVxWO Y1GbEt8f0HaqzyKqLG1xiVc3kuPYSyVII0rcUbfkuKm1uRohQ4eWNM3OEVaqu6Ne1o7C IN/JuSLhKGu8vJcM8vEPaboYEhgCpDrEDY6OjnQrkicyq3yOZQky4k5ohg5iTi20q3wB iIZrupleiRQMD1g42XmsLdTOh7h6QQlVbY41+RVeNMnBaFUJmnq5Qpvphp3z0USa7oaQ Md5M4buBWonaf1RANONx6xuNPjqvcOac/tQOcgMmnsQXZKtXf7/EfPR/Y3765xXttaTG yBHA== X-Gm-Message-State: AFeK/H3Chgfg2v/S4ncAJ3neZVX93PkgOWDiePbF+rrEx+WnY1Hzdj4BwcOuLPKr1RWu8A7HUiEaN7wwYes+xg== X-Received: by 10.159.59.29 with SMTP id i29mr8824255uah.43.1491268583528; Mon, 03 Apr 2017 18:16:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.130.70 with HTTP; Mon, 3 Apr 2017 18:16:23 -0700 (PDT) In-Reply-To: <90A17C68-4ED2-4333-8927-B8F614174C73@kitterman.com> References: <44ca5ba1-e1ee-c485-d812-eb3b5ba23c35@crash.com> <90A17C68-4ED2-4333-8927-B8F614174C73@kitterman.com> From: "Murray S. Kucherawy" Date: Mon, 3 Apr 2017 18:16:23 -0700 Message-ID: To: Scott Kitterman Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=f403043c68202f9f1b054c4d0644 Archived-At: Subject: Re: [dmarc-ietf] ARC-Authentication-Results 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, 04 Apr 2017 01:16:27 -0000 --f403043c68202f9f1b054c4d0644 Content-Type: text/plain; charset=UTF-8 On Mon, Apr 3, 2017 at 5:47 PM, Scott Kitterman wrote: > I'm also not clear why we need a new header field. Why can ARC be a new > method for A-R? > The idea, as I understood it, is for AAR to record what a particular ADMD saw at ingress from DKIM and SPF (and maybe others), not to record what the ARC result is. The ARC result is in the ARC-Seal. (How's that for acronym soup?) -MSK --f403043c68202f9f1b054c4d0644 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 3, 2017 at 5:47 PM, Scott Kitterman <skli= st@kitterman.com> wrote:
I'm also not clear why we need a new header field.=C2=A0 Why can ARC b= e a new method for A-R?

The idea, as I = understood it, is for AAR to record what a particular ADMD saw at ingress f= rom DKIM and SPF (and maybe others), not to record what the ARC result is.= =C2=A0 The ARC result is in the ARC-Seal.

(How's that= for acronym soup?)

-MSK
--f403043c68202f9f1b054c4d0644-- From nobody Mon Apr 3 19:04: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 4C8A9129536 for ; Mon, 3 Apr 2017 19:04: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, HTML_MESSAGE=0.001, 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 (2048-bit key) header.d=crash.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Up0202nnwSm for ; Mon, 3 Apr 2017 19:04:13 -0700 (PDT) Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C307E129539 for ; Mon, 3 Apr 2017 19:04:10 -0700 (PDT) Received: from [10.10.10.41] (70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26]) (authenticated bits=0) by segv.crash.com (8.14.5/8.14.5/cci-colo-1.6) with ESMTP id v34242bC024752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 3 Apr 2017 19:04:08 -0700 (PDT) (envelope-from smj@crash.com) X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com v34242bC024752 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1491271448; bh=AaTFyciDdcAwRoDB9AGu8hshZcUmh1alYKT0YnWxSkM=; h=Subject:To:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type; b=hp/zkTMCF1YeWhoQhcPXZaKDOfkjOiwGv/P3+U5by02Cj1OQuoQgQbxI+R909QbCm RNXgFSyu+EzX6YnRFX5c5jdtuTCNK9/fxNKYidrCf2tfcmxJlfAXwnotFFtdMYBJDO qrvxOlK9XK0n1cp5fkO1Y011my1Qdclubn4Dy8yhkyPyJOxX9XaUFdXukt+j+u90Dk 8G4QWwRQTjDMRoVqtgkS4O/No5iHFZZ879RmUhm5NlMXfImDUtUxcCxU1qOPfwWWZp mZ7AFZ9sGsKsyE3lbpFyUSaeX8mbrVI8tFUQTLnEw3rSa6JQ1WBPoBohx71WCm74a6 SPjPmFgGmAc3Q== X-Authentication-Warning: segv.crash.com: Host 70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26] claimed to be [10.10.10.41] To: "dmarc@ietf.org" References: <44ca5ba1-e1ee-c485-d812-eb3b5ba23c35@crash.com> From: Steven M Jones Organization: Crash Computing Message-ID: <6ea9eaca-2960-c68e-1386-dbc55341ecd0@crash.com> Date: Mon, 3 Apr 2017 19:04:04 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------127CA38DC75C310CAC1E41F9" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (segv.crash.com [72.52.75.15]); Mon, 03 Apr 2017 19:04:08 -0700 (PDT) Archived-At: Subject: Re: [dmarc-ietf] ARC-Authentication-Results 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, 04 Apr 2017 02:04:15 -0000 This is a multi-part message in MIME format. --------------127CA38DC75C310CAC1E41F9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 04/03/2017 17:42, Murray S. Kucherawy wrote: > On Mon, Apr 3, 2017 at 5:36 PM, Steven M Jones > wrote: > > My POV, there is a strong 1:1 correlation between a set of ARC > headers and a given ADMD. In this world view, the A-A-R would > *not* collect all A-R values from all preceding ADMDs. > > > It depends on what the goal is. If you only want to record what the > ADMD itself directly evaluated, your proposal is fine. If you want to > record what the ADMD thinks prior ADMDs claimed (e.g., GMail saying > "Yahoo! claims this was fine when they got it"), then we must go deeper. Results/claims by prior ARC participants in a given message are recorded in their own ARC set ("i=N"), which they signed. Those are verified and signed by subsequent ARC participants. This is how an intact ARC chain provides the authentication results as observed by all/prior ARC participants. The 2nd/3rd/Nth ARC participant is not saying "I believe and trust the prior participants," just that "the signature(s) verified, and I can tell you what I saw re: authentication when I was receiving the message from hop N-1." By contrast (and referring back to the start of the thread) I think it would be unwise to include random A-R payloads one extracts from inbound messages. Anybody handling the message can inject a random A-R. Trying to extract only DKIM signed A-R headers from those messages can be difficult - for example, because the correct inbound authserv-id for an ADMD may not be clear to subsequent ADMDs, and where alterations may have subsequently occurred in transit that break the signatures or remove an A-R. --S. --------------127CA38DC75C310CAC1E41F9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 04/03/2017 17:42, Murray S. Kucherawy wrote:
On Mon, Apr 3, 2017 at 5:36 PM, Steven M Jones <smj@crash.com> wrote:
My POV, there is a strong 1:1 correlation between a set of ARC headers and a given ADMD. In this world view, the A-A-R would *not* collect all A-R values from all preceding ADMDs.

It depends on what the goal is.  If you only want to record what the ADMD itself directly evaluated, your proposal is fine.  If you want to record what the ADMD thinks prior ADMDs claimed (e.g., GMail saying "Yahoo! claims this was fine when they got it"), then we must go deeper.

Results/claims by prior ARC participants in a given message are recorded in their own ARC set ("i=N"), which they signed. Those are verified and signed by subsequent ARC participants. This is how an intact ARC chain provides the authentication results as observed by all/prior ARC participants. The 2nd/3rd/Nth ARC participant is not saying "I believe and trust the prior participants," just that "the signature(s) verified, and I can tell you what I saw re: authentication when I was receiving the message from hop N-1."

By contrast (and referring back to the start of the thread) I think it would be unwise to include random A-R payloads one extracts from inbound messages. Anybody handling the message can inject a random A-R. Trying to extract only DKIM signed A-R headers from those messages can be difficult - for example, because the correct inbound authserv-id for an ADMD may not be clear to subsequent ADMDs, and where alterations may have subsequently occurred in transit that break the signatures or remove an A-R.


--S.

--------------127CA38DC75C310CAC1E41F9-- From nobody Mon Apr 3 19:19: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 098B212953B for ; Mon, 3 Apr 2017 19:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=crash.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7NSYl6PzMRB for ; Mon, 3 Apr 2017 19:19:30 -0700 (PDT) Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA0EA127011 for ; Mon, 3 Apr 2017 19:19:30 -0700 (PDT) Received: from [10.10.10.41] (70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26]) (authenticated bits=0) by segv.crash.com (8.14.5/8.14.5/cci-colo-1.6) with ESMTP id v342JNTi025077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 3 Apr 2017 19:19:28 -0700 (PDT) (envelope-from smj@crash.com) X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com v342JNTi025077 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1491272368; bh=BGVAD+LmOue20e+NwD3RGjvylP5jK3g1OW0CzcSTIE4=; h=Subject:To:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=MZ8l+FeeCqID3Q4DP6fBg2pK6h+daHWttYIreUnkUoNqLlGB5aPzRvIkD4iThJoN5 uqDKYeAEFcpYc4WnXfIEXukUnIbk2Cw1oNywAuqA8kWVA5WYeWpBRzUjGp7gdc96fK P9jRZif/+AGXCoS6IEJN5V+Lkp8fHFJC2M9oMq4YQI944VpsLYwJXpi6pdnLjh/oGI XXAOWUQQBx0Xa/eGcJ+PNlHw6GPRHsI05ll0Wmj+CwLxg/3NX5/lMS9DUeAJ++JAfx ohx11aLvn4Q+lCQ+3mxaob/ez9N1JfeJtxN8d9knd9lqm2XKSm14d4MKK8GMAyIGRx XHYUS/NsoZFRA== X-Authentication-Warning: segv.crash.com: Host 70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26] claimed to be [10.10.10.41] To: dmarc@ietf.org References: <44ca5ba1-e1ee-c485-d812-eb3b5ba23c35@crash.com> <6ea9eaca-2960-c68e-1386-dbc55341ecd0@crash.com> From: Steven M Jones Organization: Crash Computing Message-ID: Date: Mon, 3 Apr 2017 19:19:25 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <6ea9eaca-2960-c68e-1386-dbc55341ecd0@crash.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (segv.crash.com [72.52.75.15]); Mon, 03 Apr 2017 19:19:28 -0700 (PDT) Archived-At: Subject: Re: [dmarc-ietf] ARC-Authentication-Results 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, 04 Apr 2017 02:19:32 -0000 On 04/03/2017 19:04, Steven M Jones wrote: > > Results/claims by prior ARC participants in a given message are > recorded in their own ARC set ("i=N"), which they signed. Those are > verified and signed by subsequent ARC participants. Excuse me, too imprecise. "Those signatures are verified and all prior ARC sets are signed by subsequent ARC participants."The subsequent ARC participants cannot verify prior ARC participants' results/claims. --S. From nobody Mon Apr 3 20:06:29 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 6792F129551 for ; Mon, 3 Apr 2017 20:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_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 ABLIo1M_k9XA for ; Mon, 3 Apr 2017 20:06:25 -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 945C4129545 for ; Mon, 3 Apr 2017 20:06:25 -0700 (PDT) Received: from android-df929938bd25e485.home.kitterman.com (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 52D1AC40023; Mon, 3 Apr 2017 22:07:36 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1491275256; bh=yTT55Qw4lhahbOyVH2mNiEc73MYCFJTkEhc4QDgdOKI=; h=Date:In-Reply-To:References:Subject:To:From:From; b=dAACfsmTjb7lxoSRZZ+dMe59qCsnwcDjT5CQOaoPKCMTI+ZyCuJ1h87nbNTra4oT3 xZZi/FwA3cR9IGH194WCDIbNsblGgkiJzuwBi/HPwKyO+8RFc7Jka5Vf1Cpu56eQBC 7NFFHxCC//Kl6EXo/VoYVvWnL/YqbyQfYYwsrXRQ= Date: Tue, 04 Apr 2017 03:06:21 +0000 In-Reply-To: References: <44ca5ba1-e1ee-c485-d812-eb3b5ba23c35@crash.com> <90A17C68-4ED2-4333-8927-B8F614174C73@kitterman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: <7F7D99FE-8441-47C9-B386-FFFD29B9D926@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] ARC-Authentication-Results 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, 04 Apr 2017 03:06:27 -0000 On April 3, 2017 9:16:23 PM EDT, "Murray S=2E Kucherawy" wrote: >On Mon, Apr 3, 2017 at 5:47 PM, Scott Kitterman >wrote: > >> I'm also not clear why we need a new header field=2E Why can ARC be a >new >> method for A-R? >> > >The idea, as I understood it, is for AAR to record what a particular >ADMD >saw at ingress from DKIM and SPF (and maybe others), not to record what >the >ARC result is=2E The ARC result is in the ARC-Seal=2E > >(How's that for acronym soup?) Lovely=2E Thanks=2E That makes more sense, but raises another concern then=2E It seems misnam= ed=2E A-A-R isn't an ARC result at all, it's part of the input to the ARC = process=2E Is the A-A-R intended to be used in normal ARC seal validation or is usefu= l for forensic purposes? If it's the former, then it might be better insid= e the ARC seal field rather than in a separate field=2E Then the bit about= correlation based on i=3D isn't necessary=2E If the latter, I think a dif= ferent name would be clearer=2E Maybe ARC-seal-data (A-S-D) or ARC-authent= ication-input (A-A-I)? Scott K From nobody Tue Apr 4 05:28:09 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 73566129682 for ; Tue, 4 Apr 2017 05:28:08 -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 (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3SaN3Q_ccFc for ; Tue, 4 Apr 2017 05:28:06 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BE05129672 for ; Tue, 4 Apr 2017 05:28:06 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id f193so160502242oib.2 for ; Tue, 04 Apr 2017 05:28:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1S0/bPUeOswzc1OlT1erOv6AGq64EFeoNnWdkYdmr9g=; b=HKa+JUgXOA0GS9MpjFlMAs8xVkZSZmEDdetXE0UckZk9vLgJrMt75J3JI3uR7F54YM RjpXzJtik2laD8wAemk3sl14HNYF0nSpXLOwseGVHT2bwBQkTylTchbzYZzK4MGbqciA eod2s24Ko43RaEXZNShcdodVbA+RHhoIUqzS8= 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=1S0/bPUeOswzc1OlT1erOv6AGq64EFeoNnWdkYdmr9g=; b=qrspgRpykcWbvo0FpJ+6FpVcgr2DcjZMWYU/6sQhmNnXwk3ZzCqDcw7XMpYrUtAWE1 LF35hCW/rUgvI6n2XfaqxoGkiAuMk+xP9t8UiJEV4oqYKdgoqeTOeg8gdF5R83J8SUCF s4EG2lEfCcUeszZ8Z2vTAAf/cyohQxYTV4NDv4YNgZPNfKJ6EK1y3cSTG5seboBCf9Aq 1iEQGnTiQbzd6Bhz8SctGDAanM7/HHJQ5WtrNXrDMEsYfIzp6MAiXVX4CZLUQVOEZeJn Mt7RFEwhuXzcelZsyAgE35CVpz6aZFNn4fnDISkNHW86W7RvWwdpegfH+VaBE9lsfUpC FOsA== X-Gm-Message-State: AFeK/H3ZF8j1LwpHqUJjYdC8e5nY3HYyfeXWuVsg/oGd9LiJN0K3Cdx9+iPblgh3YY4zXiWFOswGRvRA30Iz+g== X-Received: by 10.157.1.174 with SMTP id e43mr10802511ote.239.1491308885547; Tue, 04 Apr 2017 05:28:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.128.68 with HTTP; Tue, 4 Apr 2017 05:28:04 -0700 (PDT) Received: by 10.74.128.68 with HTTP; Tue, 4 Apr 2017 05:28:04 -0700 (PDT) In-Reply-To: References: From: Kurt Andersen Date: Tue, 4 Apr 2017 07:28:04 -0500 Message-ID: To: "Murray S. Kucherawy" Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary=94eb2c0be8ba5fac51054c566818 Archived-At: Subject: Re: [dmarc-ietf] ARC-Authentication-Results 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, 04 Apr 2017 12:28:08 -0000 --94eb2c0be8ba5fac51054c566818 Content-Type: text/plain; charset=UTF-8 On Apr 3, 2017 7:22 PM, "Murray S. Kucherawy" wrote: On Mon, Apr 3, 2017 at 4:49 PM, Murray S. Kucherawy wrote: > > As a final recipient, I'd have no idea what to do with that. > I'd be happy to propose alternative text to what's there, but first I'd like to understand what the downstream receivers want to get out of it. -MSK Attempting to reply to the chain as best I can from my phone (won't be back to work and a real keyboard until next Monday)... The grammar is indeed terrible and needs to be fixed. The intent is that the AAR reflects the computed A-R at the time the message enters a trust boundary. Only the A-R that it computes is put into its ARC set as the AAR. Depending upon implementation, an ADMD may affix an ARC set both upon entry and exit or may implement an ARC set that effectively spans the transit through its domain. I hope that helps... --Kurt --94eb2c0be8ba5fac51054c566818 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Apr 3, 2017 7:22 PM, "Murray S. Kucherawy" <superuser@gmail.com> wrote:
On Mon, Apr 3, 2017 at 4:49 PM, Murray S. Kucherawy <super= user@gmail.com> wrote:

As a final recipient, I'd have no ide= a what to do with that.

I'd be happy to propose alternative text to what's there, but fi= rst I'd like to understand what the downstream receivers want to get ou= t of it.

-MSK=C2=A0

Attempting to reply to th= e chain as best I can from my phone (won't be back to work and a real k= eyboard until next Monday)...

The grammar is indeed terrible and needs to be fixed. The intent is t= hat the AAR reflects the computed A-R at the time the message enters a trus= t boundary. Only the A-R that it computes is put into its ARC set as the AA= R. Depending upon implementation, an ADMD may affix an ARC set both upon en= try and exit or may implement an ARC set that effectively spans the transit= through its domain.

I h= ope that helps...

--Kurt=
--94eb2c0be8ba5fac51054c566818-- From nobody Tue Apr 4 13:34: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 7662A126E3A for ; Tue, 4 Apr 2017 13:34:21 -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 En2ykw6O16Ei for ; Tue, 4 Apr 2017 13:34:18 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003: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 7AA5312950E for ; Tue, 4 Apr 2017 13:34:15 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id r203so177416885oib.3 for ; Tue, 04 Apr 2017 13:34:15 -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=lmig6wXUJcVUcqSfv8tVvMdypUnQKBScELI2cTinlOc=; b=J7AUcbLCk4pbplb11lmgiFUEqa2pVo2jBPiY/HLOp8ojztU3UJewJHbYsah6nlgzLm NW0/Su5R4WmUYZsDnr6K5rMsPFspkUFqTZ619Dq2w/BgGPPIV+XeKBxAbtxpIsFMqo++ b7D7K+fakS92kW//1+DV9P0GRbLvd9nIpQuiMxatPsivnDtviZRN2tE1Alrj1Ar014ZT fZ3BznAUl+CT9wqBB8Yeyv4gVOQnXHbkVcwSKNb12YvDxzEVWE7y3WpwE1iTZgTGdBKk Cl5d0MV6zHoDXf1U62deW55viIRjE7UMz5VOtLx/LXYHIBTQ96l22QmWD4hqQxMVKzEY 0C9w== 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=lmig6wXUJcVUcqSfv8tVvMdypUnQKBScELI2cTinlOc=; b=DuHrAKnvcae5Vx1F0O2nkCq63qZicc0Vkq5FjVtzBsdSOEK8p6safpRk9CKbVM7/U1 +/klF4YMcXOv4xIolltxrRW2NvsXLllKmU4QNDChtc9XbLAF5DSEb2eHoB7QM2MGIpmH RPpbe8hSW7RnHx3R8tDsSfvhIBshabuq/j/8RhRrCUOJF4QQ+9Cjw/3af+1vf+4vZg3Y 2U0Mvs5ufwgR5xT8Qu4VDBzTn0cH14S/cXvAF/AchsEwUrm6ZcALlaltOlI5IMkjRBKX Ede4F1t3YVtI4EbJncCOwbqB2TH2ilR3FV+2Za+ZNgpm3ZJkfF+9TjXZ5xwD/zX0ijYE RIxg== X-Gm-Message-State: AFeK/H0wQRIQhB3YluK+RxYsEQVMas4/QjTPj2Mbz3wuqSqdNNL6pxr4YnhhbZys1SJmC0bTltRlW312y5SH/ONP X-Received: by 10.202.79.67 with SMTP id d64mr11140211oib.95.1491338054302; Tue, 04 Apr 2017 13:34:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.120.72 with HTTP; Tue, 4 Apr 2017 13:34:13 -0700 (PDT) In-Reply-To: References: <44ca5ba1-e1ee-c485-d812-eb3b5ba23c35@crash.com> From: Brandon Long Date: Tue, 4 Apr 2017 13:34:13 -0700 Message-ID: To: "Murray S. Kucherawy" Cc: Steven M Jones , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a113d72e4f80318054c5d3216 Archived-At: Subject: Re: [dmarc-ietf] ARC-Authentication-Results 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, 04 Apr 2017 20:34:21 -0000 --001a113d72e4f80318054c5d3216 Content-Type: text/plain; charset=UTF-8 On Mon, Apr 3, 2017 at 5:42 PM, Murray S. Kucherawy wrote: > On Mon, Apr 3, 2017 at 5:36 PM, Steven M Jones wrote: > >> My POV, there is a strong 1:1 correlation between a set of ARC headers >> and a given ADMD. In this world view, the A-A-R would *not* collect all A-R >> values from all preceding ADMDs. >> > > It depends on what the goal is. If you only want to record what the ADMD > itself directly evaluated, your proposal is fine. If you want to record > what the ADMD thinks prior ADMDs claimed (e.g., GMail saying "Yahoo! claims > this was fine when they got it"), then we must go deeper. But I don't know > if that's what's actually needed, or would even be useful, or how one would > evaluate the meaning of such an indirect claim without a lot of reputation > data. > > Knowing what the previous ADMD thought is explicitly a goal of ARC. The theory is, the first hop said that it was from yahoo.com and DKIM signature matched, and then the mailing list changed it so the DKIM signature is now broken, but I believe that the first hop was accurate, so I will bypass DMARC reject. Does it need to be included at every hop? Well, what if it goes through a mailing list at @google.com which does rewrite it to @google.com and DKIM signs it to pass, then another hop which rewrites all of the links to use Proofpoint's "smart malware redirector", so it would fail DMARC for a domain that wasn't the original domain or evaluation. The proposal which led to this, X-Original-Authentication-Results, was basically a way to pass a single AuthRes header forward (in our impl, it is only believed if it is covered by our X-Google-DKIM-Signature, ARC extends this to handling multiple hops. Brandon --001a113d72e4f80318054c5d3216 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Apr 3, 2017 at 5:42 PM, Murray S. Kucherawy &= lt;superuser@gmail= .com> wrote:
On Mon, Apr 3, 2017 at 5:36 PM, Steven M Jones <smj@crash.= com> wrote:
=20 =20 =20
My POV, there is a= strong 1:1 correlation between a set of ARC headers and a given ADMD. In this world view, the A-A-R would *not* collect all A-R values from all preceding ADMDs.
=

It depends on what the goal is.=C2=A0 If you onl= y want to record what the ADMD itself directly evaluated, your proposal is = fine.=C2=A0 If you want to record what the ADMD thinks prior ADMDs claimed = (e.g., GMail saying "Yahoo! claims this was fine when they got it"= ;), then we must go deeper.=C2=A0 But I don't know if that's what&#= 39;s actually needed, or would even be useful, or how one would evaluate th= e meaning of such an indirect claim without a lot of reputation data.

=

Knowing what the previous ADMD= thought is explicitly a goal of ARC.=C2=A0 The theory is, the first hop sa= id that it was from yahoo.com and DKIM sig= nature matched, and then the mailing list changed it so the DKIM signature = is now broken, but I believe that the first hop was accurate, so I will byp= ass DMARC reject.

Does it need to be included at e= very hop?=C2=A0 Well, what if it goes through a mailing list at @google.com which does rewrite it to @google.com and DKIM signs it to pass, then another hop = which rewrites all of the links to use Proofpoint's "smart malware= redirector", so it would fail DMARC for a domain that wasn't the = original domain or evaluation.

The proposal which = led to this, X-Original-Authentication-Results, was basically a way to pass= a single AuthRes header forward (in our impl, it is only believed if it is= covered by our X-Google-DKIM-Signature, ARC extends this to handling multi= ple hops.

Brandon=C2=A0
--001a113d72e4f80318054c5d3216-- From nobody Tue Apr 4 22:02:11 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 657BC1292AE for ; Tue, 4 Apr 2017 22:02:09 -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 bSC-3mDHiv5t for ; Tue, 4 Apr 2017 22:02:07 -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 4AEC9128BBB for ; Tue, 4 Apr 2017 22:02:07 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id d188so1246787vka.0 for ; Tue, 04 Apr 2017 22:02:07 -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=+wfq/JPctsTZVQmHcYDyPXTwMWc+KdjKn/a7SahP9uY=; b=YagVcX50Wb1egr4BWYZbRLyn3modgOxp7IrNDdcTayUOVqaXEWUwTrBpzwb3ULM1B9 QkCEK/M05c8t4YJkmoAELDN0C62iAPBYaGy4XhXzpqpq6mvnrhhub0l+kV1vyyj0nA1g FvDlHGYAY887OgkGJViT1FyBIwuQK/dqG7zfxZEdTlM39h/9U4oSvRrbA4Orf9XokaZr p53PxifYjb4fiOo6+V+YW/ys62Gwqh+Ii3g3EAAquGCuP+FR5ZOJfpdSrhKa5angDExj JLMiFsqYnf0kJZCUkStlEQetoK6f/pZyM3MxeG4QnrWebAuKcUw+abfrG8C1m2fg4uVb 9JgA== 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=+wfq/JPctsTZVQmHcYDyPXTwMWc+KdjKn/a7SahP9uY=; b=cw22dE3I/NcxxPArtSwzA3GORKq+E2xhYS9sWnxvrhyKQB7p6FXXH4cNmh8/Hj26E8 2nQZtx4p8USCs/bZucJci/h2OXmshjZ5N4qq5CgXLx+6S/SVjwkEauJMzV6i4hzufbw2 clWfe01we0ng6ePrt/rg28XScNvUTFU8LcKSvCq7Us5g19dow0vJJilLGHBsnRAn2H7g j0Q4Ah6o9BFXCrKuQKzWJ+AqmWab7hSw7N4OEdR88E13S/3xCJG3t3GY2a5mOHhOp7wa ySYRQ3VzUQA0lvVWBkoV57C/TVAWCcsEokf6LlPurTCtnk+g5kNd962FChoYOk2Dbjo3 M7Hg== X-Gm-Message-State: AFeK/H3FQj7xQ6e5Lky98/Ea/sqY0M1sr6fz4l35EgXDZ+I4dE0JVqEIgMWOfVB1H28Zc5ZbL21nZv/ONsLMFg== X-Received: by 10.31.96.198 with SMTP id u189mr9174420vkb.117.1491368526281; Tue, 04 Apr 2017 22:02:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.130.70 with HTTP; Tue, 4 Apr 2017 22:02:05 -0700 (PDT) In-Reply-To: References: <44ca5ba1-e1ee-c485-d812-eb3b5ba23c35@crash.com> From: "Murray S. Kucherawy" Date: Tue, 4 Apr 2017 22:02:05 -0700 Message-ID: To: Brandon Long Cc: Steven M Jones , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a114e33023d0250054c644bd8 Archived-At: Subject: Re: [dmarc-ietf] ARC-Authentication-Results 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, 05 Apr 2017 05:02:09 -0000 --001a114e33023d0250054c644bd8 Content-Type: text/plain; charset=UTF-8 On Tue, Apr 4, 2017 at 1:34 PM, Brandon Long wrote: > Knowing what the previous ADMD thought is explicitly a goal of ARC. The > theory is, the first hop said that it was from yahoo.com and DKIM > signature matched, and then the mailing list changed it so the DKIM > signature is now broken, but I believe that the first hop was accurate, so > I will bypass DMARC reject. > This seems to be the classic illustration of the DMARC problem. There are three actors: An author/sender, an intermediary (MLM, say), and a receiver; the MLM will invalidate the author's signature, so the receiver will bounce it. ARC fixes this by allowing the receiver to see what the MLM saw and make a decision based on that. It must either blindly or explicitly trust the MLM, each of which deserves at least a paragraph of discussion in ARC, but that's for another thread. But how does this extend beyond three actors? What if Yahoo! sends to an IETF list, which sends to an alumni remailer, which re-sends to Gmail? The Yahoo! signature (which you might trust explicitly or by reputation) is now one more hop away. Does this still work? -MSK --001a114e33023d0250054c644bd8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 4, 2017 at 1:34 PM, Brandon Long <blong@google= .com> wrote:
Knowing what the p= revious ADMD thought is explicitly a goal of ARC.=C2=A0 The theory is, the = first hop said that it was from yahoo.com and DKIM signature matched, and then the mailing list cha= nged it so the DKIM signature is now broken, but I believe that the first h= op was accurate, so I will bypass DMARC reject.

=
This seems to be the classic illustration of the DMARC problem.= =C2=A0 There are three actors: An author/sender, an intermediary (MLM, say)= , and a receiver; the MLM will invalidate the author's signature, so th= e receiver will bounce it.=C2=A0 ARC fixes this by allowing the receiver to= see what the MLM saw and make a decision based on that.=C2=A0 It must eith= er blindly or explicitly trust the MLM, each of which deserves at least a p= aragraph of discussion in ARC, but that's for another thread.

But how does this extend beyond three actors?=C2=A0 What if Yahoo!= sends to an IETF list, which sends to an alumni remailer, which re-sends t= o Gmail?=C2=A0 The Yahoo! signature (which you might trust explicitly or by= reputation) is now one more hop away.=C2=A0 Does this still work?

<= /div>
-MSK
--001a114e33023d0250054c644bd8-- From nobody Tue Apr 4 22:03: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 15947128D8B for ; Tue, 4 Apr 2017 22:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5V0AeZ4_5mnb for ; Tue, 4 Apr 2017 22:03:40 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::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 8E918128BA2 for ; Tue, 4 Apr 2017 22:03:40 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id g30so1450011uab.0 for ; Tue, 04 Apr 2017 22:03:40 -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=2HfcqzVSWU1CPbvYvMdq4e1L9zwMxyrU/cwAizFWwAw=; b=VTnbDdBhQYV/4WXhDH6wVgGs5VokOM1cgVqhYi3i9S5caFU/OYVcF4fnZwST7mcXnR cMveO3oXCoEP40eq4x9hh5ifNY6aGljxg0jH/LmGxBNPqhtJjcXnqBBT0IpPhv7DsOIp K3s++jeA/QqNqPi9JjPCklcn9d3rdqmRKANWQyYdwWmG3kSRxKqqtVw1xTDPR6kKVw59 QEMPgoR0OI4Z+RpWSPvzqA+SKgTaB6RHcZ5OYN59wgPgeO0S+HZLjYfdN0ihCxDW9Zui uxZpVWapdaZoYPjcTvdDHXDw/2DDWZ87nEw99txLCnDuWSqDnIoJjTyFy2Z3+iSLSiLX 5OXw== 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=2HfcqzVSWU1CPbvYvMdq4e1L9zwMxyrU/cwAizFWwAw=; b=pFqnuorIEislDow4HZMAoVimdAZxQq8cc4cW1mzN5euWZOm2292UjdMBiRf4w5uZwR inv56z0z1jqpqceajBjUIZVt5aQSAkrvT23096sBCPmRx/Dz1AiHizyz2ZAdMVnrCGY+ X+HQGuXnIBRXDABabzrmanYpT6EPhu3Ej/aEosbsK1SMpleNxSf+gFDIhzYUUc3S0gJX oxjRTLOVpuBg4pLIZ55sEjE44zex7eI13YVaJ90mQ+/UYLgkOjhP/bGW2gfeLTAr3qRr AiwyhRGDnvX41wFM03i/P1rJbrDQaA6S/T5WJDwjuwJSk/62KqkwDkNQAl2rW9X7D0Qs 8pvw== X-Gm-Message-State: AFeK/H0T1+OhuRrQmyrAD3A7NWoUzU3d2J9JbAYX7gwiFsjPwY0rJp6O8fOyYj5xsB0eUOJeQ0vbT+mUPdi8jA== X-Received: by 10.159.32.163 with SMTP id 32mr13923646uaa.160.1491368619646; Tue, 04 Apr 2017 22:03:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.130.70 with HTTP; Tue, 4 Apr 2017 22:03:39 -0700 (PDT) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Tue, 4 Apr 2017 22:03:39 -0700 Message-ID: To: Kurt Andersen Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c0b6d8acda189054c6450e7 Archived-At: Subject: Re: [dmarc-ietf] ARC-Authentication-Results 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, 05 Apr 2017 05:03:43 -0000 --94eb2c0b6d8acda189054c6450e7 Content-Type: text/plain; charset=UTF-8 On Tue, Apr 4, 2017 at 5:28 AM, Kurt Andersen wrote: > The grammar is indeed terrible and needs to be fixed. The intent is that > the AAR reflects the computed A-R at the time the message enters a trust > boundary. Only the A-R that it computes is put into its ARC set as the AAR. > Depending upon implementation, an ADMD may affix an ARC set both upon entry > and exit or may implement an ARC set that effectively spans the transit > through its domain. > So it's nothing more than an A-R with an instance number and a different field name. Presumably you want the new name specifically to permit addition of the instance name, and to bind it to a specific ARC Set without having to do the dance with the authserv-id. -MSK --94eb2c0b6d8acda189054c6450e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 4, 2017 at 5:28 AM, Kurt Andersen <kurta@drkur= t.com> wrote:
The grammar is i= ndeed terrible and needs to be fixed. The intent is that the AAR reflects t= he computed A-R at the time the message enters a trust boundary. Only the A= -R that it computes is put into its ARC set as the AAR. Depending upon impl= ementation, an ADMD may affix an ARC set both upon entry and exit or may im= plement an ARC set that effectively spans the transit through its domain.

So it's nothing more than an A-R w= ith an instance number and a different field name.=C2=A0 Presumably you wan= t the new name specifically to permit addition of the instance name, and to= bind it to a specific ARC Set without having to do the dance with the auth= serv-id.

-MSK
--94eb2c0b6d8acda189054c6450e7-- From nobody Tue Apr 4 22:07:12 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 DD02D128BB7 for ; Tue, 4 Apr 2017 22:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtO0KB7y7fIj for ; Tue, 4 Apr 2017 22:07:09 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::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 01E3F124D68 for ; Tue, 4 Apr 2017 22:07:08 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id d64so1460364uad.2 for ; Tue, 04 Apr 2017 22:07:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+lgHjJF856ysl2rYy8O0Sxs3PKuH0/S/JmlsK72VmJ0=; b=GFD5MUodyDfGyrIP0Bdf89GDniYfe+41wFtmyKwl5B+uamIMcTziWVJEeNPwwVxZJl Gi2NaDrpmZjyYlPcnJPRQSP/swm072vElIOd3p5EuCMDeG2rNCKrur0FhKNBL3P2Ivpu ZNpOYj9qgpm/V3Xd0uZYVy+HPCI6GI4vAEGoEUUK42wKtobAg4twEtA4vHHJd9N5/Hin A2/RS8mAd2nPmQHrdxdq/P9bI9QpE3GGQvuuga2VT+QxwgZmymmC7Ir1Kq07oe99WaYR I8y5wgDJAUPnEPn4ItTJgye2RqfOSXvkl81I5pfhJB86Md7bBQa17bXjaPYrT3lNh94D qOgQ== 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=+lgHjJF856ysl2rYy8O0Sxs3PKuH0/S/JmlsK72VmJ0=; b=qz1lIaeFFMmuRnqTWkZKO1mum3tWddxpw9y5mAzk0h8/Qbx36mAVe/XSjksRR/Ik/6 UiNuSIjJNm3G1eeMIoCbJW3sun4SiUITyYJk/qd7aBm1XbMfyYm6Q0bDntJtX8+69rU2 GqVMJ/fkoHWvJhOqBER/Vuf1ECyzH5IH8P7L5FboswqFvKWnXR688ri7Xmel75zws/Bv R16yJ+lSc06SA+gcpvCPsAEyDfYXM/Sjvnzd0eplH69z+fY7chBb2nT5c78566VrjpBD oX/TWbRltQv/FfVD4+SDKXssIDxIt0M6Rzec4vZ7oBOulbQXB9Dn7ReNF69gNzteys6B C2ow== X-Gm-Message-State: AFeK/H2EWf8ix2bqC4pK12f8WQVyf269j4CqBqYse/zzLJ29gVH3oo0dJ8hPQyByERxFLHylpcDbYeo8BUtwog== X-Received: by 10.176.92.13 with SMTP id q13mr14064049uaf.149.1491368827816; Tue, 04 Apr 2017 22:07:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.130.70 with HTTP; Tue, 4 Apr 2017 22:07:07 -0700 (PDT) In-Reply-To: <7F7D99FE-8441-47C9-B386-FFFD29B9D926@kitterman.com> References: <44ca5ba1-e1ee-c485-d812-eb3b5ba23c35@crash.com> <90A17C68-4ED2-4333-8927-B8F614174C73@kitterman.com> <7F7D99FE-8441-47C9-B386-FFFD29B9D926@kitterman.com> From: "Murray S. Kucherawy" Date: Tue, 4 Apr 2017 22:07:07 -0700 Message-ID: To: Scott Kitterman Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=f403043614163610e5054c645d92 Archived-At: Subject: Re: [dmarc-ietf] ARC-Authentication-Results 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, 05 Apr 2017 05:07:11 -0000 --f403043614163610e5054c645d92 Content-Type: text/plain; charset=UTF-8 On Mon, Apr 3, 2017 at 8:06 PM, Scott Kitterman wrote: > That makes more sense, but raises another concern then. It seems > misnamed. A-A-R isn't an ARC result at all, it's part of the input to the > ARC process. > I think it's not named that way because it's conveying an ARC result, but rather to make it more obvious that it's part of an ARC Set, where all three header fields are added at the same time. > Is the A-A-R intended to be used in normal ARC seal validation or is > useful for forensic purposes? If it's the former, then it might be better > inside the ARC seal field rather than in a separate field. Then the bit > about correlation based on i= isn't necessary. If the latter, I think a > different name would be clearer. Maybe ARC-seal-data (A-S-D) or > ARC-authentication-input (A-A-I)? > No opinion there. The current name makes its syntax and semantics immediately recognizable, but mixing it into the ARC-Seal is plausible. -MSK --f403043614163610e5054c645d92 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 3, 2017 at 8:06 PM, Scott Kitterman <skli= st@kitterman.com> wrote:
That makes more sense, = but raises another concern then.=C2=A0 It seems misnamed.=C2=A0 A-A-R isn&#= 39;t an ARC result at all, it's part of the input to the ARC process.

I think it's not named that way beca= use it's conveying an ARC result, but rather to make it more obvious th= at it's part of an ARC Set, where all three header fields are added at = the same time.
=C2=A0
Is the A-A-R intended to be used in normal ARC seal validation or is useful= for forensic purposes?=C2=A0 If it's the former, then it might be bett= er inside the ARC seal field rather than in a separate field.=C2=A0 Then th= e bit about correlation based on i=3D isn't necessary.=C2=A0 If the lat= ter, I think a different name would be clearer.=C2=A0 Maybe ARC-seal-data (= A-S-D) or ARC-authentication-input (A-A-I)?

=
No opinion there.=C2=A0 The current name makes its syntax and semantic= s immediately recognizable, but mixing it into the ARC-Seal is plausible.
-MSK
--f403043614163610e5054c645d92-- From nobody Wed Apr 5 05:35: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 EA02A127B57 for ; Wed, 5 Apr 2017 05:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 mdZmKcptAjOa for ; Wed, 5 Apr 2017 05:35:01 -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 A92D3126BF0 for ; Wed, 5 Apr 2017 05:35:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=americangreetings.com; s=q42010; c=relaxed/relaxed; q=dns/txt; i=@americangreetings.com; t=1491395700; x=1522931700; h=From:Subject:Date:To:Cc:Reply-To:Message-ID:MIME-Version:Content-Type; bh=yfxfyvi+8hXrZXXg0gZ5a/f2DebB1zbKgROhalJhnoE=; b=kRQM2od/tISqXqpl3b369Bla94uqvIBsxv5JQEeNm/fj3XsuqJkW3QRh2qEqgk1q zDr40Q5Z+3m4827OIN8TazB5FIP60xojO4ueDUMSKcJ+2+m7VsFdcmRBtye+Kj9p rFiNOMnVE6ukyjbQFqCYu6PEOVecZT/IQASME7NOP04=; Received: from [66.119.43.83] ([66.119.43.83:4202] helo=dc3-mbox.ops.ag.com) by momentum8 (envelope-from ) (ecelerity 3.6.18.52357 r(Core:3.6.18.0)) with ESMTP id 9C/BA-30912-474E4E85; Wed, 05 Apr 2017 08:35:00 -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 v35CYx0C020146 for ; Wed, 5 Apr 2017 08:35:00 -0400 To: dmarc@ietf.org References: <44ca5ba1-e1ee-c485-d812-eb3b5ba23c35@crash.com> From: "mhammer@americangreetings.com" Message-ID: Date: Wed, 5 Apr 2017 08:34:59 -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: Content-Type: multipart/alternative; boundary="------------4DC9AE33EA79E13C778E5013" Archived-At: Subject: Re: [dmarc-ietf] ARC-Authentication-Results 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, 05 Apr 2017 12:35:04 -0000 This is a multi-part message in MIME format. --------------4DC9AE33EA79E13C778E5013 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 4/5/2017 1:02 AM, Murray S. Kucherawy wrote: > On Tue, Apr 4, 2017 at 1:34 PM, Brandon Long > wrote: > > Knowing what the previous ADMD thought is explicitly a goal of > ARC. The theory is, the first hop said that it was from yahoo.com > and DKIM signature matched, and then the > mailing list changed it so the DKIM signature is now broken, but I > believe that the first hop was accurate, so I will bypass DMARC > reject. > > > This seems to be the classic illustration of the DMARC problem. There > are three actors: An author/sender, an intermediary (MLM, say), and a > receiver; the MLM will invalidate the author's signature, so the > receiver will bounce it. ARC fixes this by allowing the receiver to > see what the MLM saw and make a decision based on that. It must > either blindly or explicitly trust the MLM, each of which deserves at > least a paragraph of discussion in ARC, but that's for another thread. > In earlier (early?) discussions for the design of ARC, reputation of the MLM or other participants in the chain (which is outside the scope of the document) was an important part of the discussion. I think how well this works can only be determined once there are more ARC implementations in the wild. > But how does this extend beyond three actors? What if Yahoo! sends to > an IETF list, which sends to an alumni remailer, which re-sends to > Gmail? The Yahoo! signature (which you might trust explicitly or by > reputation) is now one more hop away. Does this still work? > Same as above. My sense is that it might be possible to game the system at very low volumes of abuse but bad (ARC) chains will be identified at larger volumes. What the thresholds are is anyone's guess. > -MSK > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc Mike --------------4DC9AE33EA79E13C778E5013 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 4/5/2017 1:02 AM, Murray S. Kucherawy wrote:
On Tue, Apr 4, 2017 at 1:34 PM, Brandon Long <blong@google.com> wrote:
Knowing what the previous ADMD thought is explicitly a goal of ARC.  The theory is, the first hop said that it was from yahoo.com and DKIM signature matched, and then the mailing list changed it so the DKIM signature is now broken, but I believe that the first hop was accurate, so I will bypass DMARC reject.

This seems to be the classic illustration of the DMARC problem.  There are three actors: An author/sender, an intermediary (MLM, say), and a receiver; the MLM will invalidate the author's signature, so the receiver will bounce it.  ARC fixes this by allowing the receiver to see what the MLM saw and make a decision based on that.  It must either blindly or explicitly trust the MLM, each of which deserves at least a paragraph of discussion in ARC, but that's for another thread.

In earlier (early?) discussions for the design of ARC, reputation of the MLM or other participants in the chain (which is outside the scope of the document) was an important part of the discussion. I think how well this works can only be determined once there are more ARC implementations in the wild.

But how does this extend beyond three actors?  What if Yahoo! sends to an IETF list, which sends to an alumni remailer, which re-sends to Gmail?  The Yahoo! signature (which you might trust explicitly or by reputation) is now one more hop away.  Does this still work?


Same as above. My sense is that it might be possible to game the system at very low volumes of abuse but bad (ARC) chains will be identified at larger volumes. What the thresholds are is anyone's guess.

-MSK


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


Mike

--------------4DC9AE33EA79E13C778E5013-- From nobody Thu Apr 6 10:32: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 C4A4312957D for ; Thu, 6 Apr 2017 10:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eisj2A-z1Dvy for ; Thu, 6 Apr 2017 10:32:39 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [IPv6:2610:20:6005:13::150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B98C21295EA for ; Thu, 6 Apr 2017 10:32:38 -0700 (PDT) Received: from WSGHUB2.xchange.nist.gov (129.6.42.35) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 6 Apr 2017 13:32:25 -0400 Received: from postmark.nist.gov (129.6.16.94) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.3.319.2; Thu, 6 Apr 2017 13:32:36 -0400 Received: from had3.antd.nist.gov ([129.6.141.200]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id v36HWR1s017354 for ; Thu, 6 Apr 2017 13:32:27 -0400 References: <149149960391.22024.11499305209108527807.idtracker@ietfa.amsl.com> To: From: Scott Rose X-Forwarded-Message-Id: <149149960391.22024.11499305209108527807.idtracker@ietfa.amsl.com> Message-ID: Date: Thu, 6 Apr 2017 13:32:27 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <149149960391.22024.11499305209108527807.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner-Information: Archived-At: Subject: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-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: Thu, 06 Apr 2017 17:32:42 -0000 This may be of interest to this group, as there isn't an active DKIM WG anymore. This is my first attempt to produce a draft about defining new digital algorithms for DKIM. I'm trying to keep this short i.e. only define a few IANA registry entries and that's it. I'm trying to head off a potential issue for organizations that are told to migrate to ECDSA or looking for algorithm agility that doesn't involve using SHA-1. Comments welcome and needed. Including being told this isn't needed (though I think it might be). Scott Rose NIST -------- Forwarded Message -------- Subject: New Version Notification for draft-srose-dkim-ecc-00.txt Date: Thu, 6 Apr 2017 10:26:43 -0700 From: internet-drafts@ietf.org To: Scott Rose A new version of I-D, draft-srose-dkim-ecc-00.txt has been successfully submitted by Scott Rose and posted to the IETF repository. Name: draft-srose-dkim-ecc Revision: 00 Title: Defining Elliptic Curve Cryptography Algorithms for use with DKIM Document date: 2017-04-06 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-srose-dkim-ecc-00.txt Status: https://datatracker.ietf.org/doc/draft-srose-dkim-ecc/ Htmlized: https://tools.ietf.org/html/draft-srose-dkim-ecc-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-srose-dkim-ecc-00 Abstract: DomainKeys Identified Mail (DKIM) uses digital signature to associate a message with a given sending domain. Currently, there is only one cryptography algorithm defined for use with DKIM (RSA). This document defines four new elliptic curve cryptography algorithms for use with DKIM. This will allow for algorithm agility if a weakness is found in RSA, and allows for smaller key length to provide the same digital signature strength. 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. The IETF Secretariat From nobody Thu Apr 6 14:28: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 E8B2C12945E for ; Thu, 6 Apr 2017 14:28:21 -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_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=corp.mail.ru 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 Tb153yCue34j for ; Thu, 6 Apr 2017 14:28:18 -0700 (PDT) Received: from smtp21.mail.ru (smtp21.mail.ru [94.100.179.250]) (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 6E3DD1294A4 for ; Thu, 6 Apr 2017 14:28:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=corp.mail.ru; s=mail; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=3FFQLqmQeROScXeYrlB4TbCH7+n63V6Hqpdo/nNOKuA=; b=Xwxsbk12lq68FiHkmFd5QTR20+uMVRUPLnyIoLnUcDxIf7yHMvkuHMtJdZob3Z6t4P9FQlHu3vBKJyonOYAQp6rrVV3dEeJS8QO9X+jmK195lZ5I0RfXlf0v+Yb3GQDL6+/YuyfuoOLZP/sqwaTkqMxo/+U9F093s4XHYjjnzXQ=; Received: from gate.3proxy.ru ([95.79.31.239]:62350 helo=[127.0.0.1]) by smtp21.mail.ru with esmtpa (envelope-from ) id 1cwEwu-0000TA-MD; Fri, 07 Apr 2017 00:28:13 +0300 To: Scott Rose , "dmarc@ietf.org" References: <149149960391.22024.11499305209108527807.idtracker@ietfa.amsl.com> From: Vladimir Dubrovin Message-ID: Date: Fri, 7 Apr 2017 00:28:10 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B5ECBF7DD255ACCFC55C5140" Authentication-Results: smtp21.mail.ru; auth=pass smtp.auth=dubrovin@corp.mail.ru smtp.mailfrom=dubrovin@corp.mail.ru X-7FA49CB5: 0D63561A33F958A555A373A2EF246E09C7C48DA462C775D3C51E545D75AB57429F18ECD7E95F35E929AFE063DF4C541C70BF3F6ACA3A28AFFBDEBB5FAF816B060BF2EBBBDD9D6B0F2AF914666EE41260 X-Mailru-Sender: C5364AD02485212FBEAE30F3FA322883228C178CD7CAB48FC8D4356BD0D6A11B0E8F58CB380BC13FCDCEB298E575E7B2C77752E0C033A69EDAAA56350C7513E7ACB45E4F000D93863453F38A29522196 X-Mras: OK Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-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: Thu, 06 Apr 2017 21:28:22 -0000 This is a multi-part message in MIME format. --------------B5ECBF7DD255ACCFC55C5140 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hello Scott, it may be good to cover compatibility issues, because otherwise there are little chances to succeed the older but more compatible protocols in nearest future. The possible (but probably not the best one) solution is: 1. produce 2 different DKIM-Signatures with 2 different selectors: slector1 with SHA-1 + RSA and selector2 one with SHA-512 + ECDSA 2. add an additional field to either selector1 DKIM DNS record (need to consult RFC if it's allowed) or to DKIM-Signature with selector1 (it's allowed but probably is not enough to protect against downgrade) to indicate the selector is legacy-only, e.g. o=sha512/eccp256 to indicate this selector should be ignored if verifier supports sha-512 and eccp256. Legacy verifier has valid DKIM-Signature with sha1+rsa Compatible verifier ignores sha1+rsa and choose sha-512+ECDSA I can imagine few more ways to resolve compatibility issues, but this one seems to be a simplest. 06.04.2017 20:32, Scott Rose Đ¿Đ¸ÑˆĐµÑ‚: > This may be of interest to this group, as there isn't an active DKIM > WG anymore. This is my first attempt to produce a draft about > defining new digital algorithms for DKIM. I'm trying to keep this > short i.e. only define a few IANA registry entries and that's it. > > I'm trying to head off a potential issue for organizations that are > told to migrate to ECDSA or looking for algorithm agility that doesn't > involve using SHA-1. > > Comments welcome and needed. Including being told this isn't needed > (though I think it might be). > > Scott Rose > > NIST > > > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-srose-dkim-ecc-00.txt > Date: Thu, 6 Apr 2017 10:26:43 -0700 > From: internet-drafts@ietf.org > To: Scott Rose > > > > A new version of I-D, draft-srose-dkim-ecc-00.txt > has been successfully submitted by Scott Rose and posted to the > IETF repository. > > Name: draft-srose-dkim-ecc > Revision: 00 > Title: Defining Elliptic Curve Cryptography Algorithms for use > with DKIM > Document date: 2017-04-06 > Group: Individual Submission > Pages: 6 > URL: > https://www.ietf.org/internet-drafts/draft-srose-dkim-ecc-00.txt > Status: https://datatracker.ietf.org/doc/draft-srose-dkim-ecc/ > Htmlized: https://tools.ietf.org/html/draft-srose-dkim-ecc-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-srose-dkim-ecc-00 > > > Abstract: > DomainKeys Identified Mail (DKIM) uses digital signature to associate > a message with a given sending domain. Currently, there is only one > cryptography algorithm defined for use with DKIM (RSA). This > document defines four new elliptic curve cryptography algorithms for > use with DKIM. This will allow for algorithm agility if a weakness > is found in RSA, and allows for smaller key length to provide the > same digital signature strength. > > > > > 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. > > The IETF Secretariat > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc -- Vladimir Dubrovin @Mail.Ru --------------B5ECBF7DD255ACCFC55C5140 Content-Type: multipart/related; boundary="------------D186BDF95006EE9D0565A5D3" --------------D186BDF95006EE9D0565A5D3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Hello Scott,

it may be good to cover compatibility issues, because otherwise there are little chances to succeed the older but more compatible protocols in nearest future.  The possible (but probably not the best one) solution is:

1. produce 2 different DKIM-Signatures with 2 different selectors: slector1  with SHA-1 + RSA and selector2 one with  SHA-512 + ECDSA
2. add an additional field to either selector1 DKIM DNS record (need to consult RFC if it's allowed) or to DKIM-Signature with selector1 (it's allowed but probably is not enough to protect against downgrade) to indicate the selector is legacy-only, e.g. o=sha512/eccp256 to indicate this selector should be ignored if verifier supports sha-512 and eccp256.

Legacy verifier has valid DKIM-Signature with sha1+rsa
Compatible verifier ignores sha1+rsa and choose sha-512+ECDSA

I can imagine few more ways to resolve compatibility issues, but this one seems to be a simplest.


06.04.2017 20:32, Scott Rose Đ¿Đ¸ÑˆĐµÑ‚:
This may be of interest to this group, as there isn't an active DKIM WG anymore.  This is my first attempt to produce a draft about defining new digital algorithms for DKIM.  I'm trying to keep this short i.e. only define a few IANA registry entries and that's it.

I'm trying to head off a potential issue for organizations that are told to migrate to ECDSA or looking for algorithm agility that doesn't involve using SHA-1.

Comments welcome and needed. Including being told this isn't needed (though I think it might be).

Scott Rose

NIST



-------- Forwarded Message --------
Subject:     New Version Notification for draft-srose-dkim-ecc-00.txt
Date:     Thu, 6 Apr 2017 10:26:43 -0700
From:     internet-drafts@ietf.org
To:     Scott Rose <scott.rose@nist.gov>



A new version of I-D, draft-srose-dkim-ecc-00.txt
has been successfully submitted by Scott Rose and posted to the
IETF repository.

Name:        draft-srose-dkim-ecc
Revision:    00
Title:        Defining Elliptic Curve Cryptography Algorithms for use with DKIM
Document date:    2017-04-06
Group:        Individual Submission
Pages:        6
URL:            https://www.ietf.org/internet-drafts/draft-srose-dkim-ecc-00.txt
Status:         https://datatracker.ietf.org/doc/draft-srose-dkim-ecc/
Htmlized:       https://tools.ietf.org/html/draft-srose-dkim-ecc-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-srose-dkim-ecc-00


Abstract:
   DomainKeys Identified Mail (DKIM) uses digital signature to associate
   a message with a given sending domain.  Currently, there is only one
   cryptography algorithm defined for use with DKIM (RSA).  This
   document defines four new elliptic curve cryptography algorithms for
   use with DKIM.  This will allow for algorithm agility if a weakness
   is found in RSA, and allows for smaller key length to provide the
   same digital signature strength.

                                                                                 

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.

The IETF Secretariat

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


--
Vladimir Dubrovin
@Mail.Ru
--------------D186BDF95006EE9D0565A5D3 Content-Type: image/png; name="oaifenhidjgmdknc.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="oaifenhidjgmdknc.png" iVBORw0KGgoAAAANSUhEUgAAAHwAAAAZCAQAAABZLoLcAAADz0lEQVR4AeWX2XLiPBCFP3nB 7IEAWSAk4BkWg837P95UuU51WRhXjf1XcjH/8Y2EpO7+tLQQd3JM2XDgwo2CCylvDPkJOVIK PgCYknMm4YfkWJBxe/AdmPLd6ssXwL4svfAjSvhdQc3JuHjwXwR8p3ryC/CrLL/yAxpxFWDK nB6lCBiztpYjEd+pKe+Mfha8L7gzY+oKeTf0ABOOgaanT99rSRgS8lgBCQMirK+VAwa41uCO xMaF9GlmDIHID+WskxypyzspB/a8EEOpCXnZ5wNMB25s2VBok74TAAtZK9gS4WtCqt43TqwI eC57DgHHqTxQbcATPhXXDojKw7nhgcqlu97H81YOzYiBgA/vZOcsSdgxZ6yQB1AqfpgEU69+ pgdSyK7W/8wRIVpyC/4a/JXCLF2BsWw+kPxMqSjUnD0BgVzeyDja2b5QmtMEfVaTkbnNfSSr /7JdZamTwu8txIHK4V+CbyrjMxbtwZ+1VgAfKg/VNuaI1samqCDwwC/MgICdYa0IcBbYQJaV OpW+Yq1XV/C5xTXDAbQH/yp/WpjrEwGYQo4Vc59leeKBj8Grv6jutK7Pto3vz9+QvCN4oP8b vwkBOoErFSXABmtsMLfA0Ay0h6T69M7yElhrJzl8PXcEn+k4xdAdvChNoMYcx72uZm6qdWsL fipLc+7luHYC/7Q4uoMrOQBlEjs1DDpXTG9bgxfaVXXtu4ArUc7+O/gVtC4ZdZ3N3JPu8m7g MXXtuoALY4yvkZLtI2X1EZm5+6qFZ4ACX5Xlt9bgmVrqOj8ET+WnFbhFFHGvSC1Jfc6ntp5r fH1h4NqYs9bgWz1zqG/OOrj137UC96fR14sOtKdlJagDutokx9q7x7Vl24Ib4IyqQk6PwZXt C/otwV81bkhVA4pHOyjSz/0S5qKL55Ul7wpdsyWzKbQGh73d8oGdSGE/AA+5ymsVLmZC2ATu 3e85C5yW7plceSzkThvBBkCChaMv1cbTY4RxJ/CITO05KTt5aQKHhbVdSBnZZBybwKURBTeB 7km5qlYwoaZI67wnABxLDuqcMgPmlRC30AkceqpXv4JLAzisvcePtTeDSxODtY9cUTUmmaOd DkcIVk7VvsOB5Mqgr7i7k5fU06YU8OYFlTLUw2duL4ETmOZk5hdiCrusdvL0WDFbisrkbolp 1IzCnDwZtGPMkhh44qU2awkr+p7DFSMwhSxqYxxTVqyYEau+YGZJaEkPk/lfKp4RK8FG8tSs kCeWrDCWZo3JvIfegRO5Mv4/rpA3ofrfmv+BAmZsOZBbRl3g+Af1By7rr2XUY4YeAAAAAElF TkSuQmCC --------------D186BDF95006EE9D0565A5D3-- --------------B5ECBF7DD255ACCFC55C5140-- From nobody Thu Apr 6 15:00: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 D3435129684 for ; Thu, 6 Apr 2017 15:00:43 -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 wt-jHGEFS3Zi for ; Thu, 6 Apr 2017 15:00:41 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02080129680 for ; Thu, 6 Apr 2017 15:00:25 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id d2so67405852oig.1 for ; Thu, 06 Apr 2017 15:00:25 -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=8oLkv7LZi/Rmc+E9N5tMV0ozOBlNdlHFsHCacbGZLYQ=; b=NZCTYC/7pfBXGb1YmR2KJ/ro24l/RV/W1omQu+cxHG5/jxyTTQc15UHxQcZGa3n3HV efFlHYM3JKcmHbtuHwxB01COkLK/pgqhyuMwjRAbz0o1Di8gGGWRUa5i12PcX2xfv8zo Vu/YoERAhsM/cfQvGuJUzgieeyHwfe0EhLgdnkTtqCKO0fTeaJyFhwZCpKExjXjNtxa2 Rpd4LsSLdlUgCZJor+PRCCSRK0lfg/1zQyOHXEkPFxIjfVVXx3Nzhy6F4bLJXgEpxOjK 4wtX9oXqubB7Y/y68bzj/fy9H/GErBd0Qo2fMLrkygZ2P+Zy2fF3QqXc5e9oi+UqZ+8G 4NNw== 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=8oLkv7LZi/Rmc+E9N5tMV0ozOBlNdlHFsHCacbGZLYQ=; b=m0nNeMo4504vZW+pLQ7SWUgPKO2nf8OrE5ZlBxSvQEW1aEVSrwDYWqGUTbeV08Rb5v 7OfohnBwY/Dj2x59+0x+zpTbOj4FnKsm0JKELTK+ptoiSinFWWwZJWBNZ8VYPM77/+cQ ykZqYfWUIn8w6JrFJLi5CxMe4+49D1/vKnAh42Rb8eUgRoby71n9FO3aDr0SssL+MYAk 7yJOTqbWNjIXaXvtGvOw06VICYinZqsxIeMpGMBFcGkhqmLsN9GJ/UnOdiKiBcZ8POKP ktbwubwBel8nVzhDbUD9FtY81wMWRKmBfcIRlQio+u6i2XRDx1d57CAkxaRFfUL5Psl3 tUQg== X-Gm-Message-State: AFeK/H32gUTjF7gTUiU2BqPHSLUtTUfEiRnsehd/WZCC7q9nReoWTQVzUbKRvkiAMoqzhYPQ9dj15G9csr5eKi+C X-Received: by 10.202.216.84 with SMTP id p81mr15581377oig.193.1491516024853; Thu, 06 Apr 2017 15:00:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.120.72 with HTTP; Thu, 6 Apr 2017 15:00:24 -0700 (PDT) In-Reply-To: References: <149149960391.22024.11499305209108527807.idtracker@ietfa.amsl.com> From: Brandon Long Date: Thu, 6 Apr 2017 15:00:24 -0700 Message-ID: To: Vladimir Dubrovin Cc: Scott Rose , "dmarc@ietf.org" Content-Type: multipart/related; boundary=001a113d2830d75985054c86a28f Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-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: Thu, 06 Apr 2017 22:00:44 -0000 --001a113d2830d75985054c86a28f Content-Type: multipart/alternative; boundary=001a113d2830d75982054c86a28e --001a113d2830d75982054c86a28e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We also recently discussed having a new DKIM rfc revision to create a registry of algorithms and allowed key lengths, so that we wouldn't need to rev the rfc every time they changed, and also to incorporate into arc, which will use similar signatures. Discussed a bit here: https://www.ietf.org/mail-archive/web/dmarc/current/msg03436.html Brandon On Thu, Apr 6, 2017 at 2:28 PM, Vladimir Dubrovin wrote: > > Hello Scott, > > it may be good to cover compatibility issues, because otherwise there are > little chances to succeed the older but more compatible protocols in > nearest future. The possible (but probably not the best one) solution is= : > > 1. produce 2 different DKIM-Signatures with 2 different selectors: > slector1 with SHA-1 + RSA and selector2 one with SHA-512 + ECDSA > 2. add an additional field to either selector1 DKIM DNS record (need to > consult RFC if it's allowed) or to DKIM-Signature with selector1 (it's > allowed but probably is not enough to protect against downgrade) to > indicate the selector is legacy-only, e.g. o=3Dsha512/eccp256 to indicate > this selector should be ignored if verifier supports sha-512 and eccp256. > > Legacy verifier has valid DKIM-Signature with sha1+rsa > Compatible verifier ignores sha1+rsa and choose sha-512+ECDSA > > I can imagine few more ways to resolve compatibility issues, but this one > seems to be a simplest. > > > 06.04.2017 20:32, Scott Rose =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > This may be of interest to this group, as there isn't an active DKIM WG > anymore. This is my first attempt to produce a draft about defining new > digital algorithms for DKIM. I'm trying to keep this short i.e. only > define a few IANA registry entries and that's it. > > I'm trying to head off a potential issue for organizations that are told > to migrate to ECDSA or looking for algorithm agility that doesn't involve > using SHA-1. > > Comments welcome and needed. Including being told this isn't needed > (though I think it might be). > > Scott Rose > > NIST > > > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-srose-dkim-ecc-00.txt > Date: Thu, 6 Apr 2017 10:26:43 -0700 > From: internet-drafts@ietf.org > To: Scott Rose > > > > A new version of I-D, draft-srose-dkim-ecc-00.txt > has been successfully submitted by Scott Rose and posted to the > IETF repository. > > Name: draft-srose-dkim-ecc > Revision: 00 > Title: Defining Elliptic Curve Cryptography Algorithms for use wit= h > DKIM > Document date: 2017-04-06 > Group: Individual Submission > Pages: 6 > URL: https://www.ietf.org/internet-drafts/draft-srose-dkim-ecc= - > 00.txt > Status: https://datatracker.ietf.org/doc/draft-srose-dkim-ecc/ > Htmlized: https://tools.ietf.org/html/draft-srose-dkim-ecc-00 > Htmlized: https://datatracker.ietf.org/ > doc/html/draft-srose-dkim-ecc-00 > > > Abstract: > DomainKeys Identified Mail (DKIM) uses digital signature to associate > a message with a given sending domain. Currently, there is only one > cryptography algorithm defined for use with DKIM (RSA). This > document defines four new elliptic curve cryptography algorithms for > use with DKIM. This will allow for algorithm agility if a weakness > is found in RSA, and allows for smaller key length to provide the > same digital signature strength. > > > > > 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. > > The IETF Secretariat > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > > > -- > Vladimir Dubrovin > [image: @Mail.Ru] > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --001a113d2830d75982054c86a28e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We also recently discussed having a new DKIM rfc revision = to create a registry of algorithms and allowed key lengths, so that we woul= dn't need to rev the rfc every time they changed, and also to incorpora= te into arc, which will use similar signatures.


Brandon

On Thu, Apr 6, 2017 at 2:28 PM,= Vladimir Dubrovin <dubrovin@corp.mail.ru> wrote:
=20 =20 =20

Hello Scott,

it may be good to cover compatibility issues, because otherwise there are little chances to succeed the older but more compatible protocols in nearest future.=C2=A0 The possible (but probably not the best one) solution is:

1. produce 2 different DKIM-Signatures with 2 different selectors: slector1=C2=A0 with SHA-1 + RSA and selector2 one with=C2=A0 SHA-512 = + ECDSA
2. add an additional field to either selector1 DKIM DNS record (need to consult RFC if it's allowed) or to DKIM-Signature with selector1 (it's allowed but probably is not enough to protect against downgrade) to indicate the selector is legacy-only, e.g. o=3Dsha512/eccp256 to indicate this selector should be ignored if verifier supports sha-512 and eccp256.

Legacy verifier has valid DKIM-Signature with sha1+rsa
Compatible verifier ignores sha1+rsa and choose sha-512+ECDSA

I can imagine few more ways to resolve compatibility issues, but this one seems to be a simplest.


06.04.2017 20:32, Scott Rose =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
This may be of interest to this group, as the= re isn't an active DKIM WG anymore.=C2=A0 This is my first attempt to produce = a draft about defining new digital algorithms for DKIM.=C2=A0 I'm t= rying to keep this short i.e. only define a few IANA registry entries and that's it.

I'm trying to head off a potential issue for organizations that are told to migrate to ECDSA or looking for algorithm agility that doesn't involve using SHA-1.

Comments welcome and needed. Including being told this isn't needed (though I think it might be).

Scott Rose

NIST



-------- Forwarded Message --------
Subject:=C2=A0=C2=A0=C2=A0=C2=A0 New Version Notification for draft-srose-dkim-ecc-00.txt
Date:=C2=A0=C2=A0=C2=A0=C2=A0 Thu, 6 Apr 2017 10:26:43 -0700
From:=C2=A0=C2=A0=C2=A0=C2=A0 internet-drafts@ietf.org
To:=C2=A0=C2=A0=C2=A0=C2=A0 Scott Rose <scott.rose@nist.gov>



A new version of I-D, draft-srose-dkim-ecc-00.txt
has been successfully submitted by Scott Rose and posted to the
IETF repository.

Name:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 draft-srose-dkim-ecc
Revision:=C2=A0=C2=A0=C2=A0 00
Title:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Defining Elliptic Cu= rve Cryptography Algorithms for use with DKIM
Document date:=C2=A0=C2=A0=C2=A0 2017-04-06
Group:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Individual Submissio= n
Pages:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 6
URL:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 https://www.ietf.org/internet-drafts/draft-srose-dkim-ecc-00= .txt
Status:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https= ://datatracker.ietf.org/doc/draft-srose-dkim-ecc/
Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://= tools.ietf.org/html/draft-srose-dkim-ecc-00
Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://datatracker.ietf.org/doc/html/draft-srose-dkim-ecc-00


Abstract:
=C2=A0=C2=A0 DomainKeys Identified Mail (DKIM) uses digital signature= to associate
=C2=A0=C2=A0 a message with a given sending domain.=C2=A0 Currently, = there is only one
=C2=A0=C2=A0 cryptography algorithm defined for use with DKIM (RSA).= =C2=A0 This
=C2=A0=C2=A0 document defines four new elliptic curve cryptography algorithms for
=C2=A0=C2=A0 use with DKIM.=C2=A0 This will allow for algorithm agili= ty if a weakness
=C2=A0=C2=A0 is found in RSA, and allows for smaller key length to pr= ovide the
=C2=A0=C2=A0 same digital signature strength.

=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=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=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=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=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=C2=A0

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.

The IETF Secretariat

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


--
Vladimir Dubrovin
3D"@Mail.Ru=

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


--001a113d2830d75982054c86a28e-- --001a113d2830d75985054c86a28f Content-Type: image/png; name="oaifenhidjgmdknc.png" Content-Disposition: inline; filename="oaifenhidjgmdknc.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: b864544fb1206e3a_0.0.1.1 iVBORw0KGgoAAAANSUhEUgAAAHwAAAAZCAQAAABZLoLcAAADz0lEQVR4AeWX2XLiPBCFP3nB7IEA WSAk4BkWg837P95UuU51WRhXjf1XcjH/8Y2EpO7+tLQQd3JM2XDgwo2CCylvDPkJOVIKPgCYknMm 4YfkWJBxe/AdmPLd6ssXwL4svfAjSvhdQc3JuHjwXwR8p3ryC/CrLL/yAxpxFWDKnB6lCBiztpYj Ed+pKe+Mfha8L7gzY+oKeTf0ABOOgaanT99rSRgS8lgBCQMirK+VAwa41uCOxMaF9GlmDIHID+Ws kxypyzspB/a8EEOpCXnZ5wNMB25s2VBok74TAAtZK9gS4WtCqt43TqwIeC57DgHHqTxQbcATPhXX DojKw7nhgcqlu97H81YOzYiBgA/vZOcsSdgxZ6yQB1AqfpgEU69+pgdSyK7W/8wRIVpyC/4a/JXC LF2BsWw+kPxMqSjUnD0BgVzeyDja2b5QmtMEfVaTkbnNfSSr/7JdZamTwu8txIHK4V+CbyrjMxbt wZ+1VgAfKg/VNuaI1samqCDwwC/MgICdYa0IcBbYQJaVOpW+Yq1XV/C5xTXDAbQH/yp/WpjrEwGY Qo4Vc59leeKBj8Grv6jutK7Pto3vz9+QvCN4oP8bvwkBOoErFSXABmtsMLfA0Ay0h6T69M7yElhr Jzl8PXcEn+k4xdAdvChNoMYcx72uZm6qdWsLfipLc+7luHYC/7Q4uoMrOQBlEjs1DDpXTG9bgxfa VXXtu4ArUc7+O/gVtC4ZdZ3N3JPu8m7gMXXtuoALY4yvkZLtI2X1EZm5+6qFZ4ACX5Xlt9bgmVrq Oj8ET+WnFbhFFHGvSC1Jfc6ntp5rfH1h4NqYs9bgWz1zqG/OOrj137UC96fR14sOtKdlJagDutok x9q7x7Vl24Ib4IyqQk6PwZXtC/otwV81bkhVA4pHOyjSz/0S5qKL55Ul7wpdsyWzKbQGh73d8oGd SGE/AA+5ymsVLmZC2ATu3e85C5yW7plceSzkThvBBkCChaMv1cbTY4RxJ/CITO05KTt5aQKHhbVd SBnZZBybwKURBTeB7km5qlYwoaZI67wnABxLDuqcMgPmlRC30AkceqpXv4JLAzisvcePtTeDSxOD tY9cUTUmmaOdDkcIVk7VvsOB5Mqgr7i7k5fU06YU8OYFlTLUw2duL4ETmOZk5hdiCrusdvL0WDFb isrkbolp1IzCnDwZtGPMkhh44qU2awkr+p7DFSMwhSxqYxxTVqyYEau+YGZJaEkPk/lfKp4RK8FG 8tSskCeWrDCWZo3JvIfegRO5Mv4/rpA3ofrfmv+BAmZsOZBbRl3g+Af1By7rr2XUY4YeAAAAAElF TkSuQmCC --001a113d2830d75985054c86a28f-- From nobody Thu Apr 6 16:56: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 359291296BC for ; Thu, 6 Apr 2017 16:56:05 -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 DHjoKlCcv12B for ; Thu, 6 Apr 2017 16:56:03 -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 7EE701296A8 for ; Thu, 6 Apr 2017 16:56:03 -0700 (PDT) Received: (qmail 31264 invoked from network); 6 Apr 2017 23:56:02 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 6 Apr 2017 23:56:02 -0000 Date: 6 Apr 2017 23:55:40 -0000 Message-ID: <20170406235540.47811.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org Cc: scott.rose@nist.gov 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] Fwd: New Version Notification for draft-srose-dkim-ecc-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: Thu, 06 Apr 2017 23:56:05 -0000 In article you write: >This may be of interest to this group, as there isn't an active DKIM WG >anymore. At the DISPATCH session at IETF 98 I pitched a proposal to update DKIM with a new crypto algorithm and/or a more compact key representation (put the key in the signature and put a hash of it in the DNS.) Reaction was positive, people told me to write a proposed charter, which starts here: https://www.ietf.org/mail-archive/web/dispatch/current/msg06701.html Also see: https://datatracker.ietf.org/doc/draft-levine-dcrup-dkim-crypto/ R's, John From nobody Thu Apr 6 16:58: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 826E9129631 for ; Thu, 6 Apr 2017 16:58:44 -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 qcDhlwdZBqWm for ; Thu, 6 Apr 2017 16:58:43 -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 9445E1296C1 for ; Thu, 6 Apr 2017 16:58:41 -0700 (PDT) Received: (qmail 31636 invoked from network); 6 Apr 2017 23:58:37 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 6 Apr 2017 23:58:37 -0000 Date: 6 Apr 2017 23:58:15 -0000 Message-ID: <20170406235815.47843.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org Cc: dubrovin@corp.mail.ru 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] Fwd: New Version Notification for draft-srose-dkim-ecc-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: Thu, 06 Apr 2017 23:58:44 -0000 >1. produce 2 different DKIM-Signatures with 2 different selectors: >slector1 with SHA-1 + RSA and selector2 one with SHA-512 + ECDSA Of course. >2. add an additional field to either selector1 DKIM DNS record (need to >consult RFC if it's allowed) or to DKIM-Signature with selector1 (it's >allowed but probably is not enough to protect against downgrade) to >indicate the selector is legacy-only, e.g. o=sha512/eccp256 to indicate >this selector should be ignored if verifier supports sha-512 and eccp256. No. If the verifier is smart enough to understand new algorithms, it is smart enough to figure out which signature to prefer. Also keep in mind that the legacy crypto is sha256/rsa1024 which is plenty strong for the forseeable future. R's, John From nobody Fri Apr 7 00:28: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 E038C1287A5 for ; Fri, 7 Apr 2017 00:28:44 -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 XbX9S-r3Xcju for ; Fri, 7 Apr 2017 00:28:42 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86E98126C25 for ; Fri, 7 Apr 2017 00:28:42 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id b187so77323475oif.0 for ; Fri, 07 Apr 2017 00:28:42 -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=CwnDnUxiO4q12vHT0b6sx9ajFyFAcWkB8zr6F7h7RcI=; b=e6QOwCSuKKhgO5f3TzD8hWf92p+PAeVmhg5src2d5SiqJ4OsRgmrgV1mf38rmuaEPf QKgV+gPzvQInorgh1ojruiUAhImnGRCoD47C+7NWMkuUFqaYvUjWHkLvlnVmLSYCVfFy jUeRGllegciRYT3VkqtBgaJxJgAv3CCrIPYqPV6i1lKAQmXmMhIIcm2P7q9RcSqQmIMB NpjLKgrsVipcQocgN3Wfk5C7/DzBRNrSUyWqNOrfMzKG6e/91UPdTgBK+XoESid3vLO0 bs8KlCHbW98koRpoZ+ka4BAVeLdIgMKmO5dtEeWC+tScP0FLwAjtt//e6BZ0D/ZgpWat trHw== 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=CwnDnUxiO4q12vHT0b6sx9ajFyFAcWkB8zr6F7h7RcI=; b=J07weXloWlghnCZCkvcTpmR5E353eil9uAIv5y+M5AFNElLKgIlb4zPbJBOYJFS5me a9zKmvRquBmB8mfR9gJ5JgOR108PcpTdlMWRoThvZ74uR5KokBZGgN+HMObPIPu3t1xC AB5GTX/pBFxvOLAwc179wlJqjqipveijeAI52bmroaQRKPadLfecDA7nkuuB8y9uo5/r r/EqmylOhbILm2cb1jaFGppXVE+ZweuMrXehl4/Thr9cNMU6KLu7g+qRuCu9ZuIvYm92 HiDJhTP+QDDVSMZvo/Ff85InrqlE9SKDYxP+k3O5oTjftjunUUQMz5En8demIL5Sql1z VyhQ== X-Gm-Message-State: AFeK/H1g7Lj4e26qqkD7HdlWtW6nHUTPIhmx01HyYbozC1iWTKrORGyKV3XF76b4SMDQ6+D5Fb2FBk1l9gCP8NOp X-Received: by 10.157.17.78 with SMTP id p14mr24161726otp.222.1491550121420; Fri, 07 Apr 2017 00:28:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.120.72 with HTTP; Fri, 7 Apr 2017 00:28:40 -0700 (PDT) In-Reply-To: <20170406235815.47843.qmail@ary.lan> References: <20170406235815.47843.qmail@ary.lan> From: Brandon Long Date: Fri, 7 Apr 2017 00:28:40 -0700 Message-ID: To: John Levine Cc: "dmarc@ietf.org" , Vladimir Dubrovin Content-Type: multipart/alternative; boundary=001a1145c770274a50054c8e930b Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-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, 07 Apr 2017 07:28:45 -0000 --001a1145c770274a50054c8e930b Content-Type: text/plain; charset=UTF-8 Should we add more hash algorithms? Also, I'm very unclear of the benefit of the fp versions, adding nearly 400 bytes per signature to the message seems expensive, and in the arc case, an extra 800 bytes per hop (nearly doubling the size of each hop) seems like an odd compromise. Maybe I'm being silly. I know that many of the sending providers now provide the DNS directly for DKIM keys, and so the end user domain only needs to put in CNAMEs, given the need to rotate keys, that may be the more sane thing than expecting anyone to routinely copy the large keys into DNS. Brandon On Thu, Apr 6, 2017 at 4:58 PM, John Levine wrote: > >1. produce 2 different DKIM-Signatures with 2 different selectors: > >slector1 with SHA-1 + RSA and selector2 one with SHA-512 + ECDSA > > Of course. > > >2. add an additional field to either selector1 DKIM DNS record (need to > >consult RFC if it's allowed) or to DKIM-Signature with selector1 (it's > >allowed but probably is not enough to protect against downgrade) to > >indicate the selector is legacy-only, e.g. o=sha512/eccp256 to indicate > >this selector should be ignored if verifier supports sha-512 and eccp256. > > No. If the verifier is smart enough to understand new algorithms, it > is smart enough to figure out which signature to prefer. Also keep in > mind that the legacy crypto is sha256/rsa1024 which is plenty strong > for the forseeable future. > > R's, > John > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --001a1145c770274a50054c8e930b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Should we add more hash algorithms?

Also, I'm very unclear of the benefit of the fp versions, addin= g nearly 400 bytes per signature to the message seems expensive, and in the= arc case, an extra 800 bytes per hop (nearly doubling the size of each hop= ) seems like an odd compromise.=C2=A0 Maybe I'm being silly.
=
I know that many of the sending providers now provide the DN= S directly for DKIM keys, and so the end user domain only needs to put in C= NAMEs, given the need to rotate keys, that may be the more sane thing than = expecting anyone to routinely copy the large keys into DNS.

<= /div>
Brandon

On Thu, Apr 6, 2017 at 4:58 PM, John Levine &= lt;johnl@taugh.com= > wrote:
>1= . produce 2 different DKIM-Signatures with 2 different selectors:
>slector1=C2=A0 with SHA-1 + RSA and selector2 one with=C2=A0 SHA-512 + = ECDSA

Of course.

>2. add an additional field to either selector1 DKIM DNS record (need to=
>consult RFC if it's allowed) or to DKIM-Signature with selector1 (i= t's
>allowed but probably is not enough to protect against downgrade) to
>indicate the selector is legacy-only, e.g. o=3Dsha512/eccp256 to indica= te
>this selector should be ignored if verifier supports sha-512 and eccp25= 6.

No.=C2=A0 If the verifier is smart enough to understand new algorith= ms, it
is smart enough to figure out which signature to prefer.=C2=A0 Also keep in=
mind that the legacy crypto is sha256/rsa1024 which is plenty strong
for the forseeable future.

R's,
John

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

--001a1145c770274a50054c8e930b-- From nobody Fri Apr 7 02:07: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 5B59E12704A for ; Fri, 7 Apr 2017 02:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.721 X-Spam-Level: X-Spam-Status: No, score=-1.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=corp.mail.ru 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 EVNWAG5kRw7k for ; Fri, 7 Apr 2017 02:07:01 -0700 (PDT) Received: from f391.i.mail.ru (f391.i.mail.ru [185.5.136.62]) (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 2C730127011 for ; Fri, 7 Apr 2017 02:07:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=corp.mail.ru; s=mail; h=References:In-Reply-To:Content-Type:Message-ID:Reply-To:Date:MIME-Version:Subject:Cc:To:From; bh=WTY64L3WC2lLMwXLV3pBSFZeYsmE0SHs9/b6zoMMvVs=; b=K7KIXR2D0ebc2QUj+wQhoPK0DA5XkIkO0NCUURDKDV33tPLd84McjW8GY+/0g5oOl59guCT9u3+lc7FLxF1EncHBCe5rVnP59hfH0j4JY1sMeQvNU/FxQckkWwomFgIvAI82DOWcm+WtVtMOHtzMCoGncJd9GxKawhnzaioHpG8=; Received: by f391.i.mail.ru with local (envelope-from ) id 1cwPr6-0006wo-Vf; Fri, 07 Apr 2017 12:06:57 +0300 Received: by e.mail.ru with HTTP; Fri, 07 Apr 2017 12:06:56 +0300 From: =?UTF-8?B?VmxhZGltaXIgRHVicm92aW4=?= To: =?UTF-8?B?Sm9obiBMZXZpbmU=?= Cc: dmarc@ietf.org MIME-Version: 1.0 X-Mailer: Mail.Ru Mailer 1.0 Date: Fri, 07 Apr 2017 12:06:56 +0300 Reply-To: =?UTF-8?B?VmxhZGltaXIgRHVicm92aW4=?= X-Priority: 3 (Normal) Message-ID: <1491556016.525223113@f391.i.mail.ru> Content-Type: multipart/alternative; boundary="--ALT--47aaa2521491556016" Authentication-Results: f391.i.mail.ru; auth=pass smtp.auth=dubrovin@corp.mail.ru smtp.mailfrom=dubrovin@corp.mail.ru X-7FA49CB5: 0D63561A33F958A5231C6AF64D022CC3B791D773EF6FB32F69111549802E81C39F18ECD7E95F35E929AFE063DF4C541CDFC466952B044E4C1AB4C9766DADF68A0BF2EBBBDD9D6B0F5586FE1C725613FD X-Mailru-Sender: CE01F6F06FBB9B4E41592D96479AE6441C3AEB5FB1E612D0FAF806B776C0F965C245D68BECE010C39766F80D43A7B361D19CFE17E46A923CCDCEB298E575E7B28BC0F606C687C5A1CBBBE6D6265783EC7D8C8258277D05C30D4ABDE8C577C2ED X-Mras: OK X-Spam: undefined In-Reply-To: <20170406235815.47843.qmail@ary.lan> References: <20170406235815.47843.qmail@ary.lan> Archived-At: Subject: Re: [dmarc-ietf] =?utf-8?q?Fwd=3A_New_Version_Notification_for_draft?= =?utf-8?q?-srose-dkim-ecc-00=2Etxt?= 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, 07 Apr 2017 09:07:04 -0000 ----ALT--47aaa2521491556016 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 CldpdGhvdXQgbWFya2luZyB0aGUgcHVibGlzaGVkIGtleSBhcyBvYnNvbGV0ZSwgZG93bmdyYWRl IGF0dGFjayBpcyBwb3NzaWJsZSwgYmVjYXVzZSBhdHRhY2tlciBjYW4gc3RpbGwgdXNlIGEgd2Vh a2VyIGtleSB0byBzcG9vZiBzaWduYXR1cmUuINC/0Y/RgtC90LjRhtCwLCAwNyDQsNC/0YDQtdC7 0Y8gMjAxN9CzLiwgMDI6NTggKzAzOjAwINC+0YIgSm9obiBMZXZpbmUgIGpvaG5sQHRhdWdoLmNv bSA6Cgo+PjEuIHByb2R1Y2UgMiBkaWZmZXJlbnQgREtJTS1TaWduYXR1cmVzIHdpdGggMiBkaWZm ZXJlbnQgc2VsZWN0b3JzOgo+PnNsZWN0b3IxICB3aXRoIFNIQS0xICsgUlNBIGFuZCBzZWxlY3Rv cjIgb25lIHdpdGggIFNIQS01MTIgKyBFQ0RTQQo+Cj5PZiBjb3Vyc2UuCj4KPj4yLiBhZGQgYW4g YWRkaXRpb25hbCBmaWVsZCB0byBlaXRoZXIgc2VsZWN0b3IxIERLSU0gRE5TIHJlY29yZCAobmVl ZCB0bwo+PmNvbnN1bHQgUkZDIGlmIGl0J3MgYWxsb3dlZCkgb3IgdG8gREtJTS1TaWduYXR1cmUg d2l0aCBzZWxlY3RvcjEgKGl0J3MKPj5hbGxvd2VkIGJ1dCBwcm9iYWJseSBpcyBub3QgZW5vdWdo IHRvIHByb3RlY3QgYWdhaW5zdCBkb3duZ3JhZGUpIHRvCj4+aW5kaWNhdGUgdGhlIHNlbGVjdG9y IGlzIGxlZ2FjeS1vbmx5LCBlLmcuIG89c2hhNTEyL2VjY3AyNTYgdG8gaW5kaWNhdGUKPj50aGlz IHNlbGVjdG9yIHNob3VsZCBiZSBpZ25vcmVkIGlmIHZlcmlmaWVyIHN1cHBvcnRzIHNoYS01MTIg YW5kIGVjY3AyNTYuCj4KPk5vLiAgSWYgdGhlIHZlcmlmaWVyIGlzIHNtYXJ0IGVub3VnaCB0byB1 bmRlcnN0YW5kIG5ldyBhbGdvcml0aG1zLCBpdAo+aXMgc21hcnQgZW5vdWdoIHRvIGZpZ3VyZSBv dXQgd2hpY2ggc2lnbmF0dXJlIHRvIHByZWZlci4gIEFsc28ga2VlcCBpbgo+bWluZCB0aGF0IHRo ZSBsZWdhY3kgY3J5cHRvIGlzIHNoYTI1Ni9yc2ExMDI0IHdoaWNoIGlzIHBsZW50eSBzdHJvbmcK PmZvciB0aGUgZm9yc2VlYWJsZSBmdXR1cmUuCj4KPlIncywKPkpvaG4K ----ALT--47aaa2521491556016 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 CjxIVE1MPjxCT0RZPjxwIHN0eWxlPSdtYXJnaW4tdG9wOiAwcHg7JyBkaXI9Imx0ciI+PC9wPgo8 cCBkaXI9Imx0ciI+V2l0aG91dCBtYXJraW5nIHRoZSBwdWJsaXNoZWQga2V5IGFzIG9ic29sZXRl LCBkb3duZ3JhZGUgYXR0YWNrIGlzIHBvc3NpYmxlLCBiZWNhdXNlIGF0dGFja2VyIGNhbiBzdGls bCB1c2UgYSB3ZWFrZXIga2V5IHRvIHNwb29mIHNpZ25hdHVyZS48L3A+CtC/0Y/RgtC90LjRhtCw LCAwNyDQsNC/0YDQtdC70Y8gMjAxN9CzLiwgMDI6NTggKzAzOjAwINC+0YIgSm9obiBMZXZpbmUg PGEgaHJlZj0ibWFpbHRvOmpvaG5sQHRhdWdoLmNvbSI+am9obmxAdGF1Z2guY29tPC9hPjo8YnI+ PGJyPjxibG9ja3F1b3RlIGlkPSJtYWlsLWFwcC1hdXRvLXF1b3RlIiBzdHlsZT0iYm9yZGVyLWxl ZnQ6MXB4IHNvbGlkICMwODU3QTY7IG1hcmdpbjowcHggMHB4IDBweCAxMHB4OyBwYWRkaW5nOjBw eCAwcHggMHB4IDEwcHg7IiBjaXRlPSIxNDkxNTIzMTI4MDAwMDAwMDE4NyI+CgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoJCgoKCgoKCgoKCgoKCjxkaXYgY2xhc3M9ImpzLWhlbHBlciBqcy1yZWFkbXNn LW1zZyI+Cgk8c3R5bGUgdHlwZT0idGV4dC9jc3MiPjwvc3R5bGU+CiAJPGRpdiA+CgkJPGJhc2Ug dGFyZ2V0PSJfc2VsZiIgaHJlZj0iaHR0cHM6Ly9lLm1haWwucnUvIiAvPgoJCQogICAgICAgICAg ICA8ZGl2IGlkPSJzdHlsZV8xNDkxNTIzMTI4MDAwMDAwMDE4N19CT0RZIj4mZ3Q7MS4gcHJvZHVj ZSAyIGRpZmZlcmVudCBES0lNLVNpZ25hdHVyZXMgd2l0aCAyIGRpZmZlcmVudCBzZWxlY3RvcnM6 PGJyPgomZ3Q7c2xlY3RvcjEgIHdpdGggU0hBLTEgKyBSU0EgYW5kIHNlbGVjdG9yMiBvbmUgd2l0 aCAgU0hBLTUxMiArIEVDRFNBPGJyPgo8YnI+Ck9mIGNvdXJzZS48YnI+Cjxicj4KJmd0OzIuIGFk ZCBhbiBhZGRpdGlvbmFsIGZpZWxkIHRvIGVpdGhlciBzZWxlY3RvcjEgREtJTSBETlMgcmVjb3Jk IChuZWVkIHRvPGJyPgomZ3Q7Y29uc3VsdCBSRkMgaWYgaXQmYXBvcztzIGFsbG93ZWQpIG9yIHRv IERLSU0tU2lnbmF0dXJlIHdpdGggc2VsZWN0b3IxIChpdCZhcG9zO3M8YnI+CiZndDthbGxvd2Vk IGJ1dCBwcm9iYWJseSBpcyBub3QgZW5vdWdoIHRvIHByb3RlY3QgYWdhaW5zdCBkb3duZ3JhZGUp IHRvPGJyPgomZ3Q7aW5kaWNhdGUgdGhlIHNlbGVjdG9yIGlzIGxlZ2FjeS1vbmx5LCBlLmcuIG89 c2hhNTEyL2VjY3AyNTYgdG8gaW5kaWNhdGU8YnI+CiZndDt0aGlzIHNlbGVjdG9yIHNob3VsZCBi ZSBpZ25vcmVkIGlmIHZlcmlmaWVyIHN1cHBvcnRzIHNoYS01MTIgYW5kIGVjY3AyNTYuPGJyPgo8 YnI+Ck5vLiAgSWYgdGhlIHZlcmlmaWVyIGlzIHNtYXJ0IGVub3VnaCB0byB1bmRlcnN0YW5kIG5l dyBhbGdvcml0aG1zLCBpdDxicj4KaXMgc21hcnQgZW5vdWdoIHRvIGZpZ3VyZSBvdXQgd2hpY2gg c2lnbmF0dXJlIHRvIHByZWZlci4gIEFsc28ga2VlcCBpbjxicj4KbWluZCB0aGF0IHRoZSBsZWdh Y3kgY3J5cHRvIGlzIHNoYTI1Ni9yc2ExMDI0IHdoaWNoIGlzIHBsZW50eSBzdHJvbmc8YnI+CmZv ciB0aGUgZm9yc2VlYWJsZSBmdXR1cmUuPGJyPgo8YnI+ClImYXBvcztzLDxicj4KSm9objxicj4K PC9kaXY+CiAgICAgICAgICAgIAogICAgICAgIAoJCTxiYXNlIHRhcmdldD0iX3NlbGYiIGhyZWY9 Imh0dHBzOi8vZS5tYWlsLnJ1LyIgLz4KCTwvZGl2PgoKCQo8L2Rpdj4KCgo8L2Jsb2NrcXVvdGU+ PC9CT0RZPjwvSFRNTD4K ----ALT--47aaa2521491556016-- From nobody Fri Apr 7 03:19: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 4E9DC129436 for ; Fri, 7 Apr 2017 03:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RdtgdOcn2UqQ for ; Fri, 7 Apr 2017 03:18:59 -0700 (PDT) Received: from mail3.informatica.it (mail3.informatica.it [151.99.189.163]) by ietfa.amsl.com (Postfix) with ESMTP id 9A15A127A91 for ; Fri, 7 Apr 2017 03:18:58 -0700 (PDT) To: dmarc@ietf.org References: <20170406235815.47843.qmail@ary.lan> <1491556016.525223113@f391.i.mail.ru> From: Federico Santandrea Message-ID: <30f3baa9-f13b-91b4-c931-a2fb6858243a@diennea.com> Date: Fri, 7 Apr 2017 12:18:52 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1491556016.525223113@f391.i.mail.ru> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-GatewayId: federico.santandrea=2.584357330016061233131705@diennea.com Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-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, 07 Apr 2017 10:19:01 -0000 I agree that to avoid downgrade attacks there has to be a way to mark a key as obsolete in the DNS, meaning: "don't use this key if you know what this means". But I don't see a need to explicitly put another algorithm name in the field. For example, let's say an obsolete record can be marked with just "o=1" to say it should only be considered by legacy verifiers who don't know better. A new resolver would only consider keys that are NOT marked as obsolete, and ignore the others. So if a message is only signed with keys marked as obsolete (downgrade scenario), legacy verifiers would pass, while new ones wouldn't. Another thought: If we want to put a meaningful value in this new field, I think it would be more useful to make it the time since when the key was obsoleted, this would allow for mail dated before that moment (which was correctly signed only with then-not-obsolete keys) to pass verification. This should be optional, so one could choose if he rather have some valid mail fail verification, or risk some invalid back-dated mail pass verification. -- Federico On 07/04/2017 11:06, Vladimir Dubrovin wrote: > Without marking the published key as obsolete, downgrade attack is > possible, because attacker can still use a weaker key to spoof > signature. > > Đ¿ÑÑ‚Đ½Đ¸Ñ†Đ°, 07 Đ°Đ¿Ñ€ĐµĐ»Ñ 2017Đ³., 02:58 +03:00 Đ¾Ñ‚ John Levine > johnl@taugh.com : > >> 1. produce 2 different DKIM-Signatures with 2 different selectors: >> slector1 with SHA-1 + RSA and selector2 one with SHA-512 + ECDSA > > Of course. > >> 2. add an additional field to either selector1 DKIM DNS record >> (need to consult RFC if it's allowed) or to DKIM-Signature with >> selector1 (it's allowed but probably is not enough to protect >> against downgrade) to indicate the selector is legacy-only, e.g. >> o=sha512/eccp256 to indicate this selector should be ignored if >> verifier supports sha-512 and > eccp256. > > No. If the verifier is smart enough to understand new algorithms, it > is smart enough to figure out which signature to prefer. Also keep > in mind that the legacy crypto is sha256/rsa1024 which is plenty > strong for the forseeable future. > > R's, John > From nobody Fri Apr 7 05:09:42 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 358B0127342 for ; Fri, 7 Apr 2017 05:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6uRmqyAIIJez for ; Fri, 7 Apr 2017 05:09:38 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [IPv6:2610:20:6005:13::150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66BAC12778D for ; Fri, 7 Apr 2017 05:09:38 -0700 (PDT) Received: from WSGHUB2.xchange.nist.gov (129.6.42.35) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 7 Apr 2017 08:09:24 -0400 Received: from postmark.nist.gov (129.6.16.94) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.3.319.2; Fri, 7 Apr 2017 08:09:36 -0400 Received: from had3.antd.nist.gov ([129.6.141.200]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id v37C9Nw3000688; Fri, 7 Apr 2017 08:09:23 -0400 To: Vladimir Dubrovin , "dmarc@ietf.org" References: <149149960391.22024.11499305209108527807.idtracker@ietfa.amsl.com> From: Scott Rose Message-ID: <6af0bc7b-1ec4-9e87-557b-51d86046842c@nist.gov> Date: Fri, 7 Apr 2017 08:09:23 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; 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: 8bit X-NIST-MailScanner-Information: Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-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, 07 Apr 2017 12:09:41 -0000 On 04/06/2017 05:28 PM, Vladimir Dubrovin wrote: > > Hello Scott, > > it may be good to cover compatibility issues, because otherwise there > are little chances to succeed the older but more compatible protocols > in nearest future. The possible (but probably not the best one) > solution is: > > 1. produce 2 different DKIM-Signatures with 2 different selectors: > slector1 with SHA-1 + RSA and selector2 one with SHA-512 + ECDSA > 2. add an additional field to either selector1 DKIM DNS record (need > to consult RFC if it's allowed) or to DKIM-Signature with selector1 > (it's allowed but probably is not enough to protect against downgrade) > to indicate the selector is legacy-only, e.g. o=sha512/eccp256 to > indicate this selector should be ignored if verifier supports sha-512 > and eccp256. > > Legacy verifier has valid DKIM-Signature with sha1+rsa > Compatible verifier ignores sha1+rsa and choose sha-512+ECDSA > Something similar was proposed in the DANE WG, but was not included because it isn't up to the sender to tell the receiver which algorithms to support - the receiver (likely) has its own list of approved or preferred algorithms from which to do validation. Some text could be added to the validation section about how validators should select their strongest preferred algorithm, etc. but not specify "legacy" algorithms unless there is clear consensus to get rid of it for DKIM. Scott > I can imagine few more ways to resolve compatibility issues, but this > one seems to be a simplest. > > > 06.04.2017 20:32, Scott Rose Đ¿Đ¸ÑˆĐµÑ‚: >> This may be of interest to this group, as there isn't an active DKIM >> WG anymore. This is my first attempt to produce a draft about >> defining new digital algorithms for DKIM. I'm trying to keep this >> short i.e. only define a few IANA registry entries and that's it. >> >> I'm trying to head off a potential issue for organizations that are >> told to migrate to ECDSA or looking for algorithm agility that >> doesn't involve using SHA-1. >> >> Comments welcome and needed. Including being told this isn't needed >> (though I think it might be). >> >> Scott Rose >> >> NIST >> >> >> >> -------- Forwarded Message -------- >> Subject: New Version Notification for draft-srose-dkim-ecc-00.txt >> Date: Thu, 6 Apr 2017 10:26:43 -0700 >> From: internet-drafts@ietf.org >> To: Scott Rose >> >> >> >> A new version of I-D, draft-srose-dkim-ecc-00.txt >> has been successfully submitted by Scott Rose and posted to the >> IETF repository. >> >> Name: draft-srose-dkim-ecc >> Revision: 00 >> Title: Defining Elliptic Curve Cryptography Algorithms for use >> with DKIM >> Document date: 2017-04-06 >> Group: Individual Submission >> Pages: 6 >> URL: https://www.ietf.org/internet-drafts/draft-srose-dkim-ecc-00.txt >> Status: https://datatracker.ietf.org/doc/draft-srose-dkim-ecc/ >> Htmlized: https://tools.ietf.org/html/draft-srose-dkim-ecc-00 >> Htmlized: https://datatracker.ietf.org/doc/html/draft-srose-dkim-ecc-00 >> >> >> Abstract: >> DomainKeys Identified Mail (DKIM) uses digital signature to associate >> a message with a given sending domain. Currently, there is only one >> cryptography algorithm defined for use with DKIM (RSA). This >> document defines four new elliptic curve cryptography algorithms for >> use with DKIM. This will allow for algorithm agility if a weakness >> is found in RSA, and allows for smaller key length to provide the >> same digital signature strength. >> >> >> >> 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. >> >> The IETF Secretariat >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc > > > -- > Vladimir Dubrovin > @Mail.Ru From nobody Fri Apr 7 05:17: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 AC4B712943E for ; Fri, 7 Apr 2017 05:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2NaGBcaFF1x for ; Fri, 7 Apr 2017 05:17:29 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [IPv6:2610:20:6005:13::151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91414129434 for ; Fri, 7 Apr 2017 05:17:29 -0700 (PDT) Received: from WSGHUB2.xchange.nist.gov (129.6.42.35) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 7 Apr 2017 08:17:16 -0400 Received: from postmark.nist.gov (129.6.16.94) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.3.319.2; Fri, 7 Apr 2017 08:17:27 -0400 Received: from had3.antd.nist.gov ([129.6.141.200]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id v37CHBpJ001191; Fri, 7 Apr 2017 08:17:11 -0400 To: John Levine , References: <20170406235540.47811.qmail@ary.lan> From: Scott Rose Message-ID: Date: Fri, 7 Apr 2017 08:17:11 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170406235540.47811.qmail@ary.lan> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner-Information: Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-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, 07 Apr 2017 12:17:31 -0000 Ok - nice to know I'm not the only one thinking this (means I'm not totally crazy). I'm willing to drop my draft and just contribute/review this one. There is no reason to have multiple drafts trying to do the same thing. Scott On 04/06/2017 07:55 PM, John Levine wrote: > In article you write: >> This may be of interest to this group, as there isn't an active DKIM WG >> anymore. > At the DISPATCH session at IETF 98 I pitched a proposal to update DKIM > with a new crypto algorithm and/or a more compact key representation > (put the key in the signature and put a hash of it in the DNS.) > > Reaction was positive, people told me to write a proposed charter, > which starts here: > > https://www.ietf.org/mail-archive/web/dispatch/current/msg06701.html > > Also see: > > https://datatracker.ietf.org/doc/draft-levine-dcrup-dkim-crypto/ > > R's, > John From nobody Fri Apr 7 07:24:15 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 2706D124B0A for ; Fri, 7 Apr 2017 07:24:14 -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_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=corp.mail.ru 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 9QwpC2hHWI5D for ; Fri, 7 Apr 2017 07:24:10 -0700 (PDT) Received: from smtp58.i.mail.ru (smtp58.i.mail.ru [217.69.128.38]) (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 A05E5120227 for ; Fri, 7 Apr 2017 07:24:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=corp.mail.ru; s=mail; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=Md0A/KSk4CbI7XZ/s8mUe9iLmQg8ERgA6EAN2fSWQCM=; b=sAknM+OT5EaaQcuzroUwtCp0zR5wr2AFkPhP1Ux4B/kUOhB28mAkmF6vyPjftfDNni4ABdb6RH8HSSSG7Gs0eugnkBfAaOEFxdRMzAYi2YTVEH9+eXTjWtAAcsF3DyKC0+og8da08/3LWYfrkSvRMfnQAGGpLB0iyUxP/4rNAlk=; Received: from [178.22.89.88] (port=23194 helo=[127.0.0.1]) by smtp58.i.mail.ru with esmtpa (envelope-from ) id 1cwUo3-0002zd-32; Fri, 07 Apr 2017 17:24:07 +0300 To: Scott Rose , "dmarc@ietf.org" References: <149149960391.22024.11499305209108527807.idtracker@ietfa.amsl.com> <6af0bc7b-1ec4-9e87-557b-51d86046842c@nist.gov> From: Vladimir Dubrovin Message-ID: Date: Fri, 7 Apr 2017 17:24:03 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <6af0bc7b-1ec4-9e87-557b-51d86046842c@nist.gov> Content-Type: multipart/alternative; boundary="------------8E84B5498839DCAD3FC753D7" Authentication-Results: smtp58.i.mail.ru; auth=pass smtp.auth=dubrovin@corp.mail.ru smtp.mailfrom=dubrovin@corp.mail.ru X-Mras: Ok X-SRW: 606F30325CFA050C8C380D4BBEABEE3039BC097A4E62EBC3F1C0548A3F644CCC X-Mru-Trust-IP: 1 Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-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, 07 Apr 2017 14:24:14 -0000 This is a multi-part message in MIME format. --------------8E84B5498839DCAD3FC753D7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit And again: the problem here is not in the signature, it's in key published. If you publish both weak and strong keys, attacker doesn't need to exploit the stronger key, he can exploit weak key, it doesn't matter if you use the strong one if the weak key is also valid. Attacker will generate single DKIM-Signature by using the comproised weak key. The fact you are ussing the strong one adds nothing to security in this case. There is no way for you to indicate you use the stronger one unless you indicate it with the key itself. So, if you keep the weak key published for compatibility, somehow you must indicate you are using it for compatibility purposes only to prevent verifiers from acepting the messages signed with weak key only if it's not accomplished by a stronger signature. 07.04.2017 15:09, Scott Rose Đ¿Đ¸ÑˆĐµÑ‚: > On 04/06/2017 05:28 PM, Vladimir Dubrovin wrote: > >> >> Hello Scott, >> >> it may be good to cover compatibility issues, because otherwise there >> are little chances to succeed the older but more compatible protocols >> in nearest future. The possible (but probably not the best one) >> solution is: >> >> 1. produce 2 different DKIM-Signatures with 2 different selectors: >> slector1 with SHA-1 + RSA and selector2 one with SHA-512 + ECDSA >> 2. add an additional field to either selector1 DKIM DNS record (need >> to consult RFC if it's allowed) or to DKIM-Signature with selector1 >> (it's allowed but probably is not enough to protect against >> downgrade) to indicate the selector is legacy-only, e.g. >> o=sha512/eccp256 to indicate this selector should be ignored if >> verifier supports sha-512 and eccp256. >> >> Legacy verifier has valid DKIM-Signature with sha1+rsa >> Compatible verifier ignores sha1+rsa and choose sha-512+ECDSA >> > Something similar was proposed in the DANE WG, but was not included > because it isn't up to the sender to tell the receiver which > algorithms to support - the receiver (likely) has its own list of > approved or preferred algorithms from which to do validation. Some > text could be added to the validation section about how validators > should select their strongest preferred algorithm, etc. but not > specify "legacy" algorithms unless there is clear consensus to get rid > of it for DKIM. > > Scott > > >> I can imagine few more ways to resolve compatibility issues, but this >> one seems to be a simplest. >> >> >> 06.04.2017 20:32, Scott Rose Đ¿Đ¸ÑˆĐµÑ‚: >>> This may be of interest to this group, as there isn't an active DKIM >>> WG anymore. This is my first attempt to produce a draft about >>> defining new digital algorithms for DKIM. I'm trying to keep this >>> short i.e. only define a few IANA registry entries and that's it. >>> >>> I'm trying to head off a potential issue for organizations that are >>> told to migrate to ECDSA or looking for algorithm agility that >>> doesn't involve using SHA-1. >>> >>> Comments welcome and needed. Including being told this isn't needed >>> (though I think it might be). >>> >>> Scott Rose >>> >>> NIST >>> >>> >>> >>> -------- Forwarded Message -------- >>> Subject: New Version Notification for draft-srose-dkim-ecc-00.txt >>> Date: Thu, 6 Apr 2017 10:26:43 -0700 >>> From: internet-drafts@ietf.org >>> To: Scott Rose >>> >>> >>> >>> A new version of I-D, draft-srose-dkim-ecc-00.txt >>> has been successfully submitted by Scott Rose and posted to the >>> IETF repository. >>> >>> Name: draft-srose-dkim-ecc >>> Revision: 00 >>> Title: Defining Elliptic Curve Cryptography Algorithms for >>> use with DKIM >>> Document date: 2017-04-06 >>> Group: Individual Submission >>> Pages: 6 >>> URL: https://www.ietf.org/internet-drafts/draft-srose-dkim-ecc-00.txt >>> Status: https://datatracker.ietf.org/doc/draft-srose-dkim-ecc/ >>> Htmlized: https://tools.ietf.org/html/draft-srose-dkim-ecc-00 >>> Htmlized: https://datatracker.ietf.org/doc/html/draft-srose-dkim-ecc-00 >>> >>> >>> Abstract: >>> DomainKeys Identified Mail (DKIM) uses digital signature to >>> associate >>> a message with a given sending domain. Currently, there is only one >>> cryptography algorithm defined for use with DKIM (RSA). This >>> document defines four new elliptic curve cryptography algorithms for >>> use with DKIM. This will allow for algorithm agility if a weakness >>> is found in RSA, and allows for smaller key length to provide the >>> same digital signature strength. >>> >>> >>> >>> 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. >>> >>> The IETF Secretariat >>> >>> _______________________________________________ >>> dmarc mailing list >>> dmarc@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmarc >> >> >> -- >> Vladimir Dubrovin >> @Mail.Ru > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc -- Vladimir Dubrovin @Mail.Ru --------------8E84B5498839DCAD3FC753D7 Content-Type: multipart/related; boundary="------------00A6686184996D0449A31337" --------------00A6686184996D0449A31337 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

And again: the problem here is not in the signature, it's in key published. If you publish both weak  and strong keys, attacker doesn't need to exploit the stronger key, he can exploit weak key, it doesn't matter if you use the strong one if the weak key is also valid. Attacker will generate single DKIM-Signature by using the comproised weak key. The fact you are ussing the strong one adds nothing to security in this case. There is no way for you to indicate you use the stronger one unless you indicate it with the key itself. So, if you keep the weak key published for compatibility, somehow you must indicate you are using it for compatibility purposes only to prevent verifiers from acepting the messages signed with weak key only if it's not accomplished by a stronger signature.


07.04.2017 15:09, Scott Rose Đ¿Đ¸ÑˆĐµÑ‚:
On 04/06/2017 05:28 PM, Vladimir Dubrovin wrote:


Hello Scott,

it may be good to cover compatibility issues, because otherwise there are little chances to succeed the older but more compatible protocols in nearest future.  The possible (but probably not the best one) solution is:

1. produce 2 different DKIM-Signatures with 2 different selectors: slector1  with SHA-1 + RSA and selector2 one with SHA-512 + ECDSA
2. add an additional field to either selector1 DKIM DNS record (need to consult RFC if it's allowed) or to DKIM-Signature with selector1 (it's allowed but probably is not enough to protect against downgrade) to indicate the selector is legacy-only, e.g. o=sha512/eccp256 to indicate this selector should be ignored if verifier supports sha-512 and eccp256.

Legacy verifier has valid DKIM-Signature with sha1+rsa
Compatible verifier ignores sha1+rsa and choose sha-512+ECDSA

Something similar was proposed in the DANE WG, but was not included because it isn't up to the sender to tell the receiver which algorithms to support - the receiver (likely) has its own list of approved or preferred algorithms from which to do validation.  Some text could be added to the validation section about how validators should select their strongest preferred algorithm, etc. but not specify "legacy" algorithms unless there is clear consensus to get rid of it for DKIM.

Scott


I can imagine few more ways to resolve compatibility issues, but this one seems to be a simplest.


06.04.2017 20:32, Scott Rose Đ¿Đ¸ÑˆĐµÑ‚:
This may be of interest to this group, as there isn't an active DKIM WG anymore.  This is my first attempt to produce a draft about defining new digital algorithms for DKIM. I'm trying to keep this short i.e. only define a few IANA registry entries and that's it.

I'm trying to head off a potential issue for organizations that are told to migrate to ECDSA or looking for algorithm agility that doesn't involve using SHA-1.

Comments welcome and needed. Including being told this isn't needed (though I think it might be).

Scott Rose

NIST



-------- Forwarded Message --------
Subject:     New Version Notification for draft-srose-dkim-ecc-00.txt
Date:     Thu, 6 Apr 2017 10:26:43 -0700
From: internet-drafts@ietf.org
To:     Scott Rose <scott.rose@nist.gov>



A new version of I-D, draft-srose-dkim-ecc-00.txt
has been successfully submitted by Scott Rose and posted to the
IETF repository.

Name:        draft-srose-dkim-ecc
Revision:    00
Title:        Defining Elliptic Curve Cryptography Algorithms for use with DKIM
Document date:    2017-04-06
Group:        Individual Submission
Pages:        6
URL: https://www.ietf.org/internet-drafts/draft-srose-dkim-ecc-00.txt
Status: https://datatracker.ietf.org/doc/draft-srose-dkim-ecc/
Htmlized: https://tools.ietf.org/html/draft-srose-dkim-ecc-00
Htmlized: https://datatracker.ietf.org/doc/html/draft-srose-dkim-ecc-00


Abstract:
   DomainKeys Identified Mail (DKIM) uses digital signature to associate
   a message with a given sending domain.  Currently, there is only one
   cryptography algorithm defined for use with DKIM (RSA).  This
   document defines four new elliptic curve cryptography algorithms for
   use with DKIM.  This will allow for algorithm agility if a weakness
   is found in RSA, and allows for smaller key length to provide the
   same digital signature strength.



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.

The IETF Secretariat

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


-- 
Vladimir Dubrovin
@Mail.Ru

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


--
Vladimir Dubrovin
@Mail.Ru
--------------00A6686184996D0449A31337 Content-Type: image/png; name="alcombokcljjdeef.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="alcombokcljjdeef.png" iVBORw0KGgoAAAANSUhEUgAAAHwAAAAZCAQAAABZLoLcAAADz0lEQVR4AeWX2XLiPBCFP3nB 7IEAWSAk4BkWg837P95UuU51WRhXjf1XcjH/8Y2EpO7+tLQQd3JM2XDgwo2CCylvDPkJOVIK PgCYknMm4YfkWJBxe/AdmPLd6ssXwL4svfAjSvhdQc3JuHjwXwR8p3ryC/CrLL/yAxpxFWDK nB6lCBiztpYjEd+pKe+Mfha8L7gzY+oKeTf0ABOOgaanT99rSRgS8lgBCQMirK+VAwa41uCO xMaF9GlmDIHID+WskxypyzspB/a8EEOpCXnZ5wNMB25s2VBok74TAAtZK9gS4WtCqt43TqwI eC57DgHHqTxQbcATPhXXDojKw7nhgcqlu97H81YOzYiBgA/vZOcsSdgxZ6yQB1AqfpgEU69+ pgdSyK7W/8wRIVpyC/4a/JXCLF2BsWw+kPxMqSjUnD0BgVzeyDja2b5QmtMEfVaTkbnNfSSr /7JdZamTwu8txIHK4V+CbyrjMxbtwZ+1VgAfKg/VNuaI1samqCDwwC/MgICdYa0IcBbYQJaV OpW+Yq1XV/C5xTXDAbQH/yp/WpjrEwGYQo4Vc59leeKBj8Grv6jutK7Pto3vz9+QvCN4oP8b vwkBOoErFSXABmtsMLfA0Ay0h6T69M7yElhrJzl8PXcEn+k4xdAdvChNoMYcx72uZm6qdWsL fipLc+7luHYC/7Q4uoMrOQBlEjs1DDpXTG9bgxfaVXXtu4ArUc7+O/gVtC4ZdZ3N3JPu8m7g MXXtuoALY4yvkZLtI2X1EZm5+6qFZ4ACX5Xlt9bgmVrqOj8ET+WnFbhFFHGvSC1Jfc6ntp5r fH1h4NqYs9bgWz1zqG/OOrj137UC96fR14sOtKdlJagDutokx9q7x7Vl24Ib4IyqQk6PwZXt C/otwV81bkhVA4pHOyjSz/0S5qKL55Ul7wpdsyWzKbQGh73d8oGdSGE/AA+5ymsVLmZC2ATu 3e85C5yW7plceSzkThvBBkCChaMv1cbTY4RxJ/CITO05KTt5aQKHhbVdSBnZZBybwKURBTeB 7km5qlYwoaZI67wnABxLDuqcMgPmlRC30AkceqpXv4JLAzisvcePtTeDSxODtY9cUTUmmaOd DkcIVk7VvsOB5Mqgr7i7k5fU06YU8OYFlTLUw2duL4ETmOZk5hdiCrusdvL0WDFbisrkbolp 1IzCnDwZtGPMkhh44qU2awkr+p7DFSMwhSxqYxxTVqyYEau+YGZJaEkPk/lfKp4RK8FG8tSs kCeWrDCWZo3JvIfegRO5Mv4/rpA3ofrfmv+BAmZsOZBbRl3g+Af1By7rr2XUY4YeAAAAAElF TkSuQmCC --------------00A6686184996D0449A31337-- --------------8E84B5498839DCAD3FC753D7-- From nobody Fri Apr 7 08:12: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 D561C1294D3 for ; Fri, 7 Apr 2017 08:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.406 X-Spam-Level: X-Spam-Status: No, score=-3.406 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, 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 Nrur4a-uOaFl for ; Fri, 7 Apr 2017 08:12:43 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 E30F61293D6 for ; Fri, 7 Apr 2017 08:12:40 -0700 (PDT) Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v37F5lX1019281; Fri, 7 Apr 2017 11:12:37 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049458.ppops.net-00191d01. with ESMTP id 29pcch12xs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 07 Apr 2017 11:12:37 -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 v37FCaZU010864; Fri, 7 Apr 2017 11:12:37 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v37FCR7k010655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 7 Apr 2017 11:12:32 -0400 Received: from MISOUT7MSGHUBAC.ITServices.sbc.com (MISOUT7MSGHUBAC.itservices.sbc.com [130.9.129.147]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Fri, 7 Apr 2017 15:12:08 GMT Received: from MISOUT7MSGUSRCG.ITServices.sbc.com ([169.254.7.103]) by MISOUT7MSGHUBAC.ITServices.sbc.com ([130.9.129.147]) with mapi id 14.03.0319.002; Fri, 7 Apr 2017 11:12:08 -0400 From: "HANSEN, TONY L" To: Vladimir Dubrovin , Scott Rose , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-00.txt Thread-Index: AQHSr6qnJeuM/AM6cUCPN75jnzxAmaG6A0+A Date: Fri, 7 Apr 2017 15:12:07 +0000 Message-ID: <363EDD8B-2654-4D81-AD41-D355599D3143@att.com> References: <149149960391.22024.11499305209108527807.idtracker@ietfa.amsl.com> <6af0bc7b-1ec4-9e87-557b-51d86046842c@nist.gov> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.110.198] Content-Type: multipart/alternative; boundary="_000_363EDD8B26544D81AD41D355599D3143attcom_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-07_12:, , 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-1704070126 Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-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, 07 Apr 2017 15:12:47 -0000 --_000_363EDD8B26544D81AD41D355599D3143attcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmlnaHQgbm93IHdlIHJlcXVpcmUgc3VwcG9ydCBmb3IgdHdvIHR5cGVzIG9mIGtleXM6IGEgd2Vh ayBvbmUgKHNoYTEpIGFuZCBhIHN0cm9uZyBvbmUgKHNoYTI1NikuDQoNClJvbGxpbmcgb3V0IGEg bmV3IHR5cGUgb2Yga2V5IHNob3VsZCBpbmNsdWRlIHJlcXVpcmluZyBzaWduZXJzIHRvIGRpdGNo IHRoZSB3ZWFrIHNoYTEga2V5LiBCdXQgeW91IHN0aWxsIGhhdmUgYSBzdHJvbmcgc2hhMjU2IGtl eSB0byB1c2UgYWxvbmcgd2l0aCB0aGUgbmV3IGtleS4NCg0KQW55IGV4YW1wbGVzIHNob3dpbmcg Y29tcGF0aWJpbGl0eSB3aXRoIG11bHRpcGxlIGtleXMgc2hvdWxkIHVzZSBhIHNoYTI1NiBrZXkg aW4gdGhlIGV4YW1wbGUgYW5kIG5vdCBhIHNoYTEga2V5Lg0KDQogICAgICAgICAgICAgICAgVG9u eSBIYW5zZW4NCg0KRnJvbTogZG1hcmMgPGRtYXJjLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFs ZiBvZiBWbGFkaW1pciBEdWJyb3ZpbiA8ZHVicm92aW5AY29ycC5tYWlsLnJ1Pg0KRGF0ZTogRnJp ZGF5LCBBcHJpbCA3LCAyMDE3IGF0IDEwOjI0IEFNDQpUbzogU2NvdHQgUm9zZSA8c2NvdHQucm9z ZUBuaXN0Lmdvdj4sICJkbWFyY0BpZXRmLm9yZyIgPGRtYXJjQGlldGYub3JnPg0KU3ViamVjdDog UmU6IFtkbWFyYy1pZXRmXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt c3Jvc2UtZGtpbS1lY2MtMDAudHh0DQoNCg0KQW5kIGFnYWluOiB0aGUgcHJvYmxlbSBoZXJlIGlz IG5vdCBpbiB0aGUgc2lnbmF0dXJlLCBpdCdzIGluIGtleSBwdWJsaXNoZWQuIElmIHlvdSBwdWJs aXNoIGJvdGggd2VhayAgYW5kIHN0cm9uZyBrZXlzLCBhdHRhY2tlciBkb2Vzbid0IG5lZWQgdG8g ZXhwbG9pdCB0aGUgc3Ryb25nZXIga2V5LCBoZSBjYW4gZXhwbG9pdCB3ZWFrIGtleSwgaXQgZG9l c24ndCBtYXR0ZXIgaWYgeW91IHVzZSB0aGUgc3Ryb25nIG9uZSBpZiB0aGUgd2VhayBrZXkgaXMg YWxzbyB2YWxpZC4gQXR0YWNrZXIgd2lsbCBnZW5lcmF0ZSBzaW5nbGUgREtJTS1TaWduYXR1cmUg YnkgdXNpbmcgdGhlIGNvbXByb2lzZWQgd2VhayBrZXkuIFRoZSBmYWN0IHlvdSBhcmUgdXNzaW5n IHRoZSBzdHJvbmcgb25lIGFkZHMgbm90aGluZyB0byBzZWN1cml0eSBpbiB0aGlzIGNhc2UuIFRo ZXJlIGlzIG5vIHdheSBmb3IgeW91IHRvIGluZGljYXRlIHlvdSB1c2UgdGhlIHN0cm9uZ2VyIG9u ZSB1bmxlc3MgeW91IGluZGljYXRlIGl0IHdpdGggdGhlIGtleSBpdHNlbGYuIFNvLCBpZiB5b3Ug a2VlcCB0aGUgd2VhayBrZXkgcHVibGlzaGVkIGZvciBjb21wYXRpYmlsaXR5LCBzb21laG93IHlv dSBtdXN0IGluZGljYXRlIHlvdSBhcmUgdXNpbmcgaXQgZm9yIGNvbXBhdGliaWxpdHkgcHVycG9z ZXMgb25seSB0byBwcmV2ZW50IHZlcmlmaWVycyBmcm9tIGFjZXB0aW5nIHRoZSBtZXNzYWdlcyBz aWduZWQgd2l0aCB3ZWFrIGtleSBvbmx5IGlmIGl0J3Mgbm90IGFjY29tcGxpc2hlZCBieSBhIHN0 cm9uZ2VyIHNpZ25hdHVyZS4NCg0KDQowNy4wNC4yMDE3IDE1OjA5LCBTY290dCBSb3NlINC/0LjR iNC10YI6DQpPbiAwNC8wNi8yMDE3IDA1OjI4IFBNLCBWbGFkaW1pciBEdWJyb3ZpbiB3cm90ZToN Cg0KDQoNCkhlbGxvIFNjb3R0LA0KDQppdCBtYXkgYmUgZ29vZCB0byBjb3ZlciBjb21wYXRpYmls aXR5IGlzc3VlcywgYmVjYXVzZSBvdGhlcndpc2UgdGhlcmUgYXJlIGxpdHRsZSBjaGFuY2VzIHRv IHN1Y2NlZWQgdGhlIG9sZGVyIGJ1dCBtb3JlIGNvbXBhdGlibGUgcHJvdG9jb2xzIGluIG5lYXJl c3QgZnV0dXJlLiAgVGhlIHBvc3NpYmxlIChidXQgcHJvYmFibHkgbm90IHRoZSBiZXN0IG9uZSkg c29sdXRpb24gaXM6DQoNCjEuIHByb2R1Y2UgMiBkaWZmZXJlbnQgREtJTS1TaWduYXR1cmVzIHdp dGggMiBkaWZmZXJlbnQgc2VsZWN0b3JzOiBzbGVjdG9yMSAgd2l0aCBTSEEtMSArIFJTQSBhbmQg c2VsZWN0b3IyIG9uZSB3aXRoIFNIQS01MTIgKyBFQ0RTQQ0KMi4gYWRkIGFuIGFkZGl0aW9uYWwg ZmllbGQgdG8gZWl0aGVyIHNlbGVjdG9yMSBES0lNIEROUyByZWNvcmQgKG5lZWQgdG8gY29uc3Vs dCBSRkMgaWYgaXQncyBhbGxvd2VkKSBvciB0byBES0lNLVNpZ25hdHVyZSB3aXRoIHNlbGVjdG9y MSAoaXQncyBhbGxvd2VkIGJ1dCBwcm9iYWJseSBpcyBub3QgZW5vdWdoIHRvIHByb3RlY3QgYWdh aW5zdCBkb3duZ3JhZGUpIHRvIGluZGljYXRlIHRoZSBzZWxlY3RvciBpcyBsZWdhY3ktb25seSwg ZS5nLiBvPXNoYTUxMi9lY2NwMjU2IHRvIGluZGljYXRlIHRoaXMgc2VsZWN0b3Igc2hvdWxkIGJl IGlnbm9yZWQgaWYgdmVyaWZpZXIgc3VwcG9ydHMgc2hhLTUxMiBhbmQgZWNjcDI1Ni4NCg0KTGVn YWN5IHZlcmlmaWVyIGhhcyB2YWxpZCBES0lNLVNpZ25hdHVyZSB3aXRoIHNoYTErcnNhDQpDb21w YXRpYmxlIHZlcmlmaWVyIGlnbm9yZXMgc2hhMStyc2EgYW5kIGNob29zZSBzaGEtNTEyK0VDRFNB DQpTb21ldGhpbmcgc2ltaWxhciB3YXMgcHJvcG9zZWQgaW4gdGhlIERBTkUgV0csIGJ1dCB3YXMg bm90IGluY2x1ZGVkIGJlY2F1c2UgaXQgaXNuJ3QgdXAgdG8gdGhlIHNlbmRlciB0byB0ZWxsIHRo ZSByZWNlaXZlciB3aGljaCBhbGdvcml0aG1zIHRvIHN1cHBvcnQgLSB0aGUgcmVjZWl2ZXIgKGxp a2VseSkgaGFzIGl0cyBvd24gbGlzdCBvZiBhcHByb3ZlZCBvciBwcmVmZXJyZWQgYWxnb3JpdGht cyBmcm9tIHdoaWNoIHRvIGRvIHZhbGlkYXRpb24uICBTb21lIHRleHQgY291bGQgYmUgYWRkZWQg dG8gdGhlIHZhbGlkYXRpb24gc2VjdGlvbiBhYm91dCBob3cgdmFsaWRhdG9ycyBzaG91bGQgc2Vs ZWN0IHRoZWlyIHN0cm9uZ2VzdCBwcmVmZXJyZWQgYWxnb3JpdGhtLCBldGMuIGJ1dCBub3Qgc3Bl Y2lmeSAibGVnYWN5IiBhbGdvcml0aG1zIHVubGVzcyB0aGVyZSBpcyBjbGVhciBjb25zZW5zdXMg dG8gZ2V0IHJpZCBvZiBpdCBmb3IgREtJTS4NCg0KU2NvdHQNCg0KDQoNCkkgY2FuIGltYWdpbmUg ZmV3IG1vcmUgd2F5cyB0byByZXNvbHZlIGNvbXBhdGliaWxpdHkgaXNzdWVzLCBidXQgdGhpcyBv bmUgc2VlbXMgdG8gYmUgYSBzaW1wbGVzdC4NCg0KDQowNi4wNC4yMDE3IDIwOjMyLCBTY290dCBS b3NlINC/0LjRiNC10YI6DQoNClRoaXMgbWF5IGJlIG9mIGludGVyZXN0IHRvIHRoaXMgZ3JvdXAs IGFzIHRoZXJlIGlzbid0IGFuIGFjdGl2ZSBES0lNIFdHIGFueW1vcmUuICBUaGlzIGlzIG15IGZp cnN0IGF0dGVtcHQgdG8gcHJvZHVjZSBhIGRyYWZ0IGFib3V0IGRlZmluaW5nIG5ldyBkaWdpdGFs IGFsZ29yaXRobXMgZm9yIERLSU0uIEknbSB0cnlpbmcgdG8ga2VlcCB0aGlzIHNob3J0IGkuZS4g b25seSBkZWZpbmUgYSBmZXcgSUFOQSByZWdpc3RyeSBlbnRyaWVzIGFuZCB0aGF0J3MgaXQuDQoN CkknbSB0cnlpbmcgdG8gaGVhZCBvZmYgYSBwb3RlbnRpYWwgaXNzdWUgZm9yIG9yZ2FuaXphdGlv bnMgdGhhdCBhcmUgdG9sZCB0byBtaWdyYXRlIHRvIEVDRFNBIG9yIGxvb2tpbmcgZm9yIGFsZ29y aXRobSBhZ2lsaXR5IHRoYXQgZG9lc24ndCBpbnZvbHZlIHVzaW5nIFNIQS0xLg0KDQpDb21tZW50 cyB3ZWxjb21lIGFuZCBuZWVkZWQuIEluY2x1ZGluZyBiZWluZyB0b2xkIHRoaXMgaXNuJ3QgbmVl ZGVkICh0aG91Z2ggSSB0aGluayBpdCBtaWdodCBiZSkuDQoNClNjb3R0IFJvc2UNCg0KTklTVA0K DQoNCg0KLS0tLS0tLS0gRm9yd2FyZGVkIE1lc3NhZ2UgLS0tLS0tLS0NClN1YmplY3Q6ICAgICBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXNyb3NlLWRraW0tZWNjLTAwLnR4dA0K RGF0ZTogICAgIFRodSwgNiBBcHIgMjAxNyAxMDoyNjo0MyAtMDcwMA0KRnJvbTogaW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQpUbzogICAg IFNjb3R0IFJvc2UgPHNjb3R0LnJvc2VAbmlzdC5nb3Y+PG1haWx0bzpzY290dC5yb3NlQG5pc3Qu Z292Pg0KDQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXNyb3NlLWRraW0tZWNjLTAw LnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBTY290dCBSb3NlIGFuZCBw b3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6ICAgICAgICBkcmFmdC1zcm9z ZS1ka2ltLWVjYw0KUmV2aXNpb246ICAgIDAwDQpUaXRsZTogICAgICAgIERlZmluaW5nIEVsbGlw dGljIEN1cnZlIENyeXB0b2dyYXBoeSBBbGdvcml0aG1zIGZvciB1c2Ugd2l0aCBES0lNDQpEb2N1 bWVudCBkYXRlOiAgICAyMDE3LTA0LTA2DQpHcm91cDogICAgICAgIEluZGl2aWR1YWwgU3VibWlz c2lvbg0KUGFnZXM6ICAgICAgICA2DQpVUkw6IGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1zcm9zZS1ka2ltLWVjYy0wMC50eHQ8aHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfaW50ZXJuZXQtMkRk cmFmdHNfZHJhZnQtMkRzcm9zZS0yRGRraW0tMkRlY2MtMkQwMC50eHQmZD1Ed01EYVEmYz1MRlla LW85X0hVTWVNVFNRaWN2aklnJnI9S3o4VmRnUFZjdEROU05QSjZQc0JhdyZtPXZGbUU5cmFSVEl4 YlhFYWs0LWhnazlkZjJyMlVQUGNQSUs4M1pXOEZYbjAmcz11M0RPNTd1TzVlM3lnQXBKeWJBVEZ2 SF9WdkxxYTFrMUJfeTVqM3NKX3lJJmU9Pg0KU3RhdHVzOiBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1zcm9zZS1ka2ltLWVjYy88aHR0cHM6Ly91cmxkZWZlbnNlLnByb29m cG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19kYXRhdHJhY2tlci5pZXRmLm9yZ19kb2NfZHJh ZnQtMkRzcm9zZS0yRGRraW0tMkRlY2NfJmQ9RHdNRGFRJmM9TEZZWi1vOV9IVU1lTVRTUWljdmpJ ZyZyPUt6OFZkZ1BWY3RETlNOUEo2UHNCYXcmbT12Rm1FOXJhUlRJeGJYRWFrNC1oZ2s5ZGYycjJV UFBjUElLODNaVzhGWG4wJnM9WjJ5WHR5YnViUl9FaWtfcmlaYlo3RnVkanZ4RHQwREI1aHlVUk1z TVNkUSZlPT4NCkh0bWxpemVkOiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc3Jv c2UtZGtpbS1lY2MtMDA8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91 PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1sX2RyYWZ0LTJEc3Jvc2UtMkRka2ltLTJEZWNj LTJEMDAmZD1Ed01EYVEmYz1MRllaLW85X0hVTWVNVFNRaWN2aklnJnI9S3o4VmRnUFZjdEROU05Q SjZQc0JhdyZtPXZGbUU5cmFSVEl4YlhFYWs0LWhnazlkZjJyMlVQUGNQSUs4M1pXOEZYbjAmcz1X N1pLY0IxZDd6R0ViZmtqb29DZ3lKSEk5S3VzUllWUUNyOUhzeFpfZnIwJmU9Pg0KSHRtbGl6ZWQ6 IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtc3Jvc2UtZGtpbS1l Y2MtMDA8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNB X19kYXRhdHJhY2tlci5pZXRmLm9yZ19kb2NfaHRtbF9kcmFmdC0yRHNyb3NlLTJEZGtpbS0yRGVj Yy0yRDAwJmQ9RHdNRGFRJmM9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZyPUt6OFZkZ1BWY3RETlNO UEo2UHNCYXcmbT12Rm1FOXJhUlRJeGJYRWFrNC1oZ2s5ZGYycjJVUFBjUElLODNaVzhGWG4wJnM9 WWpQUEFGaUVFVU9PQkl6cldQN3JsUEUybnBHckJBd2ppYy1QZ2laZzd0OCZlPT4NCg0KDQpBYnN0 cmFjdDoNCiAgIERvbWFpbktleXMgSWRlbnRpZmllZCBNYWlsIChES0lNKSB1c2VzIGRpZ2l0YWwg c2lnbmF0dXJlIHRvIGFzc29jaWF0ZQ0KICAgYSBtZXNzYWdlIHdpdGggYSBnaXZlbiBzZW5kaW5n IGRvbWFpbi4gIEN1cnJlbnRseSwgdGhlcmUgaXMgb25seSBvbmUNCiAgIGNyeXB0b2dyYXBoeSBh bGdvcml0aG0gZGVmaW5lZCBmb3IgdXNlIHdpdGggREtJTSAoUlNBKS4gIFRoaXMNCiAgIGRvY3Vt ZW50IGRlZmluZXMgZm91ciBuZXcgZWxsaXB0aWMgY3VydmUgY3J5cHRvZ3JhcGh5IGFsZ29yaXRo bXMgZm9yDQogICB1c2Ugd2l0aCBES0lNLiAgVGhpcyB3aWxsIGFsbG93IGZvciBhbGdvcml0aG0g YWdpbGl0eSBpZiBhIHdlYWtuZXNzDQogICBpcyBmb3VuZCBpbiBSU0EsIGFuZCBhbGxvd3MgZm9y IHNtYWxsZXIga2V5IGxlbmd0aCB0byBwcm92aWRlIHRoZQ0KICAgc2FtZSBkaWdpdGFsIHNpZ25h dHVyZSBzdHJlbmd0aC4NCg0K --_000_363EDD8B26544D81AD41D355599D3143attcom_ Content-Type: text/html; charset="utf-8" Content-ID: <519C2DA45870AE448A299527E3D2B94A@LOCAL> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1z b0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q2FsaWJyaSI+UmlnaHQgbm93IHdlIHJlcXVpcmUgc3VwcG9ydCBmb3IgdHdvIHR5 cGVzIG9mIGtleXM6IGEgd2VhayBvbmUgKHNoYTEpIGFuZCBhIHN0cm9uZyBvbmUgKHNoYTI1Niku PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Um9sbGluZyBvdXQgYSBuZXcgdHlwZSBvZiBrZXkg c2hvdWxkIGluY2x1ZGUgcmVxdWlyaW5nIHNpZ25lcnMgdG8gZGl0Y2ggdGhlIHdlYWsgc2hhMSBr ZXkuIEJ1dCB5b3Ugc3RpbGwgaGF2ZSBhIHN0cm9uZyBzaGEyNTYga2V5IHRvIHVzZSBhbG9uZyB3 aXRoIHRoZSBuZXcga2V5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkFueSBleGFtcGxlcyBz aG93aW5nIGNvbXBhdGliaWxpdHkgd2l0aCBtdWx0aXBsZSBrZXlzIHNob3VsZCB1c2UgYSBzaGEy NTYga2V5IGluIHRoZSBleGFtcGxlIGFuZCBub3QgYSBzaGExIGtleS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVG9ueSBIYW5zZW48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+RnJvbTog PC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNr Ij5kbWFyYyAmbHQ7ZG1hcmMtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIFZsYWRp bWlyIER1YnJvdmluICZsdDtkdWJyb3ZpbkBjb3JwLm1haWwucnUmZ3Q7PGJyPg0KPGI+RGF0ZTog PC9iPkZyaWRheSwgQXByaWwgNywgMjAxNyBhdCAxMDoyNCBBTTxicj4NCjxiPlRvOiA8L2I+U2Nv dHQgUm9zZSAmbHQ7c2NvdHQucm9zZUBuaXN0LmdvdiZndDssICZxdW90O2RtYXJjQGlldGYub3Jn JnF1b3Q7ICZsdDtkbWFyY0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtk bWFyYy1pZXRmXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc3Jvc2Ut ZGtpbS1lY2MtMDAudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpBbmQgYWdhaW46IHRoZSBwcm9ibGVtIGhlcmUgaXMg bm90IGluIHRoZSBzaWduYXR1cmUsIGl0J3MgaW4ga2V5IHB1Ymxpc2hlZC4gSWYgeW91IHB1Ymxp c2ggYm90aCB3ZWFrJm5ic3A7IGFuZCBzdHJvbmcga2V5cywgYXR0YWNrZXIgZG9lc24ndCBuZWVk IHRvIGV4cGxvaXQgdGhlIHN0cm9uZ2VyIGtleSwgaGUgY2FuIGV4cGxvaXQgd2VhayBrZXksIGl0 IGRvZXNuJ3QgbWF0dGVyIGlmIHlvdSB1c2UgdGhlIHN0cm9uZyBvbmUgaWYgdGhlIHdlYWsga2V5 IGlzDQogYWxzbyB2YWxpZC4gQXR0YWNrZXIgd2lsbCBnZW5lcmF0ZSBzaW5nbGUgREtJTS1TaWdu YXR1cmUgYnkgdXNpbmcgdGhlIGNvbXByb2lzZWQgd2VhayBrZXkuIFRoZSBmYWN0IHlvdSBhcmUg dXNzaW5nIHRoZSBzdHJvbmcgb25lIGFkZHMgbm90aGluZyB0byBzZWN1cml0eSBpbiB0aGlzIGNh c2UuIFRoZXJlIGlzIG5vIHdheSBmb3IgeW91IHRvIGluZGljYXRlIHlvdSB1c2UgdGhlIHN0cm9u Z2VyIG9uZSB1bmxlc3MgeW91IGluZGljYXRlIGl0IHdpdGgNCiB0aGUga2V5IGl0c2VsZi4gU28s IGlmIHlvdSBrZWVwIHRoZSB3ZWFrIGtleSBwdWJsaXNoZWQgZm9yIGNvbXBhdGliaWxpdHksIHNv bWVob3cgeW91IG11c3QgaW5kaWNhdGUgeW91IGFyZSB1c2luZyBpdCBmb3IgY29tcGF0aWJpbGl0 eSBwdXJwb3NlcyBvbmx5IHRvIHByZXZlbnQgdmVyaWZpZXJzIGZyb20gYWNlcHRpbmcgdGhlIG1l c3NhZ2VzIHNpZ25lZCB3aXRoIHdlYWsga2V5IG9ubHkgaWYgaXQncyBub3QgYWNjb21wbGlzaGVk IGJ5IGEgc3Ryb25nZXINCiBzaWduYXR1cmUuPGJyPg0KPGJyPg0KPGJyPg0KMDcuMDQuMjAxNyAx NTowOSwgU2NvdHQgUm9zZSDQv9C40YjQtdGCOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIDA0LzA2LzIwMTcgMDU6MjggUE0sIFZsYWRpbWlyIER1YnJv dmluIHdyb3RlOiA8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpIZWxsbyBTY290 dCwgPGJyPg0KPGJyPg0KaXQgbWF5IGJlIGdvb2QgdG8gY292ZXIgY29tcGF0aWJpbGl0eSBpc3N1 ZXMsIGJlY2F1c2Ugb3RoZXJ3aXNlIHRoZXJlIGFyZSBsaXR0bGUgY2hhbmNlcyB0byBzdWNjZWVk IHRoZSBvbGRlciBidXQgbW9yZSBjb21wYXRpYmxlIHByb3RvY29scyBpbiBuZWFyZXN0IGZ1dHVy ZS4mbmJzcDsgVGhlIHBvc3NpYmxlIChidXQgcHJvYmFibHkgbm90IHRoZSBiZXN0IG9uZSkgc29s dXRpb24gaXM6DQo8YnI+DQo8YnI+DQoxLiBwcm9kdWNlIDIgZGlmZmVyZW50IERLSU0tU2lnbmF0 dXJlcyB3aXRoIDIgZGlmZmVyZW50IHNlbGVjdG9yczogc2xlY3RvcjEmbmJzcDsgd2l0aCBTSEEt MSAmIzQzOyBSU0EgYW5kIHNlbGVjdG9yMiBvbmUgd2l0aCBTSEEtNTEyICYjNDM7IEVDRFNBDQo8 YnI+DQoyLiBhZGQgYW4gYWRkaXRpb25hbCBmaWVsZCB0byBlaXRoZXIgc2VsZWN0b3IxIERLSU0g RE5TIHJlY29yZCAobmVlZCB0byBjb25zdWx0IFJGQyBpZiBpdCdzIGFsbG93ZWQpIG9yIHRvIERL SU0tU2lnbmF0dXJlIHdpdGggc2VsZWN0b3IxIChpdCdzIGFsbG93ZWQgYnV0IHByb2JhYmx5IGlz IG5vdCBlbm91Z2ggdG8gcHJvdGVjdCBhZ2FpbnN0IGRvd25ncmFkZSkgdG8gaW5kaWNhdGUgdGhl IHNlbGVjdG9yIGlzIGxlZ2FjeS1vbmx5LCBlLmcuIG89c2hhNTEyL2VjY3AyNTYNCiB0byBpbmRp Y2F0ZSB0aGlzIHNlbGVjdG9yIHNob3VsZCBiZSBpZ25vcmVkIGlmIHZlcmlmaWVyIHN1cHBvcnRz IHNoYS01MTIgYW5kIGVjY3AyNTYuDQo8YnI+DQo8YnI+DQpMZWdhY3kgdmVyaWZpZXIgaGFzIHZh bGlkIERLSU0tU2lnbmF0dXJlIHdpdGggc2hhMSYjNDM7cnNhIDxicj4NCkNvbXBhdGlibGUgdmVy aWZpZXIgaWdub3JlcyBzaGExJiM0Mztyc2EgYW5kIGNob29zZSBzaGEtNTEyJiM0MztFQ0RTQSA8 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvbWV0 aGluZyBzaW1pbGFyIHdhcyBwcm9wb3NlZCBpbiB0aGUgREFORSBXRywgYnV0IHdhcyBub3QgaW5j bHVkZWQgYmVjYXVzZSBpdCBpc24ndCB1cCB0byB0aGUgc2VuZGVyIHRvIHRlbGwgdGhlIHJlY2Vp dmVyIHdoaWNoIGFsZ29yaXRobXMgdG8gc3VwcG9ydCAtIHRoZSByZWNlaXZlciAobGlrZWx5KSBo YXMgaXRzIG93biBsaXN0IG9mIGFwcHJvdmVkIG9yIHByZWZlcnJlZCBhbGdvcml0aG1zIGZyb20g d2hpY2gNCiB0byBkbyB2YWxpZGF0aW9uLiZuYnNwOyBTb21lIHRleHQgY291bGQgYmUgYWRkZWQg dG8gdGhlIHZhbGlkYXRpb24gc2VjdGlvbiBhYm91dCBob3cgdmFsaWRhdG9ycyBzaG91bGQgc2Vs ZWN0IHRoZWlyIHN0cm9uZ2VzdCBwcmVmZXJyZWQgYWxnb3JpdGhtLCBldGMuIGJ1dCBub3Qgc3Bl Y2lmeSAmcXVvdDtsZWdhY3kmcXVvdDsgYWxnb3JpdGhtcyB1bmxlc3MgdGhlcmUgaXMgY2xlYXIg Y29uc2Vuc3VzIHRvIGdldCByaWQgb2YgaXQgZm9yIERLSU0uDQo8YnI+DQo8YnI+DQpTY290dCA8 YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SSBjYW4gaW1hZ2luZSBmZXcgbW9yZSB3YXlzIHRvIHJlc29sdmUgY29tcGF0aWJpbGl0 eSBpc3N1ZXMsIGJ1dCB0aGlzIG9uZSBzZWVtcyB0byBiZSBhIHNpbXBsZXN0Lg0KPGJyPg0KPGJy Pg0KPGJyPg0KMDYuMDQuMjAxNyAyMDozMiwgU2NvdHQgUm9zZSDQv9C40YjQtdGCOiA8YnI+DQo8 YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjUuMHB0O21h cmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdDttYXJnaW4tbGVmdDowaW4iPg0KVGhp cyBtYXkgYmUgb2YgaW50ZXJlc3QgdG8gdGhpcyBncm91cCwgYXMgdGhlcmUgaXNuJ3QgYW4gYWN0 aXZlIERLSU0gV0cgYW55bW9yZS4mbmJzcDsgVGhpcyBpcyBteSBmaXJzdCBhdHRlbXB0IHRvIHBy b2R1Y2UgYSBkcmFmdCBhYm91dCBkZWZpbmluZyBuZXcgZGlnaXRhbCBhbGdvcml0aG1zIGZvciBE S0lNLiBJJ20gdHJ5aW5nIHRvIGtlZXAgdGhpcyBzaG9ydCBpLmUuIG9ubHkgZGVmaW5lIGEgZmV3 IElBTkEgcmVnaXN0cnkgZW50cmllcyBhbmQgdGhhdCdzDQogaXQuIDxicj4NCjxicj4NCkknbSB0 cnlpbmcgdG8gaGVhZCBvZmYgYSBwb3RlbnRpYWwgaXNzdWUgZm9yIG9yZ2FuaXphdGlvbnMgdGhh dCBhcmUgdG9sZCB0byBtaWdyYXRlIHRvIEVDRFNBIG9yIGxvb2tpbmcgZm9yIGFsZ29yaXRobSBh Z2lsaXR5IHRoYXQgZG9lc24ndCBpbnZvbHZlIHVzaW5nIFNIQS0xLg0KPGJyPg0KPGJyPg0KQ29t bWVudHMgd2VsY29tZSBhbmQgbmVlZGVkLiBJbmNsdWRpbmcgYmVpbmcgdG9sZCB0aGlzIGlzbid0 IG5lZWRlZCAodGhvdWdoIEkgdGhpbmsgaXQgbWlnaHQgYmUpLg0KPGJyPg0KPGJyPg0KU2NvdHQg Um9zZSA8YnI+DQo8YnI+DQpOSVNUIDxicj4NCjxicj4NCjxicj4NCjxicj4NCi0tLS0tLS0tIEZv cndhcmRlZCBNZXNzYWdlIC0tLS0tLS0tIDxicj4NClN1YmplY3Q6Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc3Jvc2UtZGtpbS1lY2Mt MDAudHh0IDxicj4NCkRhdGU6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRodSwgNiBBcHIgMjAx NyAxMDoyNjo0MyAtMDcwMCA8YnI+DQpGcm9tOiA8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+IDxicj4NClRvOiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBTY290dCBSb3NlIDxhIGhyZWY9Im1haWx0bzpzY290dC5yb3Nl QG5pc3QuZ292Ij4mbHQ7c2NvdHQucm9zZUBuaXN0LmdvdiZndDs8L2E+DQo8YnI+DQo8YnI+DQo8 YnI+DQo8YnI+DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtc3Jvc2UtZGtpbS1lY2MtMDAu dHh0IDxicj4NCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgU2NvdHQgUm9zZSBh bmQgcG9zdGVkIHRvIHRoZSA8YnI+DQpJRVRGIHJlcG9zaXRvcnkuIDxicj4NCjxicj4NCk5hbWU6 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRyYWZ0LXNyb3NlLWRr aW0tZWNjIDxicj4NClJldmlzaW9uOiZuYnNwOyZuYnNwOyZuYnNwOyAwMCA8YnI+DQpUaXRsZTom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRGVmaW5pbmcgRWxsaXB0 aWMgQ3VydmUgQ3J5cHRvZ3JhcGh5IEFsZ29yaXRobXMgZm9yIHVzZSB3aXRoIERLSU0gPGJyPg0K RG9jdW1lbnQgZGF0ZTombmJzcDsmbmJzcDsmbmJzcDsgMjAxNy0wNC0wNiA8YnI+DQpHcm91cDom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSW5kaXZpZHVhbCBTdWJt aXNzaW9uIDxicj4NClBhZ2VzOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA2IDxicj4NClVSTDogPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfaW50ZXJuZXQtMkRkcmFmdHNfZHJh ZnQtMkRzcm9zZS0yRGRraW0tMkRlY2MtMkQwMC50eHQmYW1wO2Q9RHdNRGFRJmFtcDtjPUxGWVot bzlfSFVNZU1UU1FpY3ZqSWcmYW1wO3I9S3o4VmRnUFZjdEROU05QSjZQc0JhdyZhbXA7bT12Rm1F OXJhUlRJeGJYRWFrNC1oZ2s5ZGYycjJVUFBjUElLODNaVzhGWG4wJmFtcDtzPXUzRE81N3VPNWUz eWdBcEp5YkFURnZIX1Z2THFhMWsxQl95NWozc0pfeUkmYW1wO2U9Ij4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1zcm9zZS1ka2ltLWVjYy0wMC50eHQ8L2E+IDxi cj4NClN0YXR1czogPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy L3VybD91PWh0dHBzLTNBX19kYXRhdHJhY2tlci5pZXRmLm9yZ19kb2NfZHJhZnQtMkRzcm9zZS0y RGRraW0tMkRlY2NfJmFtcDtkPUR3TURhUSZhbXA7Yz1MRllaLW85X0hVTWVNVFNRaWN2aklnJmFt cDtyPUt6OFZkZ1BWY3RETlNOUEo2UHNCYXcmYW1wO209dkZtRTlyYVJUSXhiWEVhazQtaGdrOWRm MnIyVVBQY1BJSzgzWlc4RlhuMCZhbXA7cz1aMnlYdHlidWJSX0Vpa19yaVpiWjdGdWRqdnhEdDBE QjVoeVVSTXNNU2RRJmFtcDtlPSI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1zcm9zZS1ka2ltLWVjYy88L2E+IDxicj4NCkh0bWxpemVkOiA8YSBocmVmPSJodHRwczov L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYu b3JnX2h0bWxfZHJhZnQtMkRzcm9zZS0yRGRraW0tMkRlY2MtMkQwMCZhbXA7ZD1Ed01EYVEmYW1w O2M9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZhbXA7cj1LejhWZGdQVmN0RE5TTlBKNlBzQmF3JmFt cDttPXZGbUU5cmFSVEl4YlhFYWs0LWhnazlkZjJyMlVQUGNQSUs4M1pXOEZYbjAmYW1wO3M9Vzda S2NCMWQ3ekdFYmZram9vQ2d5SkhJOUt1c1JZVlFDcjlIc3haX2ZyMCZhbXA7ZT0iPg0KaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNyb3NlLWRraW0tZWNjLTAwPC9hPiA8YnI+DQpI dG1saXplZDogPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHBzLTNBX19kYXRhdHJhY2tlci5pZXRmLm9yZ19kb2NfaHRtbF9kcmFmdC0yRHNyb3Nl LTJEZGtpbS0yRGVjYy0yRDAwJmFtcDtkPUR3TURhUSZhbXA7Yz1MRllaLW85X0hVTWVNVFNRaWN2 aklnJmFtcDtyPUt6OFZkZ1BWY3RETlNOUEo2UHNCYXcmYW1wO209dkZtRTlyYVJUSXhiWEVhazQt aGdrOWRmMnIyVVBQY1BJSzgzWlc4RlhuMCZhbXA7cz1ZalBQQUZpRUVVT09CSXpyV1A3cmxQRTJu cEdyQkF3amljLVBnaVpnN3Q4JmFtcDtlPSI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9odG1sL2RyYWZ0LXNyb3NlLWRraW0tZWNjLTAwPC9hPiA8YnI+DQo8YnI+DQo8YnI+DQpB YnN0cmFjdDogPGJyPg0KJm5ic3A7Jm5ic3A7IERvbWFpbktleXMgSWRlbnRpZmllZCBNYWlsIChE S0lNKSB1c2VzIGRpZ2l0YWwgc2lnbmF0dXJlIHRvIGFzc29jaWF0ZSA8YnI+DQombmJzcDsmbmJz cDsgYSBtZXNzYWdlIHdpdGggYSBnaXZlbiBzZW5kaW5nIGRvbWFpbi4mbmJzcDsgQ3VycmVudGx5 LCB0aGVyZSBpcyBvbmx5IG9uZSA8YnI+DQombmJzcDsmbmJzcDsgY3J5cHRvZ3JhcGh5IGFsZ29y aXRobSBkZWZpbmVkIGZvciB1c2Ugd2l0aCBES0lNIChSU0EpLiZuYnNwOyBUaGlzIDxicj4NCiZu YnNwOyZuYnNwOyBkb2N1bWVudCBkZWZpbmVzIGZvdXIgbmV3IGVsbGlwdGljIGN1cnZlIGNyeXB0 b2dyYXBoeSBhbGdvcml0aG1zIGZvciA8YnI+DQombmJzcDsmbmJzcDsgdXNlIHdpdGggREtJTS4m bmJzcDsgVGhpcyB3aWxsIGFsbG93IGZvciBhbGdvcml0aG0gYWdpbGl0eSBpZiBhIHdlYWtuZXNz IDxicj4NCiZuYnNwOyZuYnNwOyBpcyBmb3VuZCBpbiBSU0EsIGFuZCBhbGxvd3MgZm9yIHNtYWxs ZXIga2V5IGxlbmd0aCB0byBwcm92aWRlIHRoZSA8YnI+DQombmJzcDsmbmJzcDsgc2FtZSBkaWdp dGFsIHNpZ25hdHVyZSBzdHJlbmd0aC4gPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_363EDD8B26544D81AD41D355599D3143attcom_-- From nobody Fri Apr 7 08:29: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 9610212773A for ; Fri, 7 Apr 2017 08:29:50 -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=SK/Xnzdv; dkim=pass (1536-bit key) header.d=taugh.com header.b=iz7eBwVJ 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 LJSn3rSSFBqP for ; Fri, 7 Apr 2017 08:29:49 -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 BDC01127444 for ; Fri, 7 Apr 2017 08:29:48 -0700 (PDT) Received: (qmail 90279 invoked from network); 7 Apr 2017 15:29:42 -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=160a5.58e7b066.k1704; bh=7GMtyiiqDPF0/0TDFeYR7wWmCRaq3KsPZBdEfHO6Hic=; b=SK/XnzdvCFAlz+nBStllQjeydE5oOxxcrfPTJ5q7MRweMiGNIWZM0SghcZpfhcPadpWUS5tAvXP67p2FlY/xWnGVMUvhjLxQgw4C8frSIOikxIQdrRFM0HCNvTS9gVpQh6tlAVrUMUpGDnH5xWl5ZALnlFxCdOoyslb7SS0tuAF2PxT1fFVCW9dMsb7tRQ6dsyhHGn5nO2qav2i/l/wvUyYC54qqFTnF5gfSiCftlPNeL8qlkEqeF+jERcSbJNaV 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=160a5.58e7b066.k1704; bh=7GMtyiiqDPF0/0TDFeYR7wWmCRaq3KsPZBdEfHO6Hic=; b=iz7eBwVJAd3XESO0Wmm5RQYKc+yB3VJTgm24BHxJdVvEYItF9U3vmpkZfFBJxII4Qk7OGUYQMvJtMi9LnqEcKm8FinhvZoPb9BwKPiL1zUdBdXRwmWmJGbILRZ18Skiz00fcBC1K+J2MCCveCfWyKBLHYDo3LQRHh//fTuNDH8g+QRHWbwWD9Df9l9ZNM7vsLRmz8ZL480teFPS5YhU87Jn4sdqre1SobPLM1PtoDPSt+JZM0mEueA9RShWhmrCK 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; 07 Apr 2017 15:29:42 -0000 Date: 7 Apr 2017 11:29:41 -0400 Message-ID: From: "John R Levine" To: "Brandon Long" Cc: "dmarc@ietf.org" In-Reply-To: References: <20170406235815.47843.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] Fwd: New Version Notification for draft-srose-dkim-ecc-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, 07 Apr 2017 15:29:50 -0000 > Should we add more hash algorithms? As far as I know SHA-256 is still adequate for the forseeable future, but I expect the crypto experts will weigh in. Ditto whether we really need three new algorithms since the more ways there are to sign, the more ways there are to have broken signatures. I'd rather pick a single ECC algorithm that is mathematically respectable and widely implemented. > Also, I'm very unclear of the benefit of the fp versions, adding nearly 400 > bytes per signature to the message seems expensive, and in the arc case, an > extra 800 bytes per hop (nearly doubling the size of each hop) seems like > an odd compromise. Maybe I'm being silly. This is only to work around the 256 byte TXT provisioning bugs. If your provisioning works, you can keep publishing keys the current way. I probably could be persuaded that if we're going to tell people to update their DKIM and ARC signing/verifying libraries, we should just tell them to add ECC crypto and the key length problems go away forever. R's, John From nobody Fri Apr 7 08:33: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 DA014128B38 for ; Fri, 7 Apr 2017 08:33:44 -0700 (PDT) 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, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 n8IMyvAPIdzO for ; Fri, 7 Apr 2017 08:33:42 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::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 EE532127444 for ; Fri, 7 Apr 2017 08:33:41 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id x35so63599799qtc.2 for ; Fri, 07 Apr 2017 08:33: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=UfzPRLsLSJadM/s/qHJXx05i0UdgvduKVz9B1OLBxXg=; b=EwIEiNvKwlh2vIkycHzk4tU0KXcSs7xebaBAtZEOlYM1AG6+gGIb5Gtsu+d7r7I/UC +W42kvBkGhm8TrpNZAN0e8E6pL/wAPX4Apnm0D586Zlnti6L55oszuICKoh0oU8Ho9ut lW4KTFMRNt3Z2UiATPrsp2HcpGki7AjWJzkjQYQpgN9dME3XWPSDPyfOeYWj5I/ljaWt bI8AIYK5G+EBu2Q34RY2yPdwQa1KwKI9l4+lhf8QfwX5Y3WmWiaqMZGJ6rjXNzGuphW+ aZQhTdmRzwq9gvtyQe3RT/LNCXp5CWU9bgw8lWSHgcrVcu84T7PFKnqiG1wuaIODHMuK xnVQ== 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=UfzPRLsLSJadM/s/qHJXx05i0UdgvduKVz9B1OLBxXg=; b=j1YE+NXb8nPt+S0ejDaQA4ixYetrj2w0mDEdhMAtebnOKKa3/RO0d7q0fREk86xopA xU636y/mbypALh3a1hJtKx3XMh7yHcCwshsAKC+Ikt8RaiFjghVaYmQL8WzYg/Isy7UN 7DVMYzqqYk+BfBJLHPkhiPgmu2WtGMKMG2EZldAXo4JOZ8Q2zV5t50oZy5IjMZyFXc+Y Vk0+rXgB2OfEs492f5H9OKHCk/BngEVWiCl9bZIMkFHkSII/aFcG1K5NT0zCm0se2lzX yhTxoBQq3JdHDJtwc6ZTX26wQ3beAyg25FNWZylGC3LQSsGaufQ7rGT7hsrIDH7/snWx oIdA== X-Gm-Message-State: AN3rC/5ci8z5bPfKUYcPaVZE2qFGD9ALEEuEDo/UiLMS+rMYyIIRVFY6gUgHVA8Ko/6QVxEe/3fryMvYzvKLOQ== X-Received: by 10.200.53.45 with SMTP id y42mr3676414qtb.136.1491579220990; Fri, 07 Apr 2017 08:33:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.141.207 with HTTP; Fri, 7 Apr 2017 08:33:40 -0700 (PDT) In-Reply-To: <20170406235815.47843.qmail@ary.lan> References: <20170406235815.47843.qmail@ary.lan> From: Peter Goldstein Date: Fri, 7 Apr 2017 08:33:40 -0700 Message-ID: To: John Levine Cc: dmarc , Vladimir Dubrovin Content-Type: multipart/alternative; boundary=001a11403cc89f436e054c9559e6 Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-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, 07 Apr 2017 15:33:45 -0000 --001a11403cc89f436e054c9559e6 Content-Type: text/plain; charset=UTF-8 John, Really glad to see this. Does this initiative include an intention to update the cryptographic guidance from RFC 6376 sections 3.3 and 3.3.3 ? The proposed charter speaks of adding new algorithms, but doesn't discuss deprecating/removing old ones. Some specific concerns are: 1. Expressly forbidding RSA keys < 1024 bits in size - While the fact that some major receivers ignore such keys has made this a de facto standard, it would be good for the RFCs to reflect best practice here. And as we saw with the ARC discussion, using the DKIM spec as a reference can inadvertently result in new standards supporting known insecure practices. 2. Eliminating SHA-1 - Even at the time of publication RFC 6376 recommended that signers avoid the use of SHA-1. Despite this, a simple check of my inbox shows that quite a few senders - including a number of large, sophisticated ESPs - still use SHA-1 in preference to SHA-256. While the recent developed PDF collision attack against SHA-1 is not entirely on point, it seems to be further evidence that SHA-1 should not be used. And given the widespread support for SHA-256, this seems like it's mostly a configuration issue for senders. If these items don't belong in the charter for the new group, do they have a different natural home for discussion? Thanks. Best, Peter On Thu, Apr 6, 2017 at 4:58 PM, John Levine wrote: > >1. produce 2 different DKIM-Signatures with 2 different selectors: > >slector1 with SHA-1 + RSA and selector2 one with SHA-512 + ECDSA > > Of course. > > >2. add an additional field to either selector1 DKIM DNS record (need to > >consult RFC if it's allowed) or to DKIM-Signature with selector1 (it's > >allowed but probably is not enough to protect against downgrade) to > >indicate the selector is legacy-only, e.g. o=sha512/eccp256 to indicate > >this selector should be ignored if verifier supports sha-512 and eccp256. > > No. If the verifier is smart enough to understand new algorithms, it > is smart enough to figure out which signature to prefer. Also keep in > mind that the legacy crypto is sha256/rsa1024 which is plenty strong > for the forseeable future. > > 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 --001a11403cc89f436e054c9559e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
John,

Really glad to see this. =C2=A0

Does this initiative include an intention to update= the cryptographic guidance from RFC 6376 sections 3.3 and 3.3.3 ?=C2=A0 Th= e proposed charter speaks of adding new algorithms, but doesn't discuss= deprecating/removing old ones.

Some specific conc= erns are:

1. Expressly forbidding RSA keys < 10= 24 bits in size - While the fact that some major receivers ignore such keys= has made this a de facto standard, it would be good for the RFCs to reflec= t best practice here.=C2=A0 And as we saw with the ARC discussion, using th= e DKIM spec as a reference can inadvertently result in new standards suppor= ting known insecure practices. =C2=A0

2. Eliminati= ng SHA-1 - Even at the time of publication RFC 6376 recommended that signer= s avoid the use of SHA-1.=C2=A0 Despite this, a simple check of my inbox sh= ows that quite a few senders - including a number of large, sophisticated E= SPs - still use SHA-1 in preference to SHA-256.=C2=A0 While the recent deve= loped PDF collision attack against SHA-1 is not entirely on point, it seems= to be further evidence that SHA-1 should not be used.=C2=A0 And given the = widespread support for SHA-256, this seems like it's mostly a configura= tion issue for senders.

If these items don't b= elong in the charter for the new group, do they have a different natural ho= me for discussion?

Thanks.

Best,

Peter

On Thu, Apr 6, 2017 at 4:58 PM, = John Levine <johnl@taugh.com> wrote:
>1. produce 2 different DKIM-Signatures with 2= different selectors:
>slector1=C2=A0 with SHA-1 + RSA and selector2 one with=C2=A0 SHA-512 + = ECDSA

Of course.

>2. add an additional field to either selector1 DKIM DNS record (need to=
>consult RFC if it's allowed) or to DKIM-Signature with selector1 (i= t's
>allowed but probably is not enough to protect against downgrade) to
>indicate the selector is legacy-only, e.g. o=3Dsha512/eccp256 to indica= te
>this selector should be ignored if verifier supports sha-512 and eccp25= 6.

No.=C2=A0 If the verifier is smart enough to understand new algorith= ms, it
is smart enough to figure out which signature to prefer.=C2=A0 Also keep in=
mind that the legacy crypto is sha256/rsa1024 which is plenty strong
for the forseeable future.

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>
--001a11403cc89f436e054c9559e6-- From nobody Fri Apr 7 08:34: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 AEF3E129449 for ; Fri, 7 Apr 2017 08:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=R2jV/GxS; dkim=pass (1536-bit key) header.d=taugh.com header.b=qGszuWw2 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 oKmmOiE7mZii for ; Fri, 7 Apr 2017 08:34:15 -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 9B4D912773A for ; Fri, 7 Apr 2017 08:34:15 -0700 (PDT) Received: (qmail 91040 invoked from network); 7 Apr 2017 15:34:09 -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=1639e.58e7b171.k1704; bh=VnUeNaWj9f7CV+ts0aEFS0qjyMSfMavnhHfhXalUwXE=; b=R2jV/GxSJK8xNTN4a7Ghd/F+z/vVOD9OhRc2PKQo8SD1kne4NQ++FID1AsNLFx0q7R8114MQPhdl5RZwo/iCXblih6gKjqgEvsDEGAIxQh7ub7Ql1wzGSnOYgV/LWLcDK/AFKTgpsujfLh4BFLMQdbMfjxas8woTaoaw4DLw36YeIfcS9IBzUdtB9alIMhxfk1HDmw7r6zF0kOIKGSrjIa4SIRv0fA8RZU8sEqD4hu94Vx2RqyOFbybQ+4dCQ+mY 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=1639e.58e7b171.k1704; bh=VnUeNaWj9f7CV+ts0aEFS0qjyMSfMavnhHfhXalUwXE=; b=qGszuWw2wV2nDJz8fpmvuRCy+PnZfRU2SPJ/W8TLH6oFJCNthXH6686vuqNKDPyor5GDM1cn1+mOW/VQ169+m0TwJUFcmmsEz/Pp0pVkAq9FSe0Dr26uQorajI3rqegIdmEomKOilzMXndSNfgk0c6JeFlpKqRzMFQBKrrscWMGYkdoQrImeWt2gnjoBeH5GmiIlAtZ8ZVFHh+WzvLpE0U0AU5g1Oa62YDdlyT+tqLj6YKO+oFdHmpGU/xXkbwi9 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; 07 Apr 2017 15:34:09 -0000 Date: 7 Apr 2017 11:34:08 -0400 Message-ID: From: "John R Levine" To: "Scott Rose" Cc: dmarc@ietf.org In-Reply-To: References: <20170406235540.47811.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] Fwd: New Version Notification for draft-srose-dkim-ecc-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, 07 Apr 2017 15:34:18 -0000 > Ok - nice to know I'm not the only one thinking this (means I'm not totally > crazy). I'm willing to drop my draft and just contribute/review this one. > There is no reason to have multiple drafts trying to do the same thing. No, don't, we can moosh them together. I don't know much about elliptic crypto and could use some advice about which algorithms are widely implemented and which are likely to be used for a long time. > > Scott > > > On 04/06/2017 07:55 PM, John Levine wrote: >> In article you write: >>> This may be of interest to this group, as there isn't an active DKIM WG >>> anymore. >> At the DISPATCH session at IETF 98 I pitched a proposal to update DKIM >> with a new crypto algorithm and/or a more compact key representation >> (put the key in the signature and put a hash of it in the DNS.) >> >> Reaction was positive, people told me to write a proposed charter, >> which starts here: >> >> https://www.ietf.org/mail-archive/web/dispatch/current/msg06701.html >> >> Also see: >> >> https://datatracker.ietf.org/doc/draft-levine-dcrup-dkim-crypto/ >> >> R's, >> John > > Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Fri Apr 7 08:48: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 EAA4112940A for ; Fri, 7 Apr 2017 08:48:35 -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=SEpr7os+; dkim=pass (1536-bit key) header.d=taugh.com header.b=GCJlLg5P 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 inPPateg8JV3 for ; Fri, 7 Apr 2017 08:48:34 -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 42C761294C2 for ; Fri, 7 Apr 2017 08:48:33 -0700 (PDT) Received: (qmail 92633 invoked from network); 7 Apr 2017 15:48:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=169d7.58e7b4c6.k1704; bh=oMI4vBkQL8DVM4fDu6YWBifQYQZWf3prUDVVohpuDiM=; b=SEpr7os+OWBQUdW6BzHJIz1atGx/gnUcbRiWH4YSx14QzJrrk2mmC3oZE7Hmk6VWgGGrXdaIxdE3hPYoLxPxClVOmA3DP5PuNZ/BrllR8D1ki97qYdzIGKsktz81h/hMSkEGQJc12PEHQMor4MAm73H6YNyNi0xkEh9qePdMLUh2iZLlqCAGeJrkQzacAiwDawV5XQhzqaa2Vt2VOqkP7qxJx65iQ0PgnZUt/c1s3t/vA/1TUtzMUfBQPyJ0N4DK 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=169d7.58e7b4c6.k1704; bh=oMI4vBkQL8DVM4fDu6YWBifQYQZWf3prUDVVohpuDiM=; b=GCJlLg5PjJqqwxyvToA3oCtJ3vwWgaQaJinvt73WSHeRXzb9cirnIO9IPidI5A/OrmaWNbSSbZbyPl+le5fSyAp4o3ddYEZ2mlVgLWKB+6tvHZM93Csdavv+lmxFJjwpq+I0LDJ44i436wvVeeLdArcsRrYgrE278kDHHt7eXtJ4PJKCh/2HFZoePG9eRJ9Op+VFJ7Q/CtFTVbeYxvM1DzHfAluEZRDnbQ4IQDpvpus6Ry8fr3J5tFtOHkkiQ4Rj 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; 07 Apr 2017 15:48:22 -0000 Date: 7 Apr 2017 11:48:22 -0400 Message-ID: From: "John R Levine" To: "Peter Goldstein" Cc: "dmarc" In-Reply-To: References: <20170406235815.47843.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] Fwd: New Version Notification for draft-srose-dkim-ecc-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, 07 Apr 2017 15:48:36 -0000 > Does this initiative include an intention to update the cryptographic > guidance from RFC 6376 sections 3.3 and 3.3.3 ? The proposed charter > speaks of adding new algorithms, but doesn't discuss deprecating/removing > old ones. We haven't decided yet. I'd think that'd be something DCRUP could consider. R's, John From nobody Fri Apr 7 09:27: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 17841120725 for ; Fri, 7 Apr 2017 09:27:02 -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 wZpl6J5SyN5c for ; Fri, 7 Apr 2017 09:27:00 -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 2E8A11294E1 for ; Fri, 7 Apr 2017 09:26:29 -0700 (PDT) Received: (qmail 99098 invoked from network); 7 Apr 2017 16:26:23 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 7 Apr 2017 16:26:23 -0000 Date: 7 Apr 2017 16:26:01 -0000 Message-ID: <20170407162601.50961.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org Cc: federico.santandrea@diennea.com In-Reply-To: <30f3baa9-f13b-91b4-c931-a2fb6858243a@diennea.com> 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] Fwd: New Version Notification for draft-srose-dkim-ecc-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, 07 Apr 2017 16:27:02 -0000 In article <30f3baa9-f13b-91b4-c931-a2fb6858243a@diennea.com> you write: >If we want to put a meaningful value in this new field, I think it would >be more useful to make it the time since when the key was obsoleted, >this would allow for mail dated before that moment (which was correctly >signed only with then-not-obsolete keys) to pass verification. This >should be optional, so one could choose if he rather have some valid >mail fail verification, or risk some invalid back-dated mail pass >verification. Good lord, no. That's why DKIM has key rotation. R's, John From nobody Fri Apr 7 11:39:36 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 410F4129531 for ; Fri, 7 Apr 2017 11:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=microsoft.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 GrGv6bqAqqup for ; Fri, 7 Apr 2017 11:39:32 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0111.outbound.protection.outlook.com [104.47.33.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6239012420B for ; Fri, 7 Apr 2017 11:39:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=T2lJELYG//xTnommfZKxH214ZxF4kEqj9X4Q02hTlzQ=; b=gMNSJrYjt6rM7xzPLrufS1TZZV5X91glCq79uGE/fIxWdJUHL3JLYCCqXj0bDW6CN19VN3+2uFdNNzNYQysIg6shiQSwUZQa06YsBv2Fhon70P8X3A5Ejg2IacFn6aHHClQffztu71JcdoNMntyA7Qy8tUDw3sAgrrfWxDK5S9w= Received: from CO2PR00MB0120.namprd00.prod.outlook.com (10.166.215.146) by CO2PR00MB0085.namprd00.prod.outlook.com (10.166.215.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1040.0; Fri, 7 Apr 2017 18:39:28 +0000 Received: from CO2PR00MB0120.namprd00.prod.outlook.com ([fe80::8c90:54be:9fcd:6b3]) by CO2PR00MB0120.namprd00.prod.outlook.com ([fe80::8c90:54be:9fcd:6b3%17]) with mapi id 15.01.1047.000; Fri, 7 Apr 2017 18:39:28 +0000 From: Terry Zink To: dmarc Thread-Topic: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-00.txt Thread-Index: AQHSrvvOyQ+FrKz9u02ZIuxAV1lyN6G422kAgAAp7oCAAQVbAIAAMfzA Date: Fri, 7 Apr 2017 18:39:28 +0000 Message-ID: References: <20170406235815.47843.qmail@ary.lan> In-Reply-To: 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: [131.107.159.204] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CO2PR00MB0085; 7:AS9Db6hEMO47ogQyTVuzyqAOqWPoWNewUL9TzSZ5VR7Lqnsx3pNT57omv5I2KDxEhnJVRlFZeiqmMw4CbqWo+07Nuh5kdTnP1A/1uhWm6hTO+fa5xnIQRC4EUTCm5Z4pwCEVe/xuKIOFZH1VLL6yWn39idH2+7M3jEkjvBOx4CVYBPQhnRFEJnDbrtyVI/28fY/7a5C7f2tMZXlrvhVOWaJdOHn4m/P4cXv+kOhCPBapQNHLpWp7+Qle0zjtpnEiQFOM8E2t6VUrXt9HjgX9jJsKQGKLtFRqCX25lJFJJ7kiteSCisIJJhXCBzH5CIVRpA5jQPwdHu+z82w5kcK7XxHiNI43LDCZUxwfj0XkL0Q= x-ms-office365-filtering-correlation-id: 7180ae13-e0ba-4377-ab78-08d47de56c3d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:CO2PR00MB0085; x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(268704632989789)(120376859493423)(259971544884247)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(6072148); SRVR:CO2PR00MB0085; BCL:0; PCL:0; RULEID:; SRVR:CO2PR00MB0085; x-forefront-prvs: 0270ED2845 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39400400002)(39410400002)(39450400003)(39850400002)(39840400002)(39860400002)(24454002)(377454003)(3905003)(66066001)(230783001)(53546009)(5660300001)(110136004)(38730400002)(25786009)(10710500007)(2906002)(10090500001)(5250100002)(5005710100001)(10290500002)(189998001)(3280700002)(790700001)(6436002)(6116002)(3846002)(3660700001)(102836003)(606005)(76176999)(54356999)(6506006)(50986999)(733005)(6916009)(2950100002)(7696004)(7736002)(86362001)(236005)(53936002)(7906003)(6246003)(74316002)(6306002)(9686003)(54896002)(33656002)(86612001)(55016002)(99286003)(8936002)(15650500001)(2420400007)(19609705001)(8676002)(81166006)(53330200001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR00MB0085; H:CO2PR00MB0120.namprd00.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CO2PR00MB01203E4C66FD0D68137CAB91A30C0CO2PR00MB0120namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2017 18:39:28.0834 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR00MB0085 Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-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, 07 Apr 2017 18:39:35 -0000 --_000_CO2PR00MB01203E4C66FD0D68137CAB91A30C0CO2PR00MB0120namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T25lIHJlYXNvbiB0cmFuc2l0aW9ucyBhcmUgZGlmZmljdWx0IGJlY2F1c2Ugb2YgaW1wbGVtZW50 YXRpb24gYW5kIGRlcHJlY2F0aW9uIGFtYmlndWl0eS4gSWYgdGhlcmXigJlzIG5vIHJlYXNvbiB0 byBtb3ZlIG90aGVyIHRoYW4gYmVzdCBwcmFjdGljZSwgdGhlbiBubyBvbmUgd2lsbCAob3Igbm90 IGVub3VnaCB3aWxsIG1vdmUpLg0KDQpNYXliZSB3ZSBjYW4gYnVpbGQgdGltZWxpbmVzIGludG8g dGhlIHVwZGF0ZXMuIEJ5IEphbiAxLCAyMDE5LCByZWNlaXZlcnMgU0hPVUxEIChNVVNUPykgbm8g bG9uZ2VyIHN1cHBvcnQgdGhlIGZvbGxvd2luZyBrZXkgc2l6ZXMgb3IgYWxnb3JpdGhtcy4gVGhh dCB3YXksIGlmIGFueW9uZSBjb21wbGFpbnMgdGhhdCBhIHBhcnRpY3VsYXIgREtJTS1zaWduYXR1 cmUgaXMgbm90IGNvbnNpZGVyZWQgdmFsaWQsIHdlIGNhbiBhbHdheXMgc2F5IGl04oCZcyBSRkMg bm9uLWNvbXBsaWFudC4NCg0KRm9yIGV4YW1wbGUsIGZvciBzdXBwb3J0ZWQgVExTIGNpcGhlcnMs IE1pY3Jvc29mdCBPZmZpY2UgMzY1IHB1Ymxpc2hlcyB3aGF0IGFsZ29yaXRobXMgYXJlIHN1cHBv cnRlZCwgYWxvbmcgd2l0aCB0aW1lbGluZXMgZm9yIGRlcHJlY2F0aW9uOiBodHRwczovL3RlY2hu ZXQubWljcm9zb2Z0LmNvbS9lbi11cy9saWJyYXJ5L2RuNTY5Mjg2LmFzcHguIElmIHNlbmRlcnMg aGF2ZSBwcm9ibGVtcyB3aXRoIFRMUyBjb25uZWN0aW9ucywgd2UgcG9pbnQgdGhlbSB0byB0aGF0 IGRvY3VtZW50YXRpb24uIE5vdCBldmVyeW9uZSByZWFkcyB0aGUgZG9jdW1lbnRhdGlvbiwgYnV0 IGl0IGlzIHRoZSB3YXkgd2UgYWR2ZXJ0aXNlIHRvIHRoZSB3b3JsZCB3aGF0IHdlIGRvIGFuZCBk b27igJl0IHN1cHBvcnQuDQoNCi0tVGVycnkNCg0KRnJvbTogZG1hcmMgW21haWx0bzpkbWFyYy1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUGV0ZXIgR29sZHN0ZWluDQpTZW50OiBGcmlk YXksIEFwcmlsIDcsIDIwMTcgODozNCBBTQ0KVG86IEpvaG4gTGV2aW5lIDxqb2hubEB0YXVnaC5j b20+DQpDYzogZG1hcmMgPGRtYXJjQGlldGYub3JnPjsgVmxhZGltaXIgRHVicm92aW4gPGR1YnJv dmluQGNvcnAubWFpbC5ydT4NClN1YmplY3Q6IFJlOiBbZG1hcmMtaWV0Zl0gRndkOiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXNyb3NlLWRraW0tZWNjLTAwLnR4dA0KDQpKb2hu LA0KDQpSZWFsbHkgZ2xhZCB0byBzZWUgdGhpcy4NCg0KRG9lcyB0aGlzIGluaXRpYXRpdmUgaW5j bHVkZSBhbiBpbnRlbnRpb24gdG8gdXBkYXRlIHRoZSBjcnlwdG9ncmFwaGljIGd1aWRhbmNlIGZy b20gUkZDIDYzNzYgc2VjdGlvbnMgMy4zIGFuZCAzLjMuMyA/ICBUaGUgcHJvcG9zZWQgY2hhcnRl ciBzcGVha3Mgb2YgYWRkaW5nIG5ldyBhbGdvcml0aG1zLCBidXQgZG9lc24ndCBkaXNjdXNzIGRl cHJlY2F0aW5nL3JlbW92aW5nIG9sZCBvbmVzLg0KDQpTb21lIHNwZWNpZmljIGNvbmNlcm5zIGFy ZToNCg0KMS4gRXhwcmVzc2x5IGZvcmJpZGRpbmcgUlNBIGtleXMgPCAxMDI0IGJpdHMgaW4gc2l6 ZSAtIFdoaWxlIHRoZSBmYWN0IHRoYXQgc29tZSBtYWpvciByZWNlaXZlcnMgaWdub3JlIHN1Y2gg a2V5cyBoYXMgbWFkZSB0aGlzIGEgZGUgZmFjdG8gc3RhbmRhcmQsIGl0IHdvdWxkIGJlIGdvb2Qg Zm9yIHRoZSBSRkNzIHRvIHJlZmxlY3QgYmVzdCBwcmFjdGljZSBoZXJlLiAgQW5kIGFzIHdlIHNh dyB3aXRoIHRoZSBBUkMgZGlzY3Vzc2lvbiwgdXNpbmcgdGhlIERLSU0gc3BlYyBhcyBhIHJlZmVy ZW5jZSBjYW4gaW5hZHZlcnRlbnRseSByZXN1bHQgaW4gbmV3IHN0YW5kYXJkcyBzdXBwb3J0aW5n IGtub3duIGluc2VjdXJlIHByYWN0aWNlcy4NCg0KMi4gRWxpbWluYXRpbmcgU0hBLTEgLSBFdmVu IGF0IHRoZSB0aW1lIG9mIHB1YmxpY2F0aW9uIFJGQyA2Mzc2IHJlY29tbWVuZGVkIHRoYXQgc2ln bmVycyBhdm9pZCB0aGUgdXNlIG9mIFNIQS0xLiAgRGVzcGl0ZSB0aGlzLCBhIHNpbXBsZSBjaGVj ayBvZiBteSBpbmJveCBzaG93cyB0aGF0IHF1aXRlIGEgZmV3IHNlbmRlcnMgLSBpbmNsdWRpbmcg YSBudW1iZXIgb2YgbGFyZ2UsIHNvcGhpc3RpY2F0ZWQgRVNQcyAtIHN0aWxsIHVzZSBTSEEtMSBp biBwcmVmZXJlbmNlIHRvIFNIQS0yNTYuICBXaGlsZSB0aGUgcmVjZW50IGRldmVsb3BlZCBQREYg Y29sbGlzaW9uIGF0dGFjayBhZ2FpbnN0IFNIQS0xIGlzIG5vdCBlbnRpcmVseSBvbiBwb2ludCwg aXQgc2VlbXMgdG8gYmUgZnVydGhlciBldmlkZW5jZSB0aGF0IFNIQS0xIHNob3VsZCBub3QgYmUg dXNlZC4gIEFuZCBnaXZlbiB0aGUgd2lkZXNwcmVhZCBzdXBwb3J0IGZvciBTSEEtMjU2LCB0aGlz IHNlZW1zIGxpa2UgaXQncyBtb3N0bHkgYSBjb25maWd1cmF0aW9uIGlzc3VlIGZvciBzZW5kZXJz Lg0KDQpJZiB0aGVzZSBpdGVtcyBkb24ndCBiZWxvbmcgaW4gdGhlIGNoYXJ0ZXIgZm9yIHRoZSBu ZXcgZ3JvdXAsIGRvIHRoZXkgaGF2ZSBhIGRpZmZlcmVudCBuYXR1cmFsIGhvbWUgZm9yIGRpc2N1 c3Npb24/DQoNClRoYW5rcy4NCg0KQmVzdCwNCg0KUGV0ZXINCltodHRwczovL3QueWVzd2FyZS5j b20vdC9kNTFlNjNkZjQ4M2M0ZjFiZjMyYjQ3MjI5ODE0YmEzZjNiMTNmZTQ0LzMyYTQ4MGEyYTA1 ZDAwNjVmZTVjZTkyMmI2ZDJkMDMyL3NwYWNlci5naWZdW2h0dHA6Ly90Lnllc3dhcmUuY29tL3Qv ZDUxZTYzZGY0ODNjNGYxYmYzMmI0NzIyOTgxNGJhM2YzYjEzZmU0NC8zMmE0ODBhMmEwNWQwMDY1 ZmU1Y2U5MjJiNmQyZDAzMi9zcGFjZXIuZ2lmXQ0KDQpPbiBUaHUsIEFwciA2LCAyMDE3IGF0IDQ6 NTggUE0sIEpvaG4gTGV2aW5lIDxqb2hubEB0YXVnaC5jb208bWFpbHRvOmpvaG5sQHRhdWdoLmNv bT4+IHdyb3RlOg0KPjEuIHByb2R1Y2UgMiBkaWZmZXJlbnQgREtJTS1TaWduYXR1cmVzIHdpdGgg MiBkaWZmZXJlbnQgc2VsZWN0b3JzOg0KPnNsZWN0b3IxICB3aXRoIFNIQS0xICsgUlNBIGFuZCBz ZWxlY3RvcjIgb25lIHdpdGggIFNIQS01MTIgKyBFQ0RTQQ0KDQpPZiBjb3Vyc2UuDQoNCj4yLiBh ZGQgYW4gYWRkaXRpb25hbCBmaWVsZCB0byBlaXRoZXIgc2VsZWN0b3IxIERLSU0gRE5TIHJlY29y ZCAobmVlZCB0bw0KPmNvbnN1bHQgUkZDIGlmIGl0J3MgYWxsb3dlZCkgb3IgdG8gREtJTS1TaWdu YXR1cmUgd2l0aCBzZWxlY3RvcjEgKGl0J3MNCj5hbGxvd2VkIGJ1dCBwcm9iYWJseSBpcyBub3Qg ZW5vdWdoIHRvIHByb3RlY3QgYWdhaW5zdCBkb3duZ3JhZGUpIHRvDQo+aW5kaWNhdGUgdGhlIHNl bGVjdG9yIGlzIGxlZ2FjeS1vbmx5LCBlLmcuIG89c2hhNTEyL2VjY3AyNTYgdG8gaW5kaWNhdGUN Cj50aGlzIHNlbGVjdG9yIHNob3VsZCBiZSBpZ25vcmVkIGlmIHZlcmlmaWVyIHN1cHBvcnRzIHNo YS01MTIgYW5kIGVjY3AyNTYuDQoNCk5vLiAgSWYgdGhlIHZlcmlmaWVyIGlzIHNtYXJ0IGVub3Vn aCB0byB1bmRlcnN0YW5kIG5ldyBhbGdvcml0aG1zLCBpdA0KaXMgc21hcnQgZW5vdWdoIHRvIGZp Z3VyZSBvdXQgd2hpY2ggc2lnbmF0dXJlIHRvIHByZWZlci4gIEFsc28ga2VlcCBpbg0KbWluZCB0 aGF0IHRoZSBsZWdhY3kgY3J5cHRvIGlzIHNoYTI1Ni9yc2ExMDI0IHdoaWNoIGlzIHBsZW50eSBz dHJvbmcNCmZvciB0aGUgZm9yc2VlYWJsZSBmdXR1cmUuDQoNClIncywNCkpvaG4NCg== --_000_CO2PR00MB01203E4C66FD0D68137CAB91A30C0CO2PR00MB0120namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29u b3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTpt c29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVt YWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T25lIHJlYXNvbiB0cmFuc2l0aW9ucyBhcmUgZGlmZmljdWx0IGJlY2F1 c2Ugb2YgaW1wbGVtZW50YXRpb24gYW5kIGRlcHJlY2F0aW9uIGFtYmlndWl0eS4gSWYgdGhlcmXi gJlzIG5vIHJlYXNvbiB0byBtb3ZlIG90aGVyIHRoYW4gYmVzdCBwcmFjdGljZSwgdGhlbiBubyBv bmUgd2lsbCAob3Igbm90IGVub3VnaCB3aWxsIG1vdmUpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5NYXliZSB3ZSBjYW4gYnVpbGQgdGltZWxpbmVzIGludG8gdGhlIHVwZGF0ZXMuIEJ5IEphbiAx LCAyMDE5LCByZWNlaXZlcnMgU0hPVUxEIChNVVNUPykgbm8gbG9uZ2VyIHN1cHBvcnQgdGhlIGZv bGxvd2luZyBrZXkgc2l6ZXMgb3IgYWxnb3JpdGhtcy4gVGhhdCB3YXksIGlmIGFueW9uZSBjb21w bGFpbnMgdGhhdCBhIHBhcnRpY3VsYXIgREtJTS1zaWduYXR1cmUgaXMgbm90IGNvbnNpZGVyZWQg dmFsaWQsIHdlDQogY2FuIGFsd2F5cyBzYXkgaXTigJlzIFJGQyBub24tY29tcGxpYW50LjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3IgZXhhbXBsZSwgZm9yIHN1cHBvcnRlZCBUTFMgY2lwaGVy cywgTWljcm9zb2Z0IE9mZmljZSAzNjUgcHVibGlzaGVzIHdoYXQgYWxnb3JpdGhtcyBhcmUgc3Vw cG9ydGVkLCBhbG9uZyB3aXRoIHRpbWVsaW5lcyBmb3IgZGVwcmVjYXRpb246DQo8YSBocmVmPSJo dHRwczovL3RlY2huZXQubWljcm9zb2Z0LmNvbS9lbi11cy9saWJyYXJ5L2RuNTY5Mjg2LmFzcHgi Pmh0dHBzOi8vdGVjaG5ldC5taWNyb3NvZnQuY29tL2VuLXVzL2xpYnJhcnkvZG41NjkyODYuYXNw eDwvYT4uIElmIHNlbmRlcnMgaGF2ZSBwcm9ibGVtcyB3aXRoIFRMUyBjb25uZWN0aW9ucywgd2Ug cG9pbnQgdGhlbSB0byB0aGF0IGRvY3VtZW50YXRpb24uIE5vdCBldmVyeW9uZSByZWFkcyB0aGUg ZG9jdW1lbnRhdGlvbiwgYnV0DQogaXQgaXMgdGhlIHdheSB3ZSBhZHZlcnRpc2UgdG8gdGhlIHdv cmxkIHdoYXQgd2UgZG8gYW5kIGRvbuKAmXQgc3VwcG9ydC48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj4tLVRlcnJ5PG86cD48L286cD48L2E+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENv bXBvc2UiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxzcGFuIHN0eWxlPSJtc28tYm9v a21hcms6X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5G cm9tOjwvYj4gZG1hcmMgW21haWx0bzpkbWFyYy1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhh bGYgT2YNCjwvYj5QZXRlciBHb2xkc3RlaW48YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBBcHJp bCA3LCAyMDE3IDg6MzQgQU08YnI+DQo8Yj5Ubzo8L2I+IEpvaG4gTGV2aW5lICZsdDtqb2hubEB0 YXVnaC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBkbWFyYyAmbHQ7ZG1hcmNAaWV0Zi5vcmcmZ3Q7 OyBWbGFkaW1pciBEdWJyb3ZpbiAmbHQ7ZHVicm92aW5AY29ycC5tYWlsLnJ1Jmd0Ozxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW2RtYXJjLWlldGZdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1zcm9zZS1ka2ltLWVjYy0wMC50eHQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkpvaG4sPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5SZWFsbHkgZ2xhZCB0byBzZWUgdGhpcy4gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvZXMgdGhpcyBpbml0aWF0aXZlIGlu Y2x1ZGUgYW4gaW50ZW50aW9uIHRvIHVwZGF0ZSB0aGUgY3J5cHRvZ3JhcGhpYyBndWlkYW5jZSBm cm9tIFJGQyA2Mzc2IHNlY3Rpb25zIDMuMyBhbmQgMy4zLjMgPyZuYnNwOyBUaGUgcHJvcG9zZWQg Y2hhcnRlciBzcGVha3Mgb2YgYWRkaW5nIG5ldyBhbGdvcml0aG1zLCBidXQgZG9lc24ndCBkaXNj dXNzIGRlcHJlY2F0aW5nL3JlbW92aW5nIG9sZCBvbmVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Tb21lIHNwZWNpZmljIGNvbmNlcm5zIGFy ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ MS4gRXhwcmVzc2x5IGZvcmJpZGRpbmcgUlNBIGtleXMgJmx0OyAxMDI0IGJpdHMgaW4gc2l6ZSAt IFdoaWxlIHRoZSBmYWN0IHRoYXQgc29tZSBtYWpvciByZWNlaXZlcnMgaWdub3JlIHN1Y2gga2V5 cyBoYXMgbWFkZSB0aGlzIGEgZGUgZmFjdG8gc3RhbmRhcmQsIGl0IHdvdWxkIGJlIGdvb2QgZm9y IHRoZSBSRkNzIHRvIHJlZmxlY3QgYmVzdCBwcmFjdGljZSBoZXJlLiZuYnNwOyBBbmQgYXMgd2Ug c2F3IHdpdGggdGhlIEFSQw0KIGRpc2N1c3Npb24sIHVzaW5nIHRoZSBES0lNIHNwZWMgYXMgYSBy ZWZlcmVuY2UgY2FuIGluYWR2ZXJ0ZW50bHkgcmVzdWx0IGluIG5ldyBzdGFuZGFyZHMgc3VwcG9y dGluZyBrbm93biBpbnNlY3VyZSBwcmFjdGljZXMuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yLiBFbGltaW5hdGluZyBTSEEtMSAt IEV2ZW4gYXQgdGhlIHRpbWUgb2YgcHVibGljYXRpb24gUkZDIDYzNzYgcmVjb21tZW5kZWQgdGhh dCBzaWduZXJzIGF2b2lkIHRoZSB1c2Ugb2YgU0hBLTEuJm5ic3A7IERlc3BpdGUgdGhpcywgYSBz aW1wbGUgY2hlY2sgb2YgbXkgaW5ib3ggc2hvd3MgdGhhdCBxdWl0ZSBhIGZldyBzZW5kZXJzIC0g aW5jbHVkaW5nIGEgbnVtYmVyIG9mIGxhcmdlLCBzb3BoaXN0aWNhdGVkIEVTUHMNCiAtIHN0aWxs IHVzZSBTSEEtMSBpbiBwcmVmZXJlbmNlIHRvIFNIQS0yNTYuJm5ic3A7IFdoaWxlIHRoZSByZWNl bnQgZGV2ZWxvcGVkIFBERiBjb2xsaXNpb24gYXR0YWNrIGFnYWluc3QgU0hBLTEgaXMgbm90IGVu dGlyZWx5IG9uIHBvaW50LCBpdCBzZWVtcyB0byBiZSBmdXJ0aGVyIGV2aWRlbmNlIHRoYXQgU0hB LTEgc2hvdWxkIG5vdCBiZSB1c2VkLiZuYnNwOyBBbmQgZ2l2ZW4gdGhlIHdpZGVzcHJlYWQgc3Vw cG9ydCBmb3IgU0hBLTI1NiwgdGhpcyBzZWVtcyBsaWtlDQogaXQncyBtb3N0bHkgYSBjb25maWd1 cmF0aW9uIGlzc3VlIGZvciBzZW5kZXJzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB0aGVzZSBpdGVtcyBkb24ndCBiZWxvbmcgaW4gdGhl IGNoYXJ0ZXIgZm9yIHRoZSBuZXcgZ3JvdXAsIGRvIHRoZXkgaGF2ZSBhIGRpZmZlcmVudCBuYXR1 cmFsIGhvbWUgZm9yIGRpc2N1c3Npb24/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVzdCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGV0ZXI8YnI+DQo8aW1nIGJvcmRlcj0iMCIg aWQ9Il94MDAwMF9pMTAyNSIgc3JjPSJodHRwczovL3QueWVzd2FyZS5jb20vdC9kNTFlNjNkZjQ4 M2M0ZjFiZjMyYjQ3MjI5ODE0YmEzZjNiMTNmZTQ0LzMyYTQ4MGEyYTA1ZDAwNjVmZTVjZTkyMmI2 ZDJkMDMyL3NwYWNlci5naWYiPjxpbWcgYm9yZGVyPSIwIiBpZD0iX3gwMDAwX2kxMDI2IiBzcmM9 Imh0dHA6Ly90Lnllc3dhcmUuY29tL3QvZDUxZTYzZGY0ODNjNGYxYmYzMmI0NzIyOTgxNGJhM2Yz YjEzZmU0NC8zMmE0ODBhMmEwNWQwMDY1ZmU1Y2U5MjJiNmQyZDAzMi9zcGFjZXIuZ2lmIj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1 LCBBcHIgNiwgMjAxNyBhdCA0OjU4IFBNLCBKb2huIExldmluZSAmbHQ7PGEgaHJlZj0ibWFpbHRv OmpvaG5sQHRhdWdoLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmpvaG5sQHRhdWdoLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDoxMS4yNXB0Ij4mZ3Q7MS4gcHJvZHVjZSAyIGRpZmZlcmVudCBE S0lNLVNpZ25hdHVyZXMgd2l0aCAyIGRpZmZlcmVudCBzZWxlY3RvcnM6PGJyPg0KJmd0O3NsZWN0 b3IxJm5ic3A7IHdpdGggU0hBLTEgJiM0MzsgUlNBIGFuZCBzZWxlY3RvcjIgb25lIHdpdGgmbmJz cDsgU0hBLTUxMiAmIzQzOyBFQ0RTQTxicj4NCjxicj4NCk9mIGNvdXJzZS48YnI+DQo8YnI+DQom Z3Q7Mi4gYWRkIGFuIGFkZGl0aW9uYWwgZmllbGQgdG8gZWl0aGVyIHNlbGVjdG9yMSBES0lNIERO UyByZWNvcmQgKG5lZWQgdG88YnI+DQomZ3Q7Y29uc3VsdCBSRkMgaWYgaXQncyBhbGxvd2VkKSBv ciB0byBES0lNLVNpZ25hdHVyZSB3aXRoIHNlbGVjdG9yMSAoaXQnczxicj4NCiZndDthbGxvd2Vk IGJ1dCBwcm9iYWJseSBpcyBub3QgZW5vdWdoIHRvIHByb3RlY3QgYWdhaW5zdCBkb3duZ3JhZGUp IHRvPGJyPg0KJmd0O2luZGljYXRlIHRoZSBzZWxlY3RvciBpcyBsZWdhY3ktb25seSwgZS5nLiBv PXNoYTUxMi9lY2NwMjU2IHRvIGluZGljYXRlPGJyPg0KJmd0O3RoaXMgc2VsZWN0b3Igc2hvdWxk IGJlIGlnbm9yZWQgaWYgdmVyaWZpZXIgc3VwcG9ydHMgc2hhLTUxMiBhbmQgZWNjcDI1Ni48YnI+ DQo8YnI+DQpOby4mbmJzcDsgSWYgdGhlIHZlcmlmaWVyIGlzIHNtYXJ0IGVub3VnaCB0byB1bmRl cnN0YW5kIG5ldyBhbGdvcml0aG1zLCBpdDxicj4NCmlzIHNtYXJ0IGVub3VnaCB0byBmaWd1cmUg b3V0IHdoaWNoIHNpZ25hdHVyZSB0byBwcmVmZXIuJm5ic3A7IEFsc28ga2VlcCBpbjxicj4NCm1p bmQgdGhhdCB0aGUgbGVnYWN5IGNyeXB0byBpcyBzaGEyNTYvcnNhMTAyNCB3aGljaCBpcyBwbGVu dHkgc3Ryb25nPGJyPg0KZm9yIHRoZSBmb3JzZWVhYmxlIGZ1dHVyZS48YnI+DQo8YnI+DQpSJ3Ms PGJyPg0KSm9objxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CO2PR00MB01203E4C66FD0D68137CAB91A30C0CO2PR00MB0120namp_-- From nobody Fri Apr 7 11:58:21 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 24B03129583 for ; Fri, 7 Apr 2017 11:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 VdqQTPBUz19Z for ; Fri, 7 Apr 2017 11:58:14 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.31]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEF2212704B for ; Fri, 7 Apr 2017 11:58:13 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES533.agna.amgreetings.com ([::1]) with mapi id 14.03.0266.001; Fri, 7 Apr 2017 14:58:12 -0400 From: "MH Michael Hammer (5304)" To: Terry Zink , dmarc Thread-Topic: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-00.txt Thread-Index: AQHSrvvNqu4/0pctKkuxTAnboxyK5qG5HncAgAAp74CAAQVaAIAAM+kA///B35A= Date: Fri, 7 Apr 2017 18:58:12 +0000 Message-ID: References: <20170406235815.47843.qmail@ary.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.6.157] x-kse-attachmentfiltering-interceptor-info: protection disabled x-kse-serverinfo: USCLES533.agna.amgreetings.com, 9 x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean, bases: 4/7/2017 1:56:00 PM x-kse-dlp-scaninfo: Skipped Content-Type: multipart/alternative; boundary="_000_CE39F90A45FF0C49A1EA229FC9899B052BDD2B1DUSCLES544agnaam_" MIME-Version: 1.0 Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-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, 07 Apr 2017 18:58:17 -0000 --_000_CE39F90A45FF0C49A1EA229FC9899B052BDD2B1DUSCLES544agnaam_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyB3YXMgZm9yY2VkIGJ5IHRoZSB3ZWIgYnJvd3NlciBwcm92aWRlcnMgZm9yIFNIQTEuIEl0 4oCZcyBiZWluZyBmb3JjZWQgYnkgdGhlIFBDSSBEU1Mgc3RhbmRhcmQgZm9yIHVzZSBvZiBUTFMx LjAuIFNvIGl0IGNsZWFybHkgaXNwb3NzaWJsZS4NCg0KTWlrZQ0KDQpGcm9tOiBkbWFyYyBbbWFp bHRvOmRtYXJjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUZXJyeSBaaW5rDQpTZW50 OiBGcmlkYXksIEFwcmlsIDA3LCAyMDE3IDI6MzkgUE0NClRvOiBkbWFyYw0KU3ViamVjdDogUmU6 IFtkbWFyYy1pZXRmXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc3Jv c2UtZGtpbS1lY2MtMDAudHh0DQoNCk9uZSByZWFzb24gdHJhbnNpdGlvbnMgYXJlIGRpZmZpY3Vs dCBiZWNhdXNlIG9mIGltcGxlbWVudGF0aW9uIGFuZCBkZXByZWNhdGlvbiBhbWJpZ3VpdHkuIElm IHRoZXJl4oCZcyBubyByZWFzb24gdG8gbW92ZSBvdGhlciB0aGFuIGJlc3QgcHJhY3RpY2UsIHRo ZW4gbm8gb25lIHdpbGwgKG9yIG5vdCBlbm91Z2ggd2lsbCBtb3ZlKS4NCg0KTWF5YmUgd2UgY2Fu IGJ1aWxkIHRpbWVsaW5lcyBpbnRvIHRoZSB1cGRhdGVzLiBCeSBKYW4gMSwgMjAxOSwgcmVjZWl2 ZXJzIFNIT1VMRCAoTVVTVD8pIG5vIGxvbmdlciBzdXBwb3J0IHRoZSBmb2xsb3dpbmcga2V5IHNp emVzIG9yIGFsZ29yaXRobXMuIFRoYXQgd2F5LCBpZiBhbnlvbmUgY29tcGxhaW5zIHRoYXQgYSBw YXJ0aWN1bGFyIERLSU0tc2lnbmF0dXJlIGlzIG5vdCBjb25zaWRlcmVkIHZhbGlkLCB3ZSBjYW4g YWx3YXlzIHNheSBpdOKAmXMgUkZDIG5vbi1jb21wbGlhbnQuDQoNCkZvciBleGFtcGxlLCBmb3Ig c3VwcG9ydGVkIFRMUyBjaXBoZXJzLCBNaWNyb3NvZnQgT2ZmaWNlIDM2NSBwdWJsaXNoZXMgd2hh dCBhbGdvcml0aG1zIGFyZSBzdXBwb3J0ZWQsIGFsb25nIHdpdGggdGltZWxpbmVzIGZvciBkZXBy ZWNhdGlvbjogaHR0cHM6Ly90ZWNobmV0Lm1pY3Jvc29mdC5jb20vZW4tdXMvbGlicmFyeS9kbjU2 OTI4Ni5hc3B4LiBJZiBzZW5kZXJzIGhhdmUgcHJvYmxlbXMgd2l0aCBUTFMgY29ubmVjdGlvbnMs IHdlIHBvaW50IHRoZW0gdG8gdGhhdCBkb2N1bWVudGF0aW9uLiBOb3QgZXZlcnlvbmUgcmVhZHMg dGhlIGRvY3VtZW50YXRpb24sIGJ1dCBpdCBpcyB0aGUgd2F5IHdlIGFkdmVydGlzZSB0byB0aGUg d29ybGQgd2hhdCB3ZSBkbyBhbmQgZG9u4oCZdCBzdXBwb3J0Lg0KDQotLVRlcnJ5DQoNCkZyb206 IGRtYXJjIFttYWlsdG86ZG1hcmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBldGVy IEdvbGRzdGVpbg0KU2VudDogRnJpZGF5LCBBcHJpbCA3LCAyMDE3IDg6MzQgQU0NClRvOiBKb2hu IExldmluZSA8am9obmxAdGF1Z2guY29tPG1haWx0bzpqb2hubEB0YXVnaC5jb20+Pg0KQ2M6IGRt YXJjIDxkbWFyY0BpZXRmLm9yZzxtYWlsdG86ZG1hcmNAaWV0Zi5vcmc+PjsgVmxhZGltaXIgRHVi cm92aW4gPGR1YnJvdmluQGNvcnAubWFpbC5ydTxtYWlsdG86ZHVicm92aW5AY29ycC5tYWlsLnJ1 Pj4NClN1YmplY3Q6IFJlOiBbZG1hcmMtaWV0Zl0gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LXNyb3NlLWRraW0tZWNjLTAwLnR4dA0KDQpKb2huLA0KDQpSZWFsbHkgZ2xh ZCB0byBzZWUgdGhpcy4NCg0KRG9lcyB0aGlzIGluaXRpYXRpdmUgaW5jbHVkZSBhbiBpbnRlbnRp b24gdG8gdXBkYXRlIHRoZSBjcnlwdG9ncmFwaGljIGd1aWRhbmNlIGZyb20gUkZDIDYzNzYgc2Vj dGlvbnMgMy4zIGFuZCAzLjMuMyA/ICBUaGUgcHJvcG9zZWQgY2hhcnRlciBzcGVha3Mgb2YgYWRk aW5nIG5ldyBhbGdvcml0aG1zLCBidXQgZG9lc24ndCBkaXNjdXNzIGRlcHJlY2F0aW5nL3JlbW92 aW5nIG9sZCBvbmVzLg0KDQpTb21lIHNwZWNpZmljIGNvbmNlcm5zIGFyZToNCg0KMS4gRXhwcmVz c2x5IGZvcmJpZGRpbmcgUlNBIGtleXMgPCAxMDI0IGJpdHMgaW4gc2l6ZSAtIFdoaWxlIHRoZSBm YWN0IHRoYXQgc29tZSBtYWpvciByZWNlaXZlcnMgaWdub3JlIHN1Y2gga2V5cyBoYXMgbWFkZSB0 aGlzIGEgZGUgZmFjdG8gc3RhbmRhcmQsIGl0IHdvdWxkIGJlIGdvb2QgZm9yIHRoZSBSRkNzIHRv IHJlZmxlY3QgYmVzdCBwcmFjdGljZSBoZXJlLiAgQW5kIGFzIHdlIHNhdyB3aXRoIHRoZSBBUkMg ZGlzY3Vzc2lvbiwgdXNpbmcgdGhlIERLSU0gc3BlYyBhcyBhIHJlZmVyZW5jZSBjYW4gaW5hZHZl cnRlbnRseSByZXN1bHQgaW4gbmV3IHN0YW5kYXJkcyBzdXBwb3J0aW5nIGtub3duIGluc2VjdXJl IHByYWN0aWNlcy4NCg0KMi4gRWxpbWluYXRpbmcgU0hBLTEgLSBFdmVuIGF0IHRoZSB0aW1lIG9m IHB1YmxpY2F0aW9uIFJGQyA2Mzc2IHJlY29tbWVuZGVkIHRoYXQgc2lnbmVycyBhdm9pZCB0aGUg dXNlIG9mIFNIQS0xLiAgRGVzcGl0ZSB0aGlzLCBhIHNpbXBsZSBjaGVjayBvZiBteSBpbmJveCBz aG93cyB0aGF0IHF1aXRlIGEgZmV3IHNlbmRlcnMgLSBpbmNsdWRpbmcgYSBudW1iZXIgb2YgbGFy Z2UsIHNvcGhpc3RpY2F0ZWQgRVNQcyAtIHN0aWxsIHVzZSBTSEEtMSBpbiBwcmVmZXJlbmNlIHRv IFNIQS0yNTYuICBXaGlsZSB0aGUgcmVjZW50IGRldmVsb3BlZCBQREYgY29sbGlzaW9uIGF0dGFj ayBhZ2FpbnN0IFNIQS0xIGlzIG5vdCBlbnRpcmVseSBvbiBwb2ludCwgaXQgc2VlbXMgdG8gYmUg ZnVydGhlciBldmlkZW5jZSB0aGF0IFNIQS0xIHNob3VsZCBub3QgYmUgdXNlZC4gIEFuZCBnaXZl biB0aGUgd2lkZXNwcmVhZCBzdXBwb3J0IGZvciBTSEEtMjU2LCB0aGlzIHNlZW1zIGxpa2UgaXQn cyBtb3N0bHkgYSBjb25maWd1cmF0aW9uIGlzc3VlIGZvciBzZW5kZXJzLg0KDQpJZiB0aGVzZSBp dGVtcyBkb24ndCBiZWxvbmcgaW4gdGhlIGNoYXJ0ZXIgZm9yIHRoZSBuZXcgZ3JvdXAsIGRvIHRo ZXkgaGF2ZSBhIGRpZmZlcmVudCBuYXR1cmFsIGhvbWUgZm9yIGRpc2N1c3Npb24/DQoNClRoYW5r cy4NCg0KQmVzdCwNCg0KUGV0ZXINCltodHRwczovL3QueWVzd2FyZS5jb20vdC9kNTFlNjNkZjQ4 M2M0ZjFiZjMyYjQ3MjI5ODE0YmEzZjNiMTNmZTQ0LzMyYTQ4MGEyYTA1ZDAwNjVmZTVjZTkyMmI2 ZDJkMDMyL3NwYWNlci5naWZdW2h0dHA6Ly90Lnllc3dhcmUuY29tL3QvZDUxZTYzZGY0ODNjNGYx YmYzMmI0NzIyOTgxNGJhM2YzYjEzZmU0NC8zMmE0ODBhMmEwNWQwMDY1ZmU1Y2U5MjJiNmQyZDAz Mi9zcGFjZXIuZ2lmXQ0KDQpPbiBUaHUsIEFwciA2LCAyMDE3IGF0IDQ6NTggUE0sIEpvaG4gTGV2 aW5lIDxqb2hubEB0YXVnaC5jb208bWFpbHRvOmpvaG5sQHRhdWdoLmNvbT4+IHdyb3RlOg0KPjEu IHByb2R1Y2UgMiBkaWZmZXJlbnQgREtJTS1TaWduYXR1cmVzIHdpdGggMiBkaWZmZXJlbnQgc2Vs ZWN0b3JzOg0KPnNsZWN0b3IxICB3aXRoIFNIQS0xICsgUlNBIGFuZCBzZWxlY3RvcjIgb25lIHdp dGggIFNIQS01MTIgKyBFQ0RTQQ0KDQpPZiBjb3Vyc2UuDQoNCj4yLiBhZGQgYW4gYWRkaXRpb25h bCBmaWVsZCB0byBlaXRoZXIgc2VsZWN0b3IxIERLSU0gRE5TIHJlY29yZCAobmVlZCB0bw0KPmNv bnN1bHQgUkZDIGlmIGl0J3MgYWxsb3dlZCkgb3IgdG8gREtJTS1TaWduYXR1cmUgd2l0aCBzZWxl Y3RvcjEgKGl0J3MNCj5hbGxvd2VkIGJ1dCBwcm9iYWJseSBpcyBub3QgZW5vdWdoIHRvIHByb3Rl Y3QgYWdhaW5zdCBkb3duZ3JhZGUpIHRvDQo+aW5kaWNhdGUgdGhlIHNlbGVjdG9yIGlzIGxlZ2Fj eS1vbmx5LCBlLmcuIG89c2hhNTEyL2VjY3AyNTYgdG8gaW5kaWNhdGUNCj50aGlzIHNlbGVjdG9y IHNob3VsZCBiZSBpZ25vcmVkIGlmIHZlcmlmaWVyIHN1cHBvcnRzIHNoYS01MTIgYW5kIGVjY3Ay NTYuDQoNCk5vLiAgSWYgdGhlIHZlcmlmaWVyIGlzIHNtYXJ0IGVub3VnaCB0byB1bmRlcnN0YW5k IG5ldyBhbGdvcml0aG1zLCBpdA0KaXMgc21hcnQgZW5vdWdoIHRvIGZpZ3VyZSBvdXQgd2hpY2gg c2lnbmF0dXJlIHRvIHByZWZlci4gIEFsc28ga2VlcCBpbg0KbWluZCB0aGF0IHRoZSBsZWdhY3kg Y3J5cHRvIGlzIHNoYTI1Ni9yc2ExMDI0IHdoaWNoIGlzIHBsZW50eSBzdHJvbmcNCmZvciB0aGUg Zm9yc2VlYWJsZSBmdXR1cmUuDQoNClIncywNCkpvaG4NCg== --_000_CE39F90A45FF0C49A1EA229FC9899B052BDD2B1DUSCLES544agnaam_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0 ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0 ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5t c29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ow0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJC YWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9 DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2lu OjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5UaGlzIHdhcyBmb3JjZWQgYnkgdGhl IHdlYiBicm93c2VyIHByb3ZpZGVycyBmb3IgU0hBMS4gSXTigJlzIGJlaW5nIGZvcmNlZCBieSB0 aGUgUENJIERTUyBzdGFuZGFyZCBmb3IgdXNlIG9mIFRMUzEuMC4gU28gaXQgY2xlYXJseSBpc3Bv c3NpYmxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+TWlrZTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4w cHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiBkbWFyYyBbbWFpbHRvOmRtYXJjLWJvdW5jZXNAaWV0Zi5v cmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlRlcnJ5IFppbms8YnI+DQo8Yj5TZW50OjwvYj4gRnJp ZGF5LCBBcHJpbCAwNywgMjAxNyAyOjM5IFBNPGJyPg0KPGI+VG86PC9iPiBkbWFyYzxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW2RtYXJjLWlldGZdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1zcm9zZS1ka2ltLWVjYy0wMC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbmUgcmVhc29uIHRyYW5zaXRpb25zIGFyZSBkaWZm aWN1bHQgYmVjYXVzZSBvZiBpbXBsZW1lbnRhdGlvbiBhbmQgZGVwcmVjYXRpb24gYW1iaWd1aXR5 LiBJZiB0aGVyZeKAmXMgbm8gcmVhc29uIHRvIG1vdmUgb3RoZXIgdGhhbiBiZXN0IHByYWN0aWNl LCB0aGVuIG5vIG9uZSB3aWxsIChvciBub3QgZW5vdWdoIHdpbGwgbW92ZSkuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk1heWJlIHdlIGNhbiBidWlsZCB0aW1lbGluZXMgaW50byB0aGUgdXBkYXRl cy4gQnkgSmFuIDEsIDIwMTksIHJlY2VpdmVycyBTSE9VTEQgKE1VU1Q/KSBubyBsb25nZXIgc3Vw cG9ydCB0aGUgZm9sbG93aW5nIGtleSBzaXplcyBvciBhbGdvcml0aG1zLiBUaGF0IHdheSwgaWYg YW55b25lIGNvbXBsYWlucyB0aGF0IGEgcGFydGljdWxhciBES0lNLXNpZ25hdHVyZSBpcyBub3Qg Y29uc2lkZXJlZCB2YWxpZCwgd2UNCiBjYW4gYWx3YXlzIHNheSBpdOKAmXMgUkZDIG5vbi1jb21w bGlhbnQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvciBleGFtcGxlLCBmb3Igc3VwcG9ydGVk IFRMUyBjaXBoZXJzLCBNaWNyb3NvZnQgT2ZmaWNlIDM2NSBwdWJsaXNoZXMgd2hhdCBhbGdvcml0 aG1zIGFyZSBzdXBwb3J0ZWQsIGFsb25nIHdpdGggdGltZWxpbmVzIGZvciBkZXByZWNhdGlvbjoN CjxhIGhyZWY9Imh0dHBzOi8vdGVjaG5ldC5taWNyb3NvZnQuY29tL2VuLXVzL2xpYnJhcnkvZG41 NjkyODYuYXNweCI+aHR0cHM6Ly90ZWNobmV0Lm1pY3Jvc29mdC5jb20vZW4tdXMvbGlicmFyeS9k bjU2OTI4Ni5hc3B4PC9hPi4gSWYgc2VuZGVycyBoYXZlIHByb2JsZW1zIHdpdGggVExTIGNvbm5l Y3Rpb25zLCB3ZSBwb2ludCB0aGVtIHRvIHRoYXQgZG9jdW1lbnRhdGlvbi4gTm90IGV2ZXJ5b25l IHJlYWRzIHRoZSBkb2N1bWVudGF0aW9uLCBidXQNCiBpdCBpcyB0aGUgd2F5IHdlIGFkdmVydGlz ZSB0byB0aGUgd29ybGQgd2hhdCB3ZSBkbyBhbmQgZG9u4oCZdCBzdXBwb3J0LjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPi0tVGVycnk8bzpwPjwvbzpw PjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBkbWFyYyBbPGEgaHJlZj0ibWFpbHRvOmRt YXJjLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkbWFyYy1ib3VuY2VzQGlldGYub3JnPC9hPl0N CjxiPk9uIEJlaGFsZiBPZiA8L2I+UGV0ZXIgR29sZHN0ZWluPGJyPg0KPGI+U2VudDo8L2I+IEZy aWRheSwgQXByaWwgNywgMjAxNyA4OjM0IEFNPGJyPg0KPGI+VG86PC9iPiBKb2huIExldmluZSAm bHQ7PGEgaHJlZj0ibWFpbHRvOmpvaG5sQHRhdWdoLmNvbSI+am9obmxAdGF1Z2guY29tPC9hPiZn dDs8YnI+DQo8Yj5DYzo8L2I+IGRtYXJjICZsdDs8YSBocmVmPSJtYWlsdG86ZG1hcmNAaWV0Zi5v cmciPmRtYXJjQGlldGYub3JnPC9hPiZndDs7IFZsYWRpbWlyIER1YnJvdmluICZsdDs8YSBocmVm PSJtYWlsdG86ZHVicm92aW5AY29ycC5tYWlsLnJ1Ij5kdWJyb3ZpbkBjb3JwLm1haWwucnU8L2E+ Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2RtYXJjLWlldGZdIEZ3ZDogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1zcm9zZS1ka2ltLWVjYy0wMC50eHQ8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpvaG4sPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5SZWFsbHkgZ2xhZCB0byBzZWUgdGhpcy4gJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvZXMgdGhpcyBp bml0aWF0aXZlIGluY2x1ZGUgYW4gaW50ZW50aW9uIHRvIHVwZGF0ZSB0aGUgY3J5cHRvZ3JhcGhp YyBndWlkYW5jZSBmcm9tIFJGQyA2Mzc2IHNlY3Rpb25zIDMuMyBhbmQgMy4zLjMgPyZuYnNwOyBU aGUgcHJvcG9zZWQgY2hhcnRlciBzcGVha3Mgb2YgYWRkaW5nIG5ldyBhbGdvcml0aG1zLCBidXQg ZG9lc24ndCBkaXNjdXNzIGRlcHJlY2F0aW5nL3JlbW92aW5nIG9sZCBvbmVzLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Tb21lIHNwZWNpZmlj IGNvbmNlcm5zIGFyZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+MS4gRXhwcmVzc2x5IGZvcmJpZGRpbmcgUlNBIGtleXMgJmx0OyAxMDI0IGJp dHMgaW4gc2l6ZSAtIFdoaWxlIHRoZSBmYWN0IHRoYXQgc29tZSBtYWpvciByZWNlaXZlcnMgaWdu b3JlIHN1Y2gga2V5cyBoYXMgbWFkZSB0aGlzIGEgZGUgZmFjdG8gc3RhbmRhcmQsIGl0IHdvdWxk IGJlIGdvb2QgZm9yIHRoZSBSRkNzIHRvIHJlZmxlY3QgYmVzdCBwcmFjdGljZSBoZXJlLiZuYnNw OyBBbmQgYXMgd2Ugc2F3IHdpdGggdGhlIEFSQw0KIGRpc2N1c3Npb24sIHVzaW5nIHRoZSBES0lN IHNwZWMgYXMgYSByZWZlcmVuY2UgY2FuIGluYWR2ZXJ0ZW50bHkgcmVzdWx0IGluIG5ldyBzdGFu ZGFyZHMgc3VwcG9ydGluZyBrbm93biBpbnNlY3VyZSBwcmFjdGljZXMuICZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yLiBFbGltaW5h dGluZyBTSEEtMSAtIEV2ZW4gYXQgdGhlIHRpbWUgb2YgcHVibGljYXRpb24gUkZDIDYzNzYgcmVj b21tZW5kZWQgdGhhdCBzaWduZXJzIGF2b2lkIHRoZSB1c2Ugb2YgU0hBLTEuJm5ic3A7IERlc3Bp dGUgdGhpcywgYSBzaW1wbGUgY2hlY2sgb2YgbXkgaW5ib3ggc2hvd3MgdGhhdCBxdWl0ZSBhIGZl dyBzZW5kZXJzIC0gaW5jbHVkaW5nIGEgbnVtYmVyIG9mIGxhcmdlLCBzb3BoaXN0aWNhdGVkIEVT UHMNCiAtIHN0aWxsIHVzZSBTSEEtMSBpbiBwcmVmZXJlbmNlIHRvIFNIQS0yNTYuJm5ic3A7IFdo aWxlIHRoZSByZWNlbnQgZGV2ZWxvcGVkIFBERiBjb2xsaXNpb24gYXR0YWNrIGFnYWluc3QgU0hB LTEgaXMgbm90IGVudGlyZWx5IG9uIHBvaW50LCBpdCBzZWVtcyB0byBiZSBmdXJ0aGVyIGV2aWRl bmNlIHRoYXQgU0hBLTEgc2hvdWxkIG5vdCBiZSB1c2VkLiZuYnNwOyBBbmQgZ2l2ZW4gdGhlIHdp ZGVzcHJlYWQgc3VwcG9ydCBmb3IgU0hBLTI1NiwgdGhpcyBzZWVtcyBsaWtlDQogaXQncyBtb3N0 bHkgYSBjb25maWd1cmF0aW9uIGlzc3VlIGZvciBzZW5kZXJzLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB0aGVzZSBpdGVtcyBkb24ndCBi ZWxvbmcgaW4gdGhlIGNoYXJ0ZXIgZm9yIHRoZSBuZXcgZ3JvdXAsIGRvIHRoZXkgaGF2ZSBhIGRp ZmZlcmVudCBuYXR1cmFsIGhvbWUgZm9yIGRpc2N1c3Npb24/PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcy48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVzdCw8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGV0ZXI8YnI+DQo8aW1n IGJvcmRlcj0iMCIgaWQ9Il94MDAwMF9pMTAyNSIgc3JjPSJodHRwczovL3QueWVzd2FyZS5jb20v dC9kNTFlNjNkZjQ4M2M0ZjFiZjMyYjQ3MjI5ODE0YmEzZjNiMTNmZTQ0LzMyYTQ4MGEyYTA1ZDAw NjVmZTVjZTkyMmI2ZDJkMDMyL3NwYWNlci5naWYiPjxpbWcgYm9yZGVyPSIwIiBpZD0iX3gwMDAw X2kxMDI2IiBzcmM9Imh0dHA6Ly90Lnllc3dhcmUuY29tL3QvZDUxZTYzZGY0ODNjNGYxYmYzMmI0 NzIyOTgxNGJhM2YzYjEzZmU0NC8zMmE0ODBhMmEwNWQwMDY1ZmU1Y2U5MjJiNmQyZDAzMi9zcGFj ZXIuZ2lmIj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gVGh1LCBBcHIgNiwgMjAxNyBhdCA0OjU4IFBNLCBKb2huIExldmluZSAmbHQ7PGEg aHJlZj0ibWFpbHRvOmpvaG5sQHRhdWdoLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmpvaG5sQHRhdWdo LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdo dDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MTEuMjVwdCI+Jmd0OzEuIHByb2R1Y2UgMiBkaWZmZXJlbnQgREtJTS1TaWdu YXR1cmVzIHdpdGggMiBkaWZmZXJlbnQgc2VsZWN0b3JzOjxicj4NCiZndDtzbGVjdG9yMSZuYnNw OyB3aXRoIFNIQS0xICYjNDM7IFJTQSBhbmQgc2VsZWN0b3IyIG9uZSB3aXRoJm5ic3A7IFNIQS01 MTIgJiM0MzsgRUNEU0E8YnI+DQo8YnI+DQpPZiBjb3Vyc2UuPGJyPg0KPGJyPg0KJmd0OzIuIGFk ZCBhbiBhZGRpdGlvbmFsIGZpZWxkIHRvIGVpdGhlciBzZWxlY3RvcjEgREtJTSBETlMgcmVjb3Jk IChuZWVkIHRvPGJyPg0KJmd0O2NvbnN1bHQgUkZDIGlmIGl0J3MgYWxsb3dlZCkgb3IgdG8gREtJ TS1TaWduYXR1cmUgd2l0aCBzZWxlY3RvcjEgKGl0J3M8YnI+DQomZ3Q7YWxsb3dlZCBidXQgcHJv YmFibHkgaXMgbm90IGVub3VnaCB0byBwcm90ZWN0IGFnYWluc3QgZG93bmdyYWRlKSB0bzxicj4N CiZndDtpbmRpY2F0ZSB0aGUgc2VsZWN0b3IgaXMgbGVnYWN5LW9ubHksIGUuZy4gbz1zaGE1MTIv ZWNjcDI1NiB0byBpbmRpY2F0ZTxicj4NCiZndDt0aGlzIHNlbGVjdG9yIHNob3VsZCBiZSBpZ25v cmVkIGlmIHZlcmlmaWVyIHN1cHBvcnRzIHNoYS01MTIgYW5kIGVjY3AyNTYuPGJyPg0KPGJyPg0K Tm8uJm5ic3A7IElmIHRoZSB2ZXJpZmllciBpcyBzbWFydCBlbm91Z2ggdG8gdW5kZXJzdGFuZCBu ZXcgYWxnb3JpdGhtcywgaXQ8YnI+DQppcyBzbWFydCBlbm91Z2ggdG8gZmlndXJlIG91dCB3aGlj aCBzaWduYXR1cmUgdG8gcHJlZmVyLiZuYnNwOyBBbHNvIGtlZXAgaW48YnI+DQptaW5kIHRoYXQg dGhlIGxlZ2FjeSBjcnlwdG8gaXMgc2hhMjU2L3JzYTEwMjQgd2hpY2ggaXMgcGxlbnR5IHN0cm9u Zzxicj4NCmZvciB0aGUgZm9yc2VlYWJsZSBmdXR1cmUuPGJyPg0KPGJyPg0KUidzLDxicj4NCkpv aG48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CE39F90A45FF0C49A1EA229FC9899B052BDD2B1DUSCLES544agnaam_-- From nobody Fri Apr 7 19:55:28 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 4F741129407 for ; Fri, 7 Apr 2017 19:55:26 -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 8FC1vaZwKfko for ; Fri, 7 Apr 2017 19:55:23 -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 A14811292F4 for ; Fri, 7 Apr 2017 19:55:23 -0700 (PDT) Received: from [192.168.179.5] (KD036012058250.au-net.ne.jp [36.12.58.250]) (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 88C342F8000C5; Sat, 8 Apr 2017 11:55:20 +0900 (JST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Kouji Okada In-Reply-To: <01QCNXBZDS520003XB@mauve.mrochek.com> Date: Sat, 8 Apr 2017 11:55:18 +0900 Cc: Kouji Okada , Dave Crocker , Takehito Akagiri , dmarc Content-Transfer-Encoding: quoted-printable Message-Id: <5FCB0D34-30F4-4976-AAB5-63CAB82F6F0F@lepidum.co.jp> References: <1091919919.43972.1458233931938.JavaMail.zimbra@peachymango.org> <233B51DD-C6BB-464F-8206-D3D0CDD032DE@lepidum.co.jp> <8a05b71f-8f38-cd2e-4a3c-e49acd62dbe1@dcrocker.net> <01QCNXBZDS520003XB@mauve.mrochek.com> To: ned+dmarc@mrochek.com 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: 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: Sat, 08 Apr 2017 02:55:26 -0000 Ned I=E2=80=99m sorry for my late reply. We appreciate your advice as a co-chair. We understood that currently there is no room for our proposal in the = current phase of this WG. Best regards, Kouji Okada > 2017/04/02 5:25=E3=80=81ned+dmarc@mrochek.com=E3=81=AE=E3=83=A1=E3=83=BC= =E3=83=AB: >=20 > >=20 > Normally I'm not a stickler for avoiding side discussion of related = items on working lists. But this case I'm going to have to agree with = Dave: This > group is not making sufficient progress on its core work, which = currently > is to review and progress the ARC specifications. This needs to happen > sooner rather than later, and we cannot afford to spend time on this > specification at this time. >=20 > If and when we get that far, we can discuss whether or not this is a = fit for > the third track of this WG (documentation of actual and possible = operational > practices). >=20 > >=20 > Ned >=20 >=20 >> 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. >=20 >=20 >> I'm confused. >=20 >> 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. >=20 >> 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. >=20 >> All of which tells me that this activity is out of scope for this = IETF >> mailing list. >=20 >> I encourage the chairs to chime in and either confirm or correct this >> assessment. >=20 >> d/ >=20 >> -- >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >=20 >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Fri Apr 7 20:04: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 CFEAA126DFB for ; Fri, 7 Apr 2017 20:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 S5IiS4v4fz4L for ; Fri, 7 Apr 2017 20:04:14 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5C6E1286CA for ; Fri, 7 Apr 2017 20:04:13 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id d188so88144946vka.0 for ; Fri, 07 Apr 2017 20:04:13 -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=OWSQ4sphPtefNceROINJW0JPFtVEt86RSw9eZAtPgbI=; b=LFwSde0NEyZ1xW4s76I5jglwmiqYAf5w9AHmwNM8iK8Yb0v/QFGpQYV5LGbZ6H0K9j iFDE8Bt/IyyXQqtU//lRj44tPYi6SNs9K3MDcTnPzSSqIGXSqdALjDs8/NO7jGcqG8Nj QNxzTiKPPmwqaPb4aggfopQ9uJaaEjM36yDt3wT4Naf7VugP9A7h4xHpjSL2kBbhjKor PI95Itoyj7OCosEMGmvatBfC6yz+HW8AP2WdoYbXeLn1oTjsiEjY9KSt3OrlE1pJikeN fsiAcehWsd1h2ioawlK05btRFOBtnd5iEdmm1KpTXcqLVo7mcB1q2Wlxl7tBz772veQ+ g1tg== 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=OWSQ4sphPtefNceROINJW0JPFtVEt86RSw9eZAtPgbI=; b=XepuBiwYmpRXqWpmmPFuvhlXzvEMSpXIspKk+rpJ2AHfHhgoZQfRWSX3HyBBfEumRv c6cYpkwRCe8OKQOyim5riDbOVc97lTVHLKBPG1orG8DiFENJjWS0OsjwrrTg5kyPzqJK +CrQmclF8/+XXFDx84sPAna5rjvWRtbjmdUhiREYobNm5Ijmaoio4cetCYQl2dpOFzwo 2OdR3TX6z7IykC1Gw9RchjymQpokzk6UlvQTxOlPQpMWGHxUZSISxYdUCRzplcfAvape p8DK/gmyqZhZeTUug4wgBa4zU9k5BNfqoPuP6kjjo8dG36Sv1W9mWUI++cKZbTLMJl5M ADDw== X-Gm-Message-State: AFeK/H0R+2KrqvZL0i5bA1Cx1bzkHiVJ9OVhoT7ZH7hMyg+9HbmQNYQYiL98AIpW+CapdfMePhAfXH+gAIL5ww== X-Received: by 10.31.183.19 with SMTP id h19mr17072112vkf.110.1491620652819; Fri, 07 Apr 2017 20:04:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.130.70 with HTTP; Fri, 7 Apr 2017 20:04:12 -0700 (PDT) In-Reply-To: References: <20170406235815.47843.qmail@ary.lan> From: "Murray S. Kucherawy" Date: Fri, 7 Apr 2017 20:04:12 -0700 Message-ID: To: Peter Goldstein Cc: John Levine , dmarc , Vladimir Dubrovin Content-Type: multipart/alternative; boundary=001a1143a44a26bcc6054c9efff1 Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-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: Sat, 08 Apr 2017 03:04:16 -0000 --001a1143a44a26bcc6054c9efff1 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 7, 2017 at 8:33 AM, Peter Goldstein wrote: > Does this initiative include an intention to update the cryptographic > guidance from RFC 6376 sections 3.3 and 3.3.3 ? The proposed charter > speaks of adding new algorithms, but doesn't discuss deprecating/removing > old ones. > As John said, DCRUP could do this. > Some specific concerns are: > > 1. Expressly forbidding RSA keys < 1024 bits in size - While the fact that > some major receivers ignore such keys has made this a de facto standard, it > would be good for the RFCs to reflect best practice here. And as we saw > with the ARC discussion, using the DKIM spec as a reference can > inadvertently result in new standards supporting known insecure practices. > I'm not sure about forbidding, but expressly deprecating by removing mandatory support would certainly be allowed. > 2. Eliminating SHA-1 - Even at the time of publication RFC 6376 > recommended that signers avoid the use of SHA-1. Despite this, a simple > check of my inbox shows that quite a few senders - including a number of > large, sophisticated ESPs - still use SHA-1 in preference to SHA-256. > While the recent developed PDF collision attack against SHA-1 is not > entirely on point, it seems to be further evidence that SHA-1 should not be > used. And given the widespread support for SHA-256, this seems like it's > mostly a configuration issue for senders. > Same issue, because the installed base isn't going to update itself quickly even if we really want it to. -MSK --001a1143a44a26bcc6054c9efff1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Apr 7, 2017 at 8:33 AM, Peter Goldstein <peter@= valimail.com> wrote:
Does this initiative include an intention to update the cryptograp= hic guidance from RFC 6376 sections 3.3 and 3.3.3 ?=C2=A0 The proposed char= ter speaks of adding new algorithms, but doesn't discuss deprecating/re= moving old ones.

As John said, DC= RUP could do this.
=C2=A0
Some specific con= cerns are:

1. Expressly forbidding RSA keys < 1= 024 bits in size - While the fact that some major receivers ignore such key= s has made this a de facto standard, it would be good for the RFCs to refle= ct best practice here.=C2=A0 And as we saw with the ARC discussion, using t= he DKIM spec as a reference can inadvertently result in new standards suppo= rting known insecure practices. =C2=A0

I'm not sure about forbidding, but expressly deprecating by rem= oving mandatory support would certainly be allowed.
=C2=A0
2. Elim= inating SHA-1 - Even at the time of publication RFC 6376 recommended that s= igners avoid the use of SHA-1.=C2=A0 Despite this, a simple check of my inb= ox shows that quite a few senders - including a number of large, sophistica= ted ESPs - still use SHA-1 in preference to SHA-256.=C2=A0 While the recent= developed PDF collision attack against SHA-1 is not entirely on point, it = seems to be further evidence that SHA-1 should not be used.=C2=A0 And given= the widespread support for SHA-256, this seems like it's mostly a conf= iguration issue for senders.

Sa= me issue, because the installed base isn't going to update itself quick= ly even if we really want it to.

-MSK
--001a1143a44a26bcc6054c9efff1-- From nobody Sat Apr 8 05:45:09 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 4B888128CDC for ; Sat, 8 Apr 2017 05:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[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=O90b4hho; dkim=pass (1536-bit key) header.d=taugh.com header.b=ivUEdRiG 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 y1_47QqbD3Ik for ; Sat, 8 Apr 2017 05:45:06 -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 96D08128BB6 for ; Sat, 8 Apr 2017 05:45:06 -0700 (PDT) Received: (qmail 95087 invoked from network); 8 Apr 2017 12:45:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=1736d.58e8db51.k1704; bh=Z/6KWdI9EIowEqX+OR/sm1nzwlvL9uF5HlyCf4mABvs=; b=O90b4hhoDKpQSpeTeRKtngsiOSqgMISYYM9U/vGUjt50/u51ZPQ2/OZKBtPGk6rwdFRf2w5tyNu57Q9Hze+LAueti5T8zMCDP1BcvsMIBQ3gO7c95xVaZNE4c9s43XmZngM9SyBua3L8z6abUs6stV1tvIYn0Y71KB7DtvxNfCO/zvX9WzxH4ysd1OMwJB8jAKQ1S8tKPCT9HjOf++D8u4NjOhS2jxnh+sKto6Ekpry8XX34K5WoYwPps/Iz7IhJ 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=1736d.58e8db51.k1704; bh=Z/6KWdI9EIowEqX+OR/sm1nzwlvL9uF5HlyCf4mABvs=; b=ivUEdRiGPa7jAqP+B5r4qZHc/2uY8OKhuD5zyrDiXSYkgzxsJgaHDnefIlDh9AVMujTcMz44E3LiDnExTs4qqMauAa1yxQLX4pBoIvGX79hG+mNJermvgOFV75NLVObuNhFfk3d4s7gceopDFv3f23pHlnCxjLXJBjuMsdq8GCwb2Xk8xoJK579dfj46rmb/t1a7hrDhOwG1Cvh0Y4eU3mqybktxvov266lIuDHU2ANhbww6bUoAJSoD5M0JDVYU 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; 08 Apr 2017 12:45:05 -0000 Date: 8 Apr 2017 08:45:04 -0400 Message-ID: From: "John R Levine" To: "Vladimir Dubrovin" Cc: dmarc@ietf.org In-Reply-To: <1491556016.525223113@f391.i.mail.ru> References: <20170406235815.47843.qmail@ary.lan> <1491556016.525223113@f391.i.mail.ru> User-Agent: Alpine 2.20 (OSX 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-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: Sat, 08 Apr 2017 12:45:08 -0000 > Without marking the published key as obsolete, downgrade attack is > possible, because attacker can still use a weaker key to spoof > signature. If you know how to spoof a sha256/rsa1024 signature, I know a lot of people who would like to talk to you. Other than that, please review RFC 6376. Each signing algorithm has a separate key -- if you don't trust an algorithm, don't publish a key for it. R's, John > >>> 1. produce 2 different DKIM-Signatures with 2 different selectors: >>> slector1 with SHA-1 + RSA and selector2 one with SHA-512 + ECDSA >> >> Of course. >> >>> 2. add an additional field to either selector1 DKIM DNS record (need to >>> consult RFC if it's allowed) or to DKIM-Signature with selector1 (it's >>> allowed but probably is not enough to protect against downgrade) to >>> indicate the selector is legacy-only, e.g. o=sha512/eccp256 to indicate >>> this selector should be ignored if verifier supports sha-512 and eccp256. >> >> No. If the verifier is smart enough to understand new algorithms, it >> is smart enough to figure out which signature to prefer. Also keep in >> mind that the legacy crypto is sha256/rsa1024 which is plenty strong >> for the forseeable future. From nobody Sat Apr 8 07:30: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 136E4127843 for ; Sat, 8 Apr 2017 07:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=corp.mail.ru 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 xQocnlWAfw_b for ; Sat, 8 Apr 2017 07:30:15 -0700 (PDT) Received: from smtp46.i.mail.ru (smtp46.i.mail.ru [94.100.177.106]) (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 45E501279E5 for ; Sat, 8 Apr 2017 07:30:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=corp.mail.ru; s=mail; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=A5EcwUYK8l7dxbtnDeEuSsWURMG4fQqurkw4OfTKq18=; b=GoMGtN5TAtpHBbgSKxIek8GQUwfNLiIEqjp/rxxdtolUUNYWHG2mcKD07fnwAz6HI3gFcDGjWkclTgQcYcqZQR5QKcmvUxVhE7MklaJW6LWWU8HJSOx8DRDKwSm3shYAR2GrlNnLjS8Ibx7vAcK8ZIb+ELBN2jq//TgvzM91qoE=; Received: from gate.3proxy.ru ([95.79.31.239]:51668 helo=[127.0.0.1]) by smtp46.i.mail.ru with esmtpa (envelope-from ) id 1cwrNU-0004Gt-2R; Sat, 08 Apr 2017 17:30:12 +0300 To: John R Levine , "dmarc@ietf.org" References: <20170406235815.47843.qmail@ary.lan> <1491556016.525223113@f391.i.mail.ru> From: Vladimir Dubrovin Message-ID: <6bf0cc38-581a-9cd6-404b-a9acf527c453@corp.mail.ru> Date: Sat, 8 Apr 2017 17:30:06 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------EB484DB6C085515F43C65B3C" Authentication-Results: smtp46.i.mail.ru; auth=pass smtp.auth=dubrovin@corp.mail.ru smtp.mailfrom=dubrovin@corp.mail.ru X-7FA49CB5: 0D63561A33F958A58A3592046C3E9618D1E09DC3CE3199056972239B64B5A6939F18ECD7E95F35E929AFE063DF4C541C0B0D1444BC99ECAD5554226FBFDD09D3A98AD9646F7AAD836AC2B24064223BE0 X-Mailru-Sender: C5364AD02485212FBEAE30F3FA322883122D5B6481DADB5E1B630F20623ED90A7B57453E6972826ACDCEB298E575E7B2C77752E0C033A69EDAAA56350C7513E7ACB45E4F000D93863453F38A29522196 X-Mras: OK Archived-At: Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-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: Sat, 08 Apr 2017 14:30:18 -0000 This is a multi-part message in MIME format. --------------EB484DB6C085515F43C65B3C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit If you believe sha256/rsa1024 are forever, there is no actual need for draft-srose-dkim-ecc-00.txt. The problem is, this need may arrive at some time, and this time is hardly predictable. There is also possible there may be the need to roll back ECC and mark it as insecure at some point of time. So one would expect from the standard: 1. To be compatible with existing implementation to allow to implement the standard ASAP if required and yet to allow the use of the strongest up-to-date algorithms 2. To be self updating, to avoid the need to produce the new DKIM standard each time encryption standards are changing. It may be achieved by e.g. referencing to IANA TLS SignatureAlgorithm/HashAlgorithm registry. 08.04.2017 15:45, John R Levine Đ¿Đ¸ÑˆĐµÑ‚: >> Without marking the published key as obsolete, downgrade attack is >> possible, because attacker can still use a weaker key to spoof >> signature. > > If you know how to spoof a sha256/rsa1024 signature, I know a lot of > people who would like to talk to you. > > Other than that, please review RFC 6376. Each signing algorithm has a > separate key -- if you don't trust an algorithm, don't publish a key > for it. > > R's, > John > >> >>>> 1. produce 2 different DKIM-Signatures with 2 different selectors: >>>> slector1 with SHA-1 + RSA and selector2 one with SHA-512 + ECDSA >>> >>> Of course. >>> >>>> 2. add an additional field to either selector1 DKIM DNS record >>>> (need to >>>> consult RFC if it's allowed) or to DKIM-Signature with selector1 (it's >>>> allowed but probably is not enough to protect against downgrade) to >>>> indicate the selector is legacy-only, e.g. o=sha512/eccp256 to >>>> indicate >>>> this selector should be ignored if verifier supports sha-512 and >>>> eccp256. >>> >>> No. If the verifier is smart enough to understand new algorithms, it >>> is smart enough to figure out which signature to prefer. Also keep in >>> mind that the legacy crypto is sha256/rsa1024 which is plenty strong >>> for the forseeable future. -- Vladimir Dubrovin @Mail.Ru --------------EB484DB6C085515F43C65B3C Content-Type: multipart/related; boundary="------------74CAC297FD665F780E39DB91" --------------74CAC297FD665F780E39DB91 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

If you believe sha256/rsa1024 are forever, there is no actual need for draft-srose-dkim-ecc-00.txt.  The problem is, this need may arrive at some time, and this time is hardly predictable. There is also possible there may be the need to roll back ECC and mark it as insecure at some point of time. So one would expect from the standard:

1. To be compatible with existing implementation to allow to implement the standard ASAP if required and yet to allow the use of the strongest up-to-date algorithms
2. To be self updating, to avoid the need to produce the new DKIM standard each time encryption standards are changing. It may be achieved by e.g. referencing to IANA TLS SignatureAlgorithm/HashAlgorithm registry.

08.04.2017 15:45, John R Levine Đ¿Đ¸ÑˆĐµÑ‚:
Without marking the published key as obsolete, downgrade attack is possible, because attacker can still use a weaker key to spoof signature.

If you know how to spoof a sha256/rsa1024 signature, I know a lot of people who would like to talk to you.

Other than that, please review RFC 6376.  Each signing algorithm has a separate key -- if you don't trust an algorithm, don't publish a key for it.

R's,
John


1. produce 2 different DKIM-Signatures with 2 different selectors:
slector1  with SHA-1 + RSA and selector2 one with  SHA-512 + ECDSA

Of course.

2. add an additional field to either selector1 DKIM DNS record (need to
consult RFC if it's allowed) or to DKIM-Signature with selector1 (it's
allowed but probably is not enough to protect against downgrade) to
indicate the selector is legacy-only, e.g. o=sha512/eccp256 to indicate
this selector should be ignored if verifier supports sha-512 and eccp256.

No.  If the verifier is smart enough to understand new algorithms, it
is smart enough to figure out which signature to prefer.  Also keep in
mind that the legacy crypto is sha256/rsa1024 which is plenty strong
for the forseeable future.


--
Vladimir Dubrovin
@Mail.Ru
--------------74CAC297FD665F780E39DB91 Content-Type: image/png; name="oolpcgbikilnmbdk.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="oolpcgbikilnmbdk.png" iVBORw0KGgoAAAANSUhEUgAAAHwAAAAZCAQAAABZLoLcAAADz0lEQVR4AeWX2XLiPBCFP3nB 7IEAWSAk4BkWg837P95UuU51WRhXjf1XcjH/8Y2EpO7+tLQQd3JM2XDgwo2CCylvDPkJOVIK PgCYknMm4YfkWJBxe/AdmPLd6ssXwL4svfAjSvhdQc3JuHjwXwR8p3ryC/CrLL/yAxpxFWDK nB6lCBiztpYjEd+pKe+Mfha8L7gzY+oKeTf0ABOOgaanT99rSRgS8lgBCQMirK+VAwa41uCO xMaF9GlmDIHID+WskxypyzspB/a8EEOpCXnZ5wNMB25s2VBok74TAAtZK9gS4WtCqt43TqwI eC57DgHHqTxQbcATPhXXDojKw7nhgcqlu97H81YOzYiBgA/vZOcsSdgxZ6yQB1AqfpgEU69+ pgdSyK7W/8wRIVpyC/4a/JXCLF2BsWw+kPxMqSjUnD0BgVzeyDja2b5QmtMEfVaTkbnNfSSr /7JdZamTwu8txIHK4V+CbyrjMxbtwZ+1VgAfKg/VNuaI1samqCDwwC/MgICdYa0IcBbYQJaV OpW+Yq1XV/C5xTXDAbQH/yp/WpjrEwGYQo4Vc59leeKBj8Grv6jutK7Pto3vz9+QvCN4oP8b vwkBOoErFSXABmtsMLfA0Ay0h6T69M7yElhrJzl8PXcEn+k4xdAdvChNoMYcx72uZm6qdWsL fipLc+7luHYC/7Q4uoMrOQBlEjs1DDpXTG9bgxfaVXXtu4ArUc7+O/gVtC4ZdZ3N3JPu8m7g MXXtuoALY4yvkZLtI2X1EZm5+6qFZ4ACX5Xlt9bgmVrqOj8ET+WnFbhFFHGvSC1Jfc6ntp5r fH1h4NqYs9bgWz1zqG/OOrj137UC96fR14sOtKdlJagDutokx9q7x7Vl24Ib4IyqQk6PwZXt C/otwV81bkhVA4pHOyjSz/0S5qKL55Ul7wpdsyWzKbQGh73d8oGdSGE/AA+5ymsVLmZC2ATu 3e85C5yW7plceSzkThvBBkCChaMv1cbTY4RxJ/CITO05KTt5aQKHhbVdSBnZZBybwKURBTeB 7km5qlYwoaZI67wnABxLDuqcMgPmlRC30AkceqpXv4JLAzisvcePtTeDSxODtY9cUTUmmaOd DkcIVk7VvsOB5Mqgr7i7k5fU06YU8OYFlTLUw2duL4ETmOZk5hdiCrusdvL0WDFbisrkbolp 1IzCnDwZtGPMkhh44qU2awkr+p7DFSMwhSxqYxxTVqyYEau+YGZJaEkPk/lfKp4RK8FG8tSs kCeWrDCWZo3JvIfegRO5Mv4/rpA3ofrfmv+BAmZsOZBbRl3g+Af1By7rr2XUY4YeAAAAAElF TkSuQmCC --------------74CAC297FD665F780E39DB91-- --------------EB484DB6C085515F43C65B3C-- From nobody Sat Apr 8 12:50:13 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 559DF12946F for ; Sat, 8 Apr 2017 12:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hb8BZQbH5Y7J for ; Sat, 8 Apr 2017 12:50:11 -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 F3608127A97 for ; Sat, 8 Apr 2017 12:50:10 -0700 (PDT) Received: (qmail 62070 invoked from network); 8 Apr 2017 19:50:07 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 8 Apr 2017 19:50:07 -0000 Date: 8 Apr 2017 19:49:45 -0000 Message-ID: <20170408194945.57707.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org Cc: dubrovin@corp.mail.ru In-Reply-To: <6bf0cc38-581a-9cd6-404b-a9acf527c453@corp.mail.ru> 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] Fwd: New Version Notification for draft-srose-dkim-ecc-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: Sat, 08 Apr 2017 19:50:12 -0000 >If you believe sha256/rsa1024 are forever, there is no actual need for >draft-srose-dkim-ecc-00.txt. The problem is, this need may arrive at >some time, and this time is hardly predictable. There is also possible >there may be the need to roll back ECC and mark it as insecure at some >point of time. So one would expect from the standard: ... One can expect whatever one wants, but as should be self-evident to anyone who's read RFC 6376, it's not going to happen. As Murray noted, signers put whatever signatures they want on the messages, and verifiers accept whatever signatures they find acceptable. If verifiers stop accepting signatures with a weak algorithm it'll be because they stop accepting them, not because of a "this is a weak signature" flag. One of the things DCRUP may do is to recommend that they stop accepting signatures with SHA-1 hashes or 512 bit RSA keys. R's, John From nobody Sat Apr 8 12:52: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 554AC12946A for ; Sat, 8 Apr 2017 12:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IfvUluAfp2i for ; Sat, 8 Apr 2017 12:52:17 -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 1D9A1127A97 for ; Sat, 8 Apr 2017 12:52:17 -0700 (PDT) Received: (qmail 62325 invoked from network); 8 Apr 2017 19:52:16 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 8 Apr 2017 19:52:16 -0000 Date: 8 Apr 2017 19:51:54 -0000 Message-ID: <20170408195154.57728.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org Cc: tzink@microsoft.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] Fwd: New Version Notification for draft-srose-dkim-ecc-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: Sat, 08 Apr 2017 19:52:18 -0000 >Maybe we can build timelines into the updates. By Jan 1, 2019, receivers SHOULD (MUST?) no longer support the >following key sizes or algorithms. That way, if anyone complains that a particular DKIM-signature is not >considered valid, we can always say it’s RFC non-compliant. The IETF historically hasn't done that. Would would make a difference is if some of the big gorillas (you know who you are) said you'll stop accepting weak signatures as of some date, then actually do it. R's, John From nobody Sat Apr 8 13:11:36 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 9FC22128B93 for ; Sat, 8 Apr 2017 13:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3z1sw_huZFfY for ; Sat, 8 Apr 2017 13:11:33 -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 6B592120326 for ; Sat, 8 Apr 2017 13:11:33 -0700 (PDT) Received: (qmail 65714 invoked from network); 8 Apr 2017 20:11:32 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 8 Apr 2017 20:11:32 -0000 Date: 8 Apr 2017 20:11:10 -0000 Message-ID: <20170408201110.57805.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org Cc: tony@att.com In-Reply-To: <363EDD8B-2654-4D81-AD41-D355599D3143@att.com> 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] Fwd: New Version Notification for draft-srose-dkim-ecc-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: Sat, 08 Apr 2017 20:11:35 -0000 In article <363EDD8B-2654-4D81-AD41-D355599D3143@att.com> you write: >-=-=-=-=-=- >Right now we require support for two types of keys: a weak one (sha1) and a strong one (sha256). True, but it's important to note that we don't require anyone to sign with weak keys. A key record in the DNS can contain "h=sha256" to say no SHA1 signatures accepted. I've set my key records like that for years. R's, John From nobody Wed Apr 12 04:43: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 2A79612944E for ; Wed, 12 Apr 2017 04:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.697 X-Spam-Level: X-Spam-Status: No, score=0.697 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=crash.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JExf5kWTKdqR for ; Wed, 12 Apr 2017 04:43:31 -0700 (PDT) Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9701131680 for ; Wed, 12 Apr 2017 04:43:31 -0700 (PDT) Received: from shiny.crash.com (70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26]) (authenticated bits=0) by segv.crash.com (8.14.5/8.14.5/cci-colo-1.6) with ESMTP id v3CBhJqq058022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 12 Apr 2017 04:43:24 -0700 (PDT) (envelope-from smj@crash.com) X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com v3CBhJqq058022 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1491997404; bh=i1b/XauMHPbX9gsn3EIVjf01yMpPb1ZKBDjr9KhJ2J0=; h=To:From:Subject:Message-ID:Date:MIME-Version:Content-Type: Content-Transfer-Encoding; b=bu7Uok3ibjjM78B2IHZ7jmu7KqoEGXAR1P1Cq8J0R5RMhIDHsRR8aTMlEdu2bU/R7 q88aZWXfL5fENcG0CXkPlKqyqMS4488MUU50TE2yUMDXV42pyKTYHRhxrGq6SZ2frU wL6NN0jViohu2dBa78WlYxgAu0v6zwZY7Ws2DuDofo4YJI+AyOh1kzk08W5MAsVuHL dW+sTaVXTxLcvrrXEcFzgfuEEMSl9FlO8nh2RqqqEY2q1ewqHaXdko2IJEbIg0lF+W jZpwW9zjc8P8/FArVAwRRrDonaLv96LXQCEt/qM/DM+z1iJa10j69EB83YXciNY/Uk 6qaTpJe0oyYww== X-Authentication-Warning: segv.crash.com: Host 70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26] claimed to be shiny.crash.com To: arc-discuss@dmarc.org, dmarc@ietf.org From: Steven M Jones Message-ID: <58a6add0-6edb-5bfd-f1cb-0dba22b8762a@crash.com> Date: Wed, 12 Apr 2017 04:43:21 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (segv.crash.com [72.52.75.15]); Wed, 12 Apr 2017 04:43:24 -0700 (PDT) Archived-At: Subject: [dmarc-ietf] Anybody new for a possible interop in Lisbon, week of M3AAWG? 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, 12 Apr 2017 11:43:33 -0000 >From time to time we've organized interoperability testing sessions for ARC implementers. We have the opportunity to hold one the week of the M3AAWG meeting in Lisbon, Portugal in June. Is there anybody who hadn't previously raised their hand as an implementer, who has or is developing an implementation and would want to participate in such a test? We haven't had one in Europe before, and it's not clear when such an opportunity might arise again. So if it's something you wish to see happen, please speak up. Thanks, --Steve. From nobody Sun Apr 16 23:59: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 4552012878D for ; Sun, 16 Apr 2017 23:59:30 -0700 (PDT) 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, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 KNOAC4S_Wjz1 for ; Sun, 16 Apr 2017 23:59:28 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::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 E0ABC1243F6 for ; Sun, 16 Apr 2017 23:59:27 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id y33so12110425qta.2 for ; Sun, 16 Apr 2017 23:59:27 -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=ii4LaccQ43AglI7EkA6PMmk2F+gEJjqQzFKmUCtIfHE=; b=JD/MClDJ8t6p6MQ95NWBqlEI/N4V9W6nkheb/0TqleD0I5ScGkfQrCv7GftZz8qa8F LeUMnkN+F83TVtUp+bT9ctrSCl/HlE8R3gYrbQd3giPbyhwhT+rE7GI7/IQ2RYBA0/rP tr1dprt71sokFWDU9fnXk9wdBJIrLB1K0FCajNIRv/ChWbgrlR2cliMXtPd3ChVc2RCj wPSqmQUvsC+kTtTM1NeAtYyjHuomcROrtI6h1p0z7GSaFTGLiATjUPY66iwiQo4TH7h5 It2O7ttnc9SLlGsZ5evKo45g5LrX3/v7hYZdJKETNAgxaGEVISOhI6kCuVOiQlsjvRwK zhRw== 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=ii4LaccQ43AglI7EkA6PMmk2F+gEJjqQzFKmUCtIfHE=; b=tVRHH+vyjsdKQXHd6Kso15j8BzdGyniOci/0LoA5WZx61T53/cu7Y1sXT1LoSFwp9S E90AXOGdqncL3Dofh6hN4S8tujGmZewmSi7Ybry7OL+xiy2XQCuFaw4LayhWbEB9y6pQ jPJ0AlqsydPsVT3VPEHCNudiii2pbTHTkVLaNVR6QBFESjsbGHflNj9u5uGmXm83amxc xuKhM9Bjzu9YCmyIq0ourPpqc22KoWQ4cEDp+52XdtqtdzftkTq4hzACif4p6HrJrKeu e6xo3FKyv0rAMyf2x+n7tBfuqpV4PL1BM2YWXkZHpBQcgS/PllNqyGUnNOCWVjKfsNKc JRWw== X-Gm-Message-State: AN3rC/5ix7KDU6Om82KpWktWF5xHKqoecPQUJ1hE7uRXeW7gg0xrhLnf Q1A1EuIfTka6VWypxL+rb1cGeAPUIw== X-Received: by 10.200.53.45 with SMTP id y42mr7842312qtb.136.1492412366893; Sun, 16 Apr 2017 23:59:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.144.161 with HTTP; Sun, 16 Apr 2017 23:59:26 -0700 (PDT) From: Peter Goldstein Date: Sun, 16 Apr 2017 23:59:26 -0700 Message-ID: To: Barry Leiba , dmarc Content-Type: multipart/alternative; boundary=001a11403cc8fccd5e054d5754db Archived-At: Subject: [dmarc-ietf] DMARC Working Group Activity at IETF 99 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, 17 Apr 2017 06:59:30 -0000 --001a11403cc8fccd5e054d5754db Content-Type: text/plain; charset=UTF-8 Barry, On Friday's DMARC.org call, the topic of DMARC Working Group activity at IETF 99 came up. There was some discussion of participating in the IETF hackathon, with a goal of adding ARC support to the IETF mailing list infrastructure. If we are going to be there to do ARC work in the hackathon, this may also be a good meeting for some face-to-face work on other current work items - namely the Draft Guide on DMARC Usage. An in-person meeting at IETF 99 might be a good forcing function for pulling together an initial draft version. Also, it looks like there may be some overlap between the DCRUP proposal and the on-list discussions regarding the use of cryptography for ARC. It may be valuable to have some of the ARC implementers participate in those discussions. Again, IETF 99 might be a good opportunity to make that happen. What do you think? Best, Peter -- [image: logo for sig file.png] Bringing Trust to Email Peter Goldstein | CTO & Co-Founder peter@valimail.com +1.415.793.5783 --001a11403cc8fccd5e054d5754db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Barry,

On Friday's DMARC.org call, = the topic of DMARC Working Group activity at IETF 99 came up.=C2=A0 There w= as some discussion of participating in the IETF hackathon, with a goal of a= dding ARC support to the IETF mailing list infrastructure.

If we are going to be there to do ARC work in the hackathon, this = may also be a good meeting for some face-to-face work on other current work= items - namely the Draft Guide on DMARC Usage.=C2=A0 An in-person meeting = at IETF 99 might be a good forcing function for pulling together an initial= draft version.

Also, it looks like there may be s= ome overlap between the DCRUP proposal and the on-list discussions regardin= g the use of cryptography for ARC.=C2=A0 It may be valuable to have some of= the ARC implementers participate in those discussions.=C2=A0 Again, IETF 9= 9 might be a good opportunity to make that happen.

What do you think?

Best,

Peter

--
=


3D"logo

Bringing Trust to= Email

Peter Goldstei= n | CTO & Co-Founder

peter@valimail.= com

+1.415.793.57= 83
<= /div>
--001a11403cc8fccd5e054d5754db-- From nobody Thu Apr 20 01:19: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 EF15E12EB6B for ; Thu, 20 Apr 2017 01:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.409 X-Spam-Level: X-Spam-Status: No, score=-0.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eudaemon.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdDCabzmqyB0 for ; Thu, 20 Apr 2017 01:19:40 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D977312EB3C for ; Thu, 20 Apr 2017 01:19:39 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id w64so97644268wma.0 for ; Thu, 20 Apr 2017 01:19:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eudaemon.net; s=dkey; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=QmiX7Sxg72/fsOkE5wYaiCY3UHcuLZQJOdxWCo0Vwgc=; b=kXFoBYSjhZl0HqdzIzoUBSmONEVC66eQbiwbbEJ+QfgD9afqRt7wP5hx8wPmfdbTSD KaSjj5Y+T3SN9d8dsDF8xWLqXgKen5knP0CLMpzkc4qVW4jPkrV2RBnaf5HpVKfLPRnM hO98ChWgronRrNXxKdtKcXhAg5acRQPXsVkiE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=QmiX7Sxg72/fsOkE5wYaiCY3UHcuLZQJOdxWCo0Vwgc=; b=QzmmVLf/7RDB4JkA8y3+69KzTCLYHFpCKE4IYT140FY9BNsC8U5oOcVa2Jn8OAEPC1 AdgecHOy/zCnbZEbupcJHFVb/TsXg9ooRo2KlLIPxSycLgJCP+lpzb/UpieqAk/aXdHR 0U4FlMi25O0DJz4UIfEBgQIe3rjk55d8pe4Bm5PVtT7EOHiFu6pFoKeJsol3+56UlDQd gaqR6wLr9jlmh3Z8Yfh6oqscLKFThBlEgfeHayArPC4RgcUJC/PVbffoNr+886Zpz3IV sVhpe2dN/T4pZHlhyM18xXJoSlI6UtXb1BN5AdL2QIpanT4TVKeetvsdtnd4yM+nwg9k 5SBQ== X-Gm-Message-State: AN3rC/7kbMFDqnumdylGkrtrksbJwevL3wY+9sYuVngBgqtlfH8kgg5o cIZud/LH6DDULfsfZ3o= X-Received: by 10.28.49.136 with SMTP id x130mr1800554wmx.137.1492676378119; Thu, 20 Apr 2017 01:19:38 -0700 (PDT) Received: from [10.21.179.222] ([89.248.140.9]) by smtp.gmail.com with ESMTPSA id o1sm5501024wmd.16.2017.04.20.01.19.36 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 20 Apr 2017 01:19:37 -0700 (PDT) From: Tim Draegen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <216C9467-1362-4111-A69F-28B551A4B972@eudaemon.net> Date: Thu, 20 Apr 2017 05:36:43 +0100 To: dmarc Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [dmarc-ietf] Usage Guide update 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, 20 Apr 2017 08:19:41 -0000 A minor update: an Abstract, Intro, and Outline have been written up. = Half a dozen people (those that previously volunteered on this list) are = putting meat on the bones now to get an initial reviewable draft into = place. From nobody Fri Apr 28 11:27: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 655F4127241 for ; Fri, 28 Apr 2017 11:27:06 -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 BSkwjAM0TCyd for ; Fri, 28 Apr 2017 11:27:04 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C78ED127869 for ; Fri, 28 Apr 2017 11:26:44 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id p80so73042074iop.3 for ; Fri, 28 Apr 2017 11:26:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=rmxllXIW86p3tdSfPsqYoN3zla1BDgiBl73pXUMrELs=; b=INoCvC2uaFJmv9uNToJzjL6aJ7oQRAAmuFO826ayKo86WHOjXH6nmTWLS9Pd5RTrD8 Nk7uksIq3nch6TfWBGElKFoqYAKYol2jtBvnEqu5CjLU5NogTAE2/JFA/Q5d+Ph+v513 ostqSnFVZ83Tkn63WvjGtH14bmSsY5y7vqqew0k9tpVrcSZz1ZJ7j2X+Pj5xYqVtQvba OzwjyncDWMgV8CNDK/3rEq54O+sphttJl7EzTfnRzaXG3VazqswE4r5RcNNeSK3mLBlA FNDZrvcTrIw0UUxdMh6at9hrVsttvBubBc+pSeAWDD8iRb76wcs1oyufFRaM9CPOvSxU iP7g== 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=rmxllXIW86p3tdSfPsqYoN3zla1BDgiBl73pXUMrELs=; b=HNKGpO6FGaFG1IrncghlLmRTcoVtwGEDazshEw80BhD1tMPHuvphhEVbGg0n2ug039 uAwnngSgB2MRCDJVlkvgHB3ygLV8rWOaQPNPjfABfnoTv4g4AWhrPCSKWVKQA6a6tEBq L6fQPNgXNjFKQ1DWofamDO2qVueGRWjiK6pwoPeCjmG9h4EvKSkhOg6Wp1LJ5Sgc6wPG RS/a7vrlHEGGGFyreqf0jvjekfsjbT/hTN++TwzSM0+5dU8mV+02KcDrlIdpkIS0M5gw ZRTqHCgXCny+3F0nNs7GMd4UHqL7l9mnDQ9d8ktu3C4dn4ZdobbB21SgeIBhNNJp61jJ 0YEg== X-Gm-Message-State: AN3rC/6zLc8WLzvXfEXiKD27GW0dGSaU5asOIR7vXR5i4aLt0vJyxxoH yfPcPTBQJzNspmmbYkDWH9UQPxF4qgL+ACg= X-Received: by 10.157.50.200 with SMTP id u66mr5642391otb.121.1493404003307; Fri, 28 Apr 2017 11:26:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.8.101 with HTTP; Fri, 28 Apr 2017 11:26:42 -0700 (PDT) From: Brandon Long Date: Fri, 28 Apr 2017 11:26:42 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a11493980201817054e3e376b Archived-At: Subject: [dmarc-ietf] implementation update 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, 28 Apr 2017 18:27:06 -0000 --001a11493980201817054e3e376b Content-Type: text/plain; charset=UTF-8 Gmail/Google has deployed our implementation of ARC to our mail system. At this point, we aren't creating new ARC chains, yet, but any message with an existing arc chain will be validated and signed. Let us know if you see any issues. We expect to start creating our own chains in the next couple weeks, baring issues. Brandon --001a11493980201817054e3e376b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Gmail/Google has deployed our implementation of ARC to our= mail system.

At this point, we aren't creating new = ARC chains, yet, but any message with an existing arc chain will be validat= ed and signed.

Let us know if you see any issues.<= /div>

We expect to start creating our own chains in the next couple= weeks, baring issues.

Brandon
--001a11493980201817054e3e376b-- From nobody Fri Apr 28 11:36: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 A3A21126D05 for ; Fri, 28 Apr 2017 11:36:02 -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=teamaol.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 rymXUQTccVdi for ; Fri, 28 Apr 2017 11:35:59 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DAAB126C7A for ; Fri, 28 Apr 2017 11:35:04 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id y63so59940840qkd.1 for ; Fri, 28 Apr 2017 11:35:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=teamaol.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=64BKuvGwIy1swHjiYVBDEUPPyMF6cJhIwoXW1mGnTCA=; b=NLq+y/B3Oz7MpR5fMAiJ7sKlNuCRKsJ0ekkEz1SppEXzucp8OK2qbRu0eHaBAafs0m tFaKo5/3HTRIrpOCDuYqWrjyNkk6SFWnxY75YY0enXA+fMZMO2gVA81DraAoSS04C+mb CbjMYgGDYljhj7Pz3tBWGP1D2xA5XSCfUaFcDUj9psyN5/Njn/RABBek8eQ2GghIHJ84 J/Z9RMvTa2Qe1SeHkQjNV2Scdyg3M75A7Nd01y7VBj2iDMyYPtPVQ73fpmEVlRmLszJK NIrilohAEP0d0bcwps79Ohebj6SNCw761QphmqmDZnuFuJSG7ov8kI5Y3bBITF1JFK8Q px/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=64BKuvGwIy1swHjiYVBDEUPPyMF6cJhIwoXW1mGnTCA=; b=qQIT245Ky1PjPHQKUab+OStg7A6tD8Pwre1rJJY9fEeOwxu7uIHZ//G5w3t1wwYq4G 0Z3OoxhqJqcmbI95TFeanCVxlEExNIHtLJDioPIoU0FCp6uzF3H5qDQgnzN9II4DKkoZ EXNOQbmzj132e2YhPA7uiRMNqRqPjInjkI4vv+tkiTxo4SRqGlRCSN6zeDL2qniDrWB4 dlprolj9MFOr7M+xfMJRPjvGw/uDn3wuMfIzLpNLOQ/BH58bVq5WYFoon6XrW2RHC0TT gQJy5ombKtAV4pMuzlEg/IoK9OdQZ/hm14gvYKn7/M7QPF8evOPBt6r/FchD9uJp2uQQ O1bQ== X-Gm-Message-State: AN3rC/62DT0U2koP7xTAvjDBuBCzzw7gaFTwS231lhzDxheEr4bWVSg/ +vhuX0ZXnMZdy+6h5uNpPZ0KLpgQVWUdUbA= X-Received: by 10.55.114.199 with SMTP id n190mr11442110qkc.229.1493404503262; Fri, 28 Apr 2017 11:35:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.56.46 with HTTP; Fri, 28 Apr 2017 11:35:02 -0700 (PDT) In-Reply-To: References: From: Paul Rock Date: Fri, 28 Apr 2017 14:35:02 -0400 Message-ID: To: Brandon Long Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a114ff44cec75dc054e3e545f Archived-At: Subject: Re: [dmarc-ietf] implementation update 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, 28 Apr 2017 18:36:03 -0000 --001a114ff44cec75dc054e3e545f Content-Type: text/plain; charset=UTF-8 YAY! :-) Gratz guys. On Fri, Apr 28, 2017 at 2:26 PM, Brandon Long wrote: > Gmail/Google has deployed our implementation of ARC to our mail system. > > At this point, we aren't creating new ARC chains, yet, but any message > with an existing arc chain will be validated and signed. > > Let us know if you see any issues. > > We expect to start creating our own chains in the next couple weeks, > baring issues. > > Brandon > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > -- PAUL ROCK Principal Software Engineer | AOL Mail P: 703-265-5734 | C: 703-980-8380 AIM: paulsrock 22070 Broderick Dr.| Dulles, VA | 20166-9305 --001a114ff44cec75dc054e3e545f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
YAY! :-)

Gratz guys.

On Fri, Apr 28, 2017 at = 2:26 PM, Brandon Long <blong@google.com> wrote:
Gmail/Google has deployed our impleme= ntation of ARC to our mail system.

At this point, we are= n't creating new ARC chains, yet, but any message with an existing arc = chain will be validated and signed.

Let us know if= you see any issues.

We expect to start creating our own chai= ns in the next couple weeks, baring issues.

Brandon

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




--
=
PAUL ROCK
Principal Software Engineer | AOL Mai= l
P: 703-265-5734 | C: 703-980-8380
AIM: paulsrock
22070 Broderick Dr.<= /font>| Dulles, VA | 20166-9305
=
--001a114ff44cec75dc054e3e545f-- From nobody Fri Apr 28 16:02:31 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 1A94E12951E; Fri, 28 Apr 2017 16:02:30 -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.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149342055006.2899.6994451295388593168@ietfa.amsl.com> Date: Fri, 28 Apr 2017 16:02:30 -0700 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-03.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: Fri, 28 Apr 2017 23:02:30 -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-03.txt Pages : 45 Date : 2017-04-28 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-03 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-protocol-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-protocol-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 28 16:07: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 2158B124C27 for ; Fri, 28 Apr 2017 16:07:43 -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 (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k_JpcRuMOt34 for ; Fri, 28 Apr 2017 16:07:40 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F3CE126DC2 for ; Fri, 28 Apr 2017 16:04:56 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id o76so15549316vkc.2 for ; Fri, 28 Apr 2017 16:04:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:from:date:message-id:subject:to; bh=Hv0jldMx8EFtHcnf62RJCzJWewMMDs77exLivVrQ3C4=; b=SMI3Vix0t9ZsG4qmFEPZ8na3sJMDPG8VXE6ePa43VaUb+Vd88xMkFkqp2dowd6lsJP U20+cR6iX3tYWNp1OoB2M42noe2cqFb7q83Ks9MreRWHBLDW6EtpjCq+g7dSjT1Wzz7e RKEuReNqTL/ipQ2zao/01/B9KRc3/qUxCocnU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=Hv0jldMx8EFtHcnf62RJCzJWewMMDs77exLivVrQ3C4=; b=pBuGUR4+zzBwgS3PFWtY+HmJKYZ+RLrNGC3AVdifZ9FzfXfKlYCZp8Tlbo87Sqazt8 e3ssPGpStRpDGYnzxFjUfa0f6ofXLu+pNO6UChvJxAnfajJHQHFIMcehEqkgOOYnz+zS g4cscYVEYgSn+B4exOdENFNWBbmYXiak8Jtd+A5g/ax4sta0Vwocnd0ZJ2wbXMOBddto sXCI2Q5FacQq19aZiBy6ep5ypz9kkG3N8pPweuhKMeTdZWCHsyk7ld/yai3Fj4/iXDDy K897O4W9U7fK7XW5Rj9p9M0dHOsHVhUly1lz8jDSAhHGa7ixDJoME65gZWeXwqydP4kO YSUw== X-Gm-Message-State: AN3rC/77EsT1Jj7KmLhR7a98e4s0OBDHb8Q2L7uszwlpSyqVl46wz9Py NRrQeSX8AoE05IiOLmyuAmCfkaWVypSwK04= X-Received: by 10.31.49.80 with SMTP id x77mr6889341vkx.82.1493420695364; Fri, 28 Apr 2017 16:04:55 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.176.4.115 with HTTP; Fri, 28 Apr 2017 16:04:54 -0700 (PDT) From: "Kurt Andersen (b)" Date: Fri, 28 Apr 2017 16:04:54 -0700 X-Google-Sender-Auth: u0h_ZipRV8yVfgiUDzUf7TReoG4 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a1143ea7c0c3fb0054e421adb Archived-At: Subject: [dmarc-ietf] Just posted dmarc-arc-protocol-03 . . . 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, 28 Apr 2017 23:07:43 -0000 --001a1143ea7c0c3fb0054e421adb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Based on the dialog around the AAR header unclarity in section 5.1.3, I adjusted the first paragraph to read: ARC-Authentication-Results is a copy of the Authentication-Results header > field [RFC7601] value with the corresponding ARC-set instance (=E2=80=9Ci= =3D=E2=80=9D) tag > value prefixed to the Authentication-Results value string. Since > Authentication-Results headers are frequently deleted from a message=E2= =80=99s > header list, the AAR is created for archival purposes by each > ARC-participating ADMD outside of the trust boundary of the originating > system. I hope that clarifies. --Kurt --001a1143ea7c0c3fb0054e421adb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Based on the dialog around the AAR header unclarity in sec= tion 5.1.3, I adjusted the first paragraph to read:

ARC-Authentication-Results is= a copy of the Authentication-Results header field [RFC7601] value with the corresponding ARC-set instance (=E2=80=9Ci=3D=E2=80=9D) tag= value prefixed to the Authentication-Results value string. Since=20 Authentication-Results headers are frequently deleted from a message=E2=80= =99s=20 header list, the AAR is created for archival purposes by each=20 ARC-participating ADMD outside of the trust boundary of the originating=20 system.

I hope that clarifies.
--Kurt=C2=A0

--001a1143ea7c0c3fb0054e421adb-- From nobody Fri Apr 28 16:39:01 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 AF79B129548 for ; Fri, 28 Apr 2017 16:38:59 -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 ytNE1MECmvXw for ; Fri, 28 Apr 2017 16:38:56 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::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 548FF129489 for ; Fri, 28 Apr 2017 16:36:25 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id m36so61698975qtb.0 for ; Fri, 28 Apr 2017 16:36:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=m7BiZFaD6BzdyAFBmjXl6N8YoTA9hrNpCcMstgHIBAc=; b=eqayDUO9S4RghLalzStoVd5C/jMj5EWr92bBl3bzBPn5ORbn0PwjYPCm7fIYbVWWJl zoSLqzkwajz5mgZ7tz1nJI3RQoT2j6vKE9hqzQ3J+hgV4rgG2V/Hc9xSS04RhHfYPtvA 6VxZXPiPIK/+ni7RXkheRkxBXuzkOlMRGePIK+qdERqUktlDgQP0DcncdouLrPnhPFyD LWw+mubTjGi6R1vH/+lFsiz683GQ51Bq/eC56V2ZVLcs82YdKqWlngGPUzt09DHZjxUG 4Um2exacdPbITOpwo+DuanrzYTjmmjN1rDMtfXJ4ztR2G3aTb7qWZAmTuvySZ2YgWME8 SD5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=m7BiZFaD6BzdyAFBmjXl6N8YoTA9hrNpCcMstgHIBAc=; b=Y7LRDUQbMDbHRbbNKn43Uv3aCnny3GIhi40RC4VcC0Vl2x+TH4nzz4noPA86/6SVpF pcnY8GS+3x7u1h542qE36Q95Mr55jz95mhAM0LFabRtwuAvuRB2yRpURkglyNYMIuWNK b3hENYS9KzARO+czbVFaQyg8yx8YG15izXuhbGAJeVAHnbl7Ob0Wjkk/7EJxAfJAlnLp ezmCezYAfQgrBWPMVzzeoetJPD8tGGuWR3lNqv3JuI0F5RodKw0vkZFf/4wKYyCmmNpP fQ/u9VO0hstrHGRQ+zsPyf3MiXo8oMCLfjkMzRTWNA5N0thQsO5tPZD4cPke5sluKMtB QdgQ== X-Gm-Message-State: AN3rC/4rOXH8Bk2TE9DXSv2/T7CN7Tq69tz/cxK3Ex5w5PTUxxleENq/ 3ba1lf6GpfsxTY64BgBnOLngDR7kgxLY X-Received: by 10.200.2.145 with SMTP id p17mr13188634qtg.180.1493422584169; Fri, 28 Apr 2017 16:36:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Seth Blank Date: Fri, 28 Apr 2017 23:36:13 +0000 Message-ID: To: Brandon Long , Paul Rock Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=f4030435a9c4a11c5d054e428ac9 Archived-At: Subject: Re: [dmarc-ietf] implementation update 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, 28 Apr 2017 23:39:00 -0000 --f4030435a9c4a11c5d054e428ac9 Content-Type: text/plain; charset=UTF-8 Excellent news, congrats! On Fri, Apr 28, 2017 at 11:36 Paul Rock wrote: > YAY! :-) > > Gratz guys. > > On Fri, Apr 28, 2017 at 2:26 PM, Brandon Long wrote: > >> Gmail/Google has deployed our implementation of ARC to our mail system. >> >> At this point, we aren't creating new ARC chains, yet, but any message >> with an existing arc chain will be validated and signed. >> >> Let us know if you see any issues. >> >> We expect to start creating our own chains in the next couple weeks, >> baring issues. >> >> Brandon >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> >> > > > -- > PAUL ROCK > Principal Software Engineer | AOL Mail > P: 703-265-5734 | C: 703-980-8380 > AIM: paulsrock > 22070 Broderick Dr.| Dulles, VA | 20166-9305 > _______________________________________________ > 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 --f4030435a9c4a11c5d054e428ac9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Excellent news, congrats!

On Fri, Apr 28, 2017 at 11:36 Paul Rock <paul.rock@teamaol.com> wrote:
YAY! :-)

Gratz guys.

On Fri, Apr 28, 2017 at 2:26 PM, Brandon Long <blong@google.com> wrote:
Gmail/Google has deployed= our implementation of ARC to our mail system.

At this p= oint, we aren't creating new ARC chains, yet, but any message with an e= xisting arc chain will be validated and signed.

Le= t us know if you see any issues.

We expect to start creating = our own chains in the next couple weeks, baring issues.

B= randon

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




--
PAUL ROCK
Principal Software Engineer | A= OL Mail
P: 703-265-5734 | C: 703-980-8380
AIM: paulsrock
22070 Broderick Dr.| Dulles, VA | 20166-9305
=
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--

3D"logo

= Bringing Trust to Email

= Seth Blank | Head of Product <= span style=3D"font-size:14px;white-space:pre-wrap">for Open Source and Prot= ocols

seth@valimail.com
+1-415-894-2724
--f4030435a9c4a11c5d054e428ac9-- From nobody Sat Apr 29 00:48:36 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 3CE80129ACD for ; Sat, 29 Apr 2017 00:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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 (1024-bit key) header.d=isode.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 VBgkQAA3zhOd for ; Sat, 29 Apr 2017 00:48:32 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC241294AF for ; Sat, 29 Apr 2017 00:46:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1493451982; d=isode.com; s=june2016; i=@isode.com; bh=ZBtqwCBzAo6xt7wV8BPrbLSllTnxOJYS3FbcBh++kR8=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=ENiTXzpBX+GEcOy35cZhyIPIpOuyoaGpOXgpm+A1yOtWhrn02keqgcuCgd9HmgUaJahJPC EEIAwPlR1RUpJYeUhLczHLDrsF+ThfotFNb7+XBy7Q/mbuVql7nKGzbYkIf0yy39pARyp/ sxPg38AZTtU91osVTGOP8PM5aqwek3A=; Received: from [192.168.0.6] (cpc121086-nmal24-2-0-cust54.19-2.cable.virginm.net [77.97.145.55]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Sat, 29 Apr 2017 08:46:22 +0100 X-SMTP-Protocol-Errors: PIPELINING From: Alexey Melnikov Date: Sat, 29 Apr 2017 09:07:50 +0100 Message-Id: <5433FF67-E01B-414A-B390-EEE8018A2274@isode.com> References: <149339602226.2847.3878770255715267653.idtracker@ietfa.amsl.com> To: dmarc@ietf.org X-Mailer: iPad Mail (14A456) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=Apple-Mail-AB8FDB57-2F7A-447F-A87C-B18DBA8B515D Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] Fwd: WG Action: Formed DKIM Crypto Update (dcrup) 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, 29 Apr 2017 07:48:35 -0000 --Apple-Mail-AB8FDB57-2F7A-447F-A87C-B18DBA8B515D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Please join the dcrup@ietf.org mailing list if you are interested in this wo= rk. Begin forwarded message: > From: The IESG > Date: 28 April 2017 at 17:13:42 BST > To: "IETF-Announce" > Cc: dcrup@ietf.org, dcrup-chairs@ietf.org, The IESG > Subject: WG Action: Formed DKIM Crypto Update (dcrup) >=20 > A new IETF WG has been formed in the Applications and Real-Time Area. For > additional information, please contact the Area Directors or the WG > Chairs. >=20 > DKIM Crypto Update (dcrup) > ----------------------------------------------------------------------- > Current status: Proposed WG >=20 > Chairs: > Rich Salz > Murray Kucherawy >=20 > Assigned Area Director: > Alexey Melnikov >=20 > Applications and Real-Time Area Directors: > Adam Roach > Ben Campbell > Alexey Melnikov >=20 > Technical advisors: > Eric Rescorla >=20 > Mailing list: > Address: dcrup@ietf.org > To subscribe: https://www.ietf.org/mailman/listinfo/dcrup > Archive: https://mailarchive.ietf.org/arch/browse/dcrup/ >=20 > Group page: https://datatracker.ietf.org/group/dcrup/ >=20 > Charter: https://datatracker.ietf.org/doc/charter-ietf-dcrup/ >=20 > The DKIM Crypto Update (DCRUP) Working Group is chartered to update > DomainKeys Identified Mail (DKIM, RFC 6376) to handle more modern=20 > cryptographic algorithms and key sizes. DKIM (RFC 6376) signatures=20 > include a tag that identifies the hash algorithm and signing algorithm=20 > used in the signature. The only current algorithm is RSA, with advice=20 > that signing keys should be between 1024 and 2048 bits. While 1024 bit=20 > signatures are common, longer signatures are not because bugs in DNS=20 > provisioning software prevent publishing longer keys as DNS TXT records. >=20 > DCRUP will consider three types of changes to DKIM: additional signing > algorithms such as those based on elliptic curves, changes to key > strength advice and requirements, and new public key forms, such as > putting the public key in the signature and a hash of the key in the > DNS to bypass bugs in DNS provisioning software that prevent publishing > longer keys as DNS TXT records. It will limit itself to existing > implemented algorithms and key forms. Other changes to DKIM, such as new > message canonicalization schemes, are out of scope. The WG will as far=20= > as possible avoid changes incompatible with deployed DKIM signers and=20 > verifiers. >=20 > Milestones: > Oct 2017 - Agree what algorithms and key formats to add or deprecate > Dec 2017 - Submit WG draft to IESG as Proposed Standard --Apple-Mail-AB8FDB57-2F7A-447F-A87C-B18DBA8B515D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Please join the dcrup@ietf.org mailing list if you are interested= in this work.

Begin forwarded message:

From: The IESG <iesg-secretary@ietf.org>
Date: 28 April 2017= at 17:13:42 BST
To: "IETF-Announce" <ietf-announce@ietf.org>
Cc: dcrup@ietf.org, dcrup-chairs@ietf.org, The IESG <iesg@ietf.org>
Subject: WG Action: Formed DKIM Crypto U= pdate (dcrup)

<= span>A new IETF WG has been formed in the Applications and Real-Time Area. Fo= r
additional information, please contact the Area Directors o= r the WG
Chairs.

DKIM Crypt= o Update (dcrup)
-------------------------------------------= ----------------------------
Current status: Proposed WG

Chairs:
 Rich Salz <<= a href=3D"mailto:rsalz@akamai.com">rsalz@akamai.com>
=  Murray Kucherawy <superuser= @gmail.com>

Assigned Area Director:<= /span>
 Alexey Melnikov <aamelnikov@fastmail.fm>

App= lications and Real-Time Area Directors:
 Adam Roach &l= t;adam@nostrum.com>
 Ben Campbell <ben@nostrum.co= m>
 Alexey Melnikov <aamelnikov@fastmail.fm>
Technical advisors:
 Eric Rescorla <ekr@rtfm.com>

= Mailing list:
 Address: dcrup@ietf.org
 To subscribe: https://www.ietf.org/mailman/listinf= o/dcrup
 Archive: https://mailarchive.ietf.org/arch/browse/dcrup/<= /a>

Group page: https://datatracker.ietf.org/group/dcrup/

Charter: https://datatracker.ietf.org/doc/charter-ietf-dc= rup/

The DKIM Crypto Update (DCRUP) Wor= king Group is chartered to update
DomainKeys Identified Mail= (DKIM, RFC 6376) to handle more modern
cryptographic algor= ithms and key sizes. DKIM (RFC 6376) signatures
include a t= ag that identifies the hash algorithm and signing algorithm
used in the signature. The only current algorithm is RSA, with advice
that signing keys should be between 1024 and 2048 bits. While 10= 24 bit
signatures are common, longer signatures are not bec= ause bugs in DNS
provisioning software prevent publishing l= onger keys as DNS TXT records.

DCRUP will c= onsider three types of changes to DKIM: additional signing
a= lgorithms such as those based on elliptic curves, changes to key
<= span>strength advice and requirements, and new public key forms, such as
putting the public key in the signature and a hash of the key i= n the
DNS to bypass bugs in DNS provisioning software that p= revent publishing
longer keys as DNS TXT records.  It w= ill limit itself to existing
implemented algorithms and key f= orms. Other changes to DKIM, such as new
message canonicaliz= ation schemes, are out of scope.  The WG will as far
a= s possible avoid changes incompatible with deployed DKIM signers and =
verifiers.

Milestones:
=  Oct 2017 - Agree what algorithms and key formats to add or depr= ecate
 Dec 2017 - Submit WG draft to IESG as Proposed S= tandard

= --Apple-Mail-AB8FDB57-2F7A-447F-A87C-B18DBA8B515D--