From erik@halon.se Mon May 7 14:57:28 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 889DD12D7EF for ; Mon, 7 May 2018 14:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_ILLEGAL_IP=1.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=halon.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id It79KsKoOCDk for ; Mon, 7 May 2018 14:57:27 -0700 (PDT) Received: from se1-gles-flk1.inumbo.com (se1-gles-flk1.inumbo.com [IPv6:2a02:750:1::161:babe]) (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 F1670120713 for ; Mon, 7 May 2018 14:57:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=halon.se; s=spaceship; h=content-transfer-encoding:content-type:mime-version:date:message-id:to: subject:from; bh=Edy+7FRrrhw+KbM5ta5ZJ7r69XBG++r6rTZpKqloA84=; b=AoC0hpk/8liwncdyPsEwVkOZcYOyzCaorb1g8pqGHtVWggSWVeVcxbzFjbV6Wqw1Cy2pKnmXeENtM 68Z/+j0JJ9cF0LUJBG+DweYSfVDSZldpFpk0BztP+89dQa3Lf5tAhtyAuJBsYimBn811XrFMjqNViF nSwJA5OohiDDvnp4= X-Inumbo-Out-ID: 9de27512-5241-11e8-a224-2b6f30520076 X-Inumbo-Cookie: 3cd75c98b7b0a0ff6d97bf44d2b12e90a185473c Received: from mail.halon.se (unknown [212.85.68.184]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPSA id 9de27512-5241-11e8-a224-2b6f30520076; Mon, 07 May 2018 23:57:21 +0200 (CEST) Received: from Eriks-MacBook-Pro.local (unknown [192.0.2.149]) (Authenticated sender: erik) by mail.halon.se (Postfix) with ESMTPSA id D35C74E856 for ; Mon, 7 May 2018 23:57:20 +0200 (CEST) From: Erik Lax To: dmarc@ietf.org Message-ID: Date: Mon, 7 May 2018 23:57:20 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [dmarc-ietf] ARC draft feedback 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, 07 May 2018 21:58:28 -0000 We've been looking at implementing ARC in our MTA (Halon) and DKIM library and wanted to share the following findings A. If the DKIM selectors DNS record includes the flag t=s, the DKIM standard says we should match the i= tag with the d= tag. This is of course not possible for AMS since i= is reused for instance. This was an exception we had make in our shared validator for AMS and DKIM. I think it should be mentioned somewhere if it's not. B. There is plausibly a typo in draft-ietf-dmarc-arc-protocol-14#appendix-B.3.3 example where the "Authentication-Results: i=3; gmail.com; ..." header should probably be an AAR header since it begins with i=3; and is missing otherwise. Regards Erik From nobody Mon May 7 15:28:19 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7665D126C19 for ; Mon, 7 May 2018 15:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVjiNIgs19Uo for ; Mon, 7 May 2018 15:28:16 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EDF8124239 for ; Mon, 7 May 2018 15:28:16 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id v2-v6so26656441oif.3 for ; Mon, 07 May 2018 15:28:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=keCQyzPUqLnZD8L+kJ2/DDEr4MAG5P+P9vYwkHzy694=; b=dS5cJfhWaviqzciIMGUCbnTkud2UHvobaRddQ9PzeJN+QRskaN7F++W7LREz+qXlYp 6Gkl5IwIChfk5fodEm0539KTU+DCLtsmhcdyo2YsM/MzubmDpydurXhBWFdgEfkBLvn9 NlHYAfoC/C7+FrFgzdrksM8lh1sFRMXhOyprSc+zhEKQdsO4ZpvIJO51z7OVqtUck//H o41Zq+rNilcvpXmYC5v9PBFCgsjpNUw1QgkV/+phuDJ9sWbyE4V32JGiKIiRQUEsloCv HuQtLJhX+LH03JPvrFaZ/7TzGfhfpp3JR206Fa6DFEpUnBg0j9JTo0CiEvwTBsWbJXDF JehQ== 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=keCQyzPUqLnZD8L+kJ2/DDEr4MAG5P+P9vYwkHzy694=; b=ArZ7t6Ag7jNnIDBk5n/DxOfxc1ORZmKzvC+b2sYnTQuPA7XHizS46WOXXOqVpsj++C 9v8htqc5e69LJz4z+IVWpVmdTkE+7kbq03zGPOWaZtV4+z5UV+7bRtYOp30BwjwyeES+ 2cCs6ncyO9OYf4Pbtxqp8AfDZyFwqW7Aso7jT95h1Av3WjyWjBMLgwc15GJpqfJMA5H2 7bhXX8+xXwUYutRj9N3NXsIPRcKo7vx4EvGw7Hb0Hx3J4etaCKydbYUD+Kh3Qwc5p9eM pjL7fcTh0F07kJ/kU241vCYItOPYDN6Ow34f9L2Y0oqVt1pL1hdjZ44LWxKlxJK+RHJt cehA== X-Gm-Message-State: ALQs6tCCXTce5dklw6fQXmyq6zeR1xfV3awcFfSjF2UiylK3RZWqrM/1 ajTqJ/U519OFXZHBpZqRE6/Vd/wQIa/SHPmSyuYFg/pj X-Google-Smtp-Source: AB8JxZr3sOl4qGi5NbfWxFgESHytHRWb5oOtTe9HF/JiG/2sSnj0+LwoAmrtccA9J8Wo9+ZiOi0uHwSuWaIvGBMdu+o= X-Received: by 2002:aca:dc88:: with SMTP id t130-v6mr26504608oig.356.1525732095213; Mon, 07 May 2018 15:28:15 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:73d6:0:0:0:0:0 with HTTP; Mon, 7 May 2018 15:27:54 -0700 (PDT) In-Reply-To: References: From: Seth Blank Date: Mon, 7 May 2018 15:27:54 -0700 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="0000000000008ed975056ba52fab" Archived-At: Subject: Re: [dmarc-ietf] ARC draft feedback 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, 07 May 2018 22:28:18 -0000 --0000000000008ed975056ba52fab Content-Type: text/plain; charset="UTF-8" Hi Erik, Thank you very much for this feedback. We'll incorporate it into the next revision of the draft. Seth On Mon, May 7, 2018 at 2:57 PM, Erik Lax wrote: > We've been looking at implementing ARC in our MTA (Halon) and DKIM library > and wanted to share the following findings > > A. If the DKIM selectors DNS record includes the flag t=s, the DKIM > standard says we should match the i= tag with the d= tag. This is of course > not possible for AMS since i= is reused for instance. This was an exception > we had make in our shared validator for AMS and DKIM. I think it should be > mentioned somewhere if it's not. > > B. There is plausibly a typo in draft-ietf-dmarc-arc-protocol-14#appendix-B.3.3 > example where the "Authentication-Results: i=3; gmail.com; ..." header > should probably be an AAR header since it begins with i=3; and is missing > otherwise. > > Regards > > Erik > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --0000000000008ed975056ba52fab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Erik,

Thank you very much for this f= eedback. We'll incorporate it into the next revision of the draft.

Seth

On Mon, May 7, 2018 at 2:57 PM, Erik Lax <erik@halon.se> wrote:
We've been lookin= g at implementing ARC in our MTA (Halon) and DKIM library and wanted to sha= re the following findings

A. If the DKIM selectors DNS record includes the flag t=3Ds, the DKIM stand= ard says we should match the i=3D tag with the d=3D tag. This is of course = not possible for AMS since i=3D is reused for instance. This was an excepti= on we had make in our shared validator for AMS and DKIM. I think it should = be mentioned somewhere if it's not.

B. There is plausibly a typo in draft-ietf-dmarc-arc-protocol-14#appen= dix-B.3.3 example where the "Authentication-Results: i=3D3; gmail.com; ...&= quot; header should probably be an AAR header since it begins with i=3D3; a= nd is missing otherwise.

Regards

Erik

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

--0000000000008ed975056ba52fab-- From nobody Wed May 9 15:37:18 2018 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 87804129C5D; Wed, 9 May 2018 15:37:11 -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.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152590543150.10416.13701302015002249786@ietfa.amsl.com> Date: Wed, 09 May 2018 15:37:11 -0700 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-rfc7601bis-02.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2018 22:37:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance WG of the IETF. Title : Message Header Field for Indicating Message Authentication Status Author : Murray S. Kucherawy Filename : draft-ietf-dmarc-rfc7601bis-02.txt Pages : 48 Date : 2018-05-09 Abstract: This document specifies a message header field called Authentication- Results for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmarc-rfc7601bis-02 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-rfc7601bis-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-rfc7601bis-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 15 07:15:13 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09A7E12DA2C for ; Tue, 15 May 2018 07:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 AQ2j7WYbbwuJ for ; Tue, 15 May 2018 07:15:10 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BA5D12DA28 for ; Tue, 15 May 2018 07:15:10 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id a137-v6so16037707wme.1 for ; Tue, 15 May 2018 07:15:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:from:date:message-id:subject:to; bh=H+xNmyjJxw+MPU3TgBc+RqANFh6No0nqm7L0t4I1Rgo=; b=MW5JyJA41JLXiCDP9pyAWlbQ1BF2we0peUu38+rbO2lFQ5sQF3LQs1dBo7Q4H1aRj0 gvbiRHDhKyPbN4Vhn6lgb/R3z4T7OkrPIVi01igBdHgFuzE0lu2+zAL6nC5SStfA+ieK fhyYT7zOFJKBjJ1H02T6J6f9C4DyTr/9rx+1I= 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=H+xNmyjJxw+MPU3TgBc+RqANFh6No0nqm7L0t4I1Rgo=; b=WLXThaQ2rE4CGkSB1DZTorQpV5lMq9vc3zuhGLBllL2a6XTCVNOSiwNY0MH9BmMaI6 I/XQz7SWMlmlBym5bU7DTjlSii4DaJw+XZPCPgZCHFNhDVKVgPZ2rHPDAM25lZg3tip5 lV/cauArelikYLb97djknsiJXVkzAsVUnB4FgA7OPaoDeuJ4un9n+sCcFjeQk2A5JcXm RSC/b8uXOGEikteTsXntnfevQapzhScEbUJ/OiZh9xjbNZt3NMZSLJVIQDJo7RCRjStT 8mAE+QOSXlJEWAFlns1ygIHAn3BQO5aHbp2qYVHpRTWpAZtkyMF4U/FobJS/UtxmEdbr hMLA== X-Gm-Message-State: ALKqPwduOxkR9ofBwkGk/LIveFEFGJZSOW5LzMkB+d441NG5o6ZieGFe 6cblyEntqmIeiTUYbP2/cdUwqQRqxGLwMv856rt9+ytzftk= X-Google-Smtp-Source: AB8JxZr7jPI1fgrZrf9YmKugxbxna/V1Yus2qpHKSSOe2IUHcG7D3vzW5mwO36xIaen6s7f5y6Z7hybyIPVTk9AfGso= X-Received: by 2002:a50:ec16:: with SMTP id g22-v6mr18144832edr.242.1526393708364; Tue, 15 May 2018 07:15:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.142.201 with HTTP; Tue, 15 May 2018 07:15:07 -0700 (PDT) From: Kurt Andersen Date: Tue, 15 May 2018 07:15:07 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c65261056c3f3a15" Archived-At: Subject: [dmarc-ietf] Too bad that the EFAIL victims never heard of DKIM/DMARC 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, 15 May 2018 14:15:12 -0000 --000000000000c65261056c3f3a15 Content-Type: text/plain; charset="UTF-8" Manipulating MIME structures in email messages to expose the encrypted content: https://efail.de/ --Kurt --000000000000c65261056c3f3a15 Content-Type: text/html; charset="UTF-8"
Manipulating MIME structures in email messages to expose the encrypted content: https://efail.de/

--Kurt
--000000000000c65261056c3f3a15-- From nobody Tue May 15 07:39:24 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EEC912785F for ; Tue, 15 May 2018 07:39:23 -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 (1024-bit key) header.d=wordtothewise.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E_1ZWEmOHL6c for ; Tue, 15 May 2018 07:39:21 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [IPv6:2001:470:1:6d::9a]) by ietfa.amsl.com (Postfix) with ESMTP id CB41F12DA2C for ; Tue, 15 May 2018 07:39:20 -0700 (PDT) Received: from satsuke.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 8735723379 for ; Tue, 15 May 2018 07:40:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1526395219; bh=I0GQsRYTeU7VdUohfcLR2AG+bv9/ojxIdoaltjiPemA=; h=From:Subject:Date:References:To:In-Reply-To:From; b=X0SyMlMdwj5o4AK8l0rkX2rCfReTBCglA3csEQR8t/zFXIlYKzN0eLVOjtxxObM36 wyZPWWYGKl/aKRo263/OS7FNA7AuQP4UBbxLykIZ/ql1wTcLEDgCKC7x8q7N9ItWeG W+ibt6DpPkMshaoeRSSmOoDgcGQVc7VF2MeTVxZo= From: Steve Atkins Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 15 May 2018 07:39:18 -0700 References: To: dmarc In-Reply-To: Message-Id: <7DEB1CD3-3E41-4B1A-B062-A7E69A9E2ED3@wordtothewise.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dmarc-ietf] Too bad that the EFAIL victims never heard of DKIM/DMARC 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, 15 May 2018 14:39:23 -0000 > On May 15, 2018, at 7:15 AM, Kurt Andersen wrote: >=20 > Manipulating MIME structures in email messages to expose the encrypted = content: https://efail.de/ While I'd agree that the whole efail thing is a little over-hyped, I = don't see where in the exploit process having DKIM or DMARC would help in the slightest. Cheers, Steve= From nobody Tue May 15 07:53:41 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53A5B12DA2C for ; Tue, 15 May 2018 07:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.335 X-Spam-Level: * X-Spam-Status: No, score=1.335 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, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tnetconsulting.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 KhnuXB9pP_En for ; Tue, 15 May 2018 07:53:37 -0700 (PDT) Received: from tncsrv06.tnetconsulting.net (tncsrv06.tnetconsulting.net [IPv6:2600:3c00::f03c:91ff:fe26:8849]) (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 CD19C124D37 for ; Tue, 15 May 2018 07:53:37 -0700 (PDT) Received: from REDACTED ([IPv6:2620:0:102a:11:fe50:e322:5780:92c6]) (authenticated bits=0) by tncsrv06.tnetconsulting.net (8.15.2/8.15.2/Debian-3) with ESMTPSA id w4FErZtQ024191 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 15 May 2018 09:53:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tnetconsulting.net; s=2015; t=1526396017; bh=XzxaGli475jfOwsWrBeuPOR1CyHHLRJt/q/4OL3nuHs=; h=Subject:To:References:From:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type:Cc:Content-Disposition: Content-Language:Content-Transfer-Encoding:Content-Type:Date:From: In-Reply-To:Message-ID:MIME-Version:References:Reply-To: Resent-Date:Resent-From:Resent-To:Resent-Cc:Sender:Subject:To: User-Agent; b=mENy78x7ZmP+VJJduNnzg8QwBMojZyczdHVTGXTRgZ1iUyFKsL7tidza73JTq8l2T FxBsMCjqII+1OWH9gtVnO31zVchRzzwLzK4l4UKZ4lQe+RlNJWwsc9GCxb7mXfamkr fS0kjvxMLwcUzCgXnKo+iEnDWNc1l+gOuzA4IRm0= To: dmarc@ietf.org References: From: Grant Taylor Organization: TNet Consulting Message-ID: <66d513ca-f33d-748b-e394-bceb6e1da525@spamtrap.tnetconsulting.net> Date: Tue, 15 May 2018 08:53:35 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070602000609060606020803" Archived-At: Subject: Re: [dmarc-ietf] Too bad that the EFAIL victims never heard of DKIM/DMARC 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, 15 May 2018 14:53:39 -0000 This is a cryptographically signed message in MIME format. --------------ms070602000609060606020803 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 05/15/2018 08:15 AM, Kurt Andersen wrote: > Manipulating MIME structures in email messages to expose the encrypted = > content: https://efail.de/ DKIM will not help protect against #Efail. Efail works by copying ciphertext into a new message and arranging for=20 the client to decrypt it. Said new message is devoid of any association = with DKIM. --=20 Grant. . . . unix || die --------------ms070602000609060606020803 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CxcwggUpMIIEEaADAgECAhAIzwdZriPvq7FXSbc0jGReMA0GCSqGSIb3DQEBCwUAMIGXMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNzExMTcwMDAw MDBaFw0xODExMTcyMzU5NTlaMCsxKTAnBgkqhkiG9w0BCQEWGmd0YXlsb3JAdG5ldGNvbnN1 bHRpbmcubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvhfMhFM6CDAWL4Mg xrKLLbzTCILpI7uBzgG/HFXxV92MX4fba+pAotqOV8of7uF4YykVw94lCsOmFeVkb8VNSn6Q KSFbfnjXmYgU7XRtFHioTZihIynEXXI1LPMhnDXV9jCEzVvrlBx/6mSPdQcWhG1oMAlGd62w uu/CRE5U70LngVVat0wDJhdzrHxZabQlHhAPAvwMex8ObGDAkuieUCn5pQj2xqVKMB65vdcE ZydA8d8X8mvqHHOrEOg5xIwpca7E4JeUMxzYrdp3kVS7V+wXUui1nPwMb6o8WUe72FnL27BY mGqmtUGUc/ajGDUMS4xvabJ0M4Qc/NVGf56qDwIDAQABo4IB2jCCAdYwHwYDVR0jBBgwFoAU gq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFD8vJWpDFBkhAbiZGgx0EIUgH1EoMA4G A1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1odHRwczov L3NlY3VyZS5jb21vZG8ubmV0L0NQUzBaBgNVHR8EUzBRME+gTaBLhklodHRwOi8vY3JsLmNv bW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWls Q0EuY3JsMIGLBggrBgEFBQcBAQR/MH0wVQYIKwYBBQUHMAKGSWh0dHA6Ly9jcnQuY29tb2Rv Y2EuY29tL0NPTU9ET1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAlBgNVHREEHjAcgRpn dGF5bG9yQHRuZXRjb25zdWx0aW5nLm5ldDANBgkqhkiG9w0BAQsFAAOCAQEArDRhn6+otAvz JNgWiGsEeKawiBwqIlR8NSoiOpNYfpmZWS7A+X2mn/47nUT1KypbS3Mf8j8N1rf/FU53p0So WBsnqPAYajAaLjXnGoOEs8pOW0nK/vFYGJHdh8RXvxpPBOd7HUQCqsc4MGJUgasfrWdwqfAZ C1C0G7rNxY5Uvj8RFBPb7d+RfOaegUBMc5FDiXB3Xs43lUEWoWiMi6R3Y5PlQyrvLJB39cLw iLWlOom79addldgAaWZsxnwUDgQgth5ARr1Jw+nfNIimmauAtxDJMgaV17B4ODeuHI1jlPoG HS4+u/qVAwSYq4vtaCN1PSPHwqrrnERAj40c6yPyvzCCBeYwggPOoAMCAQICEGqb4Tg7/ytr nwHV2binUlYwDQYJKoZIhvcNAQEMBQAwgYUxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVh dGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMSswKQYDVQQDEyJDT01PRE8gUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4X DTEzMDExMDAwMDAwMFoXDTI4MDEwOTIzNTk1OVowgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQI ExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA vrOeV6wodnVAFsc4A5jTxhh2IVDzJXkLTLWg0X06WD6cpzEup/Y0dtmEatrQPTRI5Or1u6zf +bGBSyD9aH95dDSmeny1nxdlYCeXIoymMv6pQHJGNcIDpFDIMypVpVSRsivlJTRENf+RKwrB 6vcfWlP8dSsE3Rfywq09N0ZfxcBa39V0wsGtkGWC+eQKiz4pBZYKjrc5NOpG9qrxpZxyb4o4 yNNwTqzaaPpGRqXB7IMjtf7tTmU2jqPMLxFNe1VXj9XB1rHvbRikw8lBoNoSWY66nJN/VCJv 5ym6Q0mdCbDKCMPybTjoNCQuelc0IAaO4nLUXk0BOSxSxt8kCvsUtQIDAQABo4IBPDCCATgw HwYDVR0jBBgwFoAUu69+Aj36pvE8hI6t7jiY7NkyMtQwHQYDVR0OBBYEFIKvbIz4xf6WYXzo Hz0rcUhexIvAMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQK MAgwBgYEVR0gADBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9D T01PRE9SU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDBxBggrBgEFBQcBAQRlMGMwOwYI KwYBBQUHMAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1JTQUFkZFRydXN0Q0Eu Y3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wDQYJKoZIhvcNAQEM BQADggIBAHhcsoEoNE887l9Wzp+XVuyPomsX9vP2SQgG1NgvNc3fQP7TcePo7EIMERoh42aw GGsma65u/ITse2hKZHzT0CBxhuhb6txM1n/y78e/4ZOs0j8CGpfb+SJA3GaBQ+394k+z3ZBy WPQedXLL1OdK8aRINTsjk/H5Ns77zwbjOKkDamxlpZ4TKSDMKVmU/PUWNMKSTvtlenlxBhh7 ETrN543j/Q6qqgCWgWuMAXijnRglp9fyadqGOncjZjaaSOGTTFB+E2pvOUtY+hPebuPtTbq7 vODqzCM6ryEhNhzf+enm0zlpXK7q332nXttNtjv7VFNYG+I31gnMrwfHM5tdhYF/8v5UY5g2 xANPECTQdu9vWPoqNSGDt87b3gXb1AiGGaI06vzgkejL580ul+9hz9D0S0U4jkhJiA7EuTec P/CFtR72uYRBcunwwH3fciPjviDDAI9SnC/2aPY8ydehzuZutLbZdRJ5PDEJM/1tyZR2niOY ihZ+FCbtf3D9mB12D4ln9icgc7CwaxpNSCPt8i/GqK2HsOgkL3VYnwtx7cJUmpvVdZ4ognzg Xtgtdk3ShrtOS1iAN2ZBXFiRmjVzmehoMof06r1xub+85hFQzVxZx5/bRaTKTlL8YXLI8nAb R9HWdFqzcOoB/hxfEyIQpx9/s81rgzdEZOofSlZHynoSMYIENTCCBDECAQEwgawwgZcxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAIzwdZriPvq7FXSbc0 jGReMA0GCWCGSAFlAwQCAQUAoIICWTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xODA1MTUxNDUzMzVaMC8GCSqGSIb3DQEJBDEiBCBjTUz2/P6q2t87jm/u XDmTMG75eEqvCbxXfl9cZts1FDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglg hkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG BSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG9BgkrBgEEAYI3EAQxga8wgawwgZcxCzAJBgNVBAYT AkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAIzwdZriPvq7FXSbc0jGReMIG/ BgsqhkiG9w0BCRACCzGBr6CBrDCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0 ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0ECEAjPB1muI++rsVdJtzSMZF4wDQYJKoZIhvcNAQEBBQAEggEAqHjdV+M3 r4sUo24GK0/BKFUZA5NDmtvuTe2ML4rcosB1lh68CRT8FSSU0q9OWjsPs/VAl5IBL3+JRQPz va4DEgmzzNbJim+HVtopFYkMSLM/AkjaU4zxMdwdlaFuEkB1wSwYzv/GqY6Bf7KipAzqaqvj vdIQjRgVzlzQcsalZfnr//YPgT7T4xLdRGEtcuCiqcZZXdCG/pwf5r76Lzw4nD2eXTSgDeTG 6MgZ1uCFTl8K8cbOh2Z9zZU11F6dYQCiu31QAK0XZrRs3t4hrAY9oj5tA6KC3j2M8uX7xQox XUyyG8SIYQ8EH2N1h6Xl//BCVeZCxylmBGR4OdIKlHIu9gAAAAAAAA== --------------ms070602000609060606020803-- From nobody Tue May 15 09:09:36 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB6B012711E for ; Tue, 15 May 2018 09:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=l+CUTZyE; dkim=pass (1536-bit key) header.d=taugh.com header.b=Kb9ZuRLu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYtDeeRdo-Ih for ; Tue, 15 May 2018 09:09:33 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2407E124207 for ; Tue, 15 May 2018 09:09:33 -0700 (PDT) Received: (qmail 22664 invoked from network); 15 May 2018 16:09:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5886.5afb063c.k1805; bh=+Ui+viawavdG50xOv0NRF9hKnA/sm+T4NlBzgDDF9Lk=; b=l+CUTZyEHxIMoIB8aJ6BGNgsPa2uk2gh+SqpNlqWdEMTe2TehaHEq7P2CNsz1bnNiZ7iCf//DWPoX4mtz6ZByNAOi6Kqb8a85AX1Pgm4Ir4JVIXCSIdXOA52Qxtus1IjUgs5hrpfVBUPszmG2y32cdlJlbhTRR3UpJmzeuNErqfEscSQZHLlOtA3NlqLXJTBv07iT0WNDDtAkPX1x8DThNy770XYIjo+TROKdGNKOrek+bhnHyThH7PvBR4+0cuT DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5886.5afb063c.k1805; bh=+Ui+viawavdG50xOv0NRF9hKnA/sm+T4NlBzgDDF9Lk=; b=Kb9ZuRLurOLwLywnbcK+o6Qcrtt2d2O70iS10XLRTefAVDD0X9OYxRQxAqlbs6s/ImHZj6b1ckEc5Sh215FVzpIBhAwOWxEu+9SX/nE0LisCfa5dYZefGZ0IUsZTfi3dPy9JhQc9g1M/ChW98YXZ8ut5j6a4BYQqKR0ELDDOQ/vOiJh/oWytl0VVINwVNH+Pk9EzNZMOdfNtu1pf+b2+aOt8SwDPv8zs1wBSrL/RHeWPrGYOyiqIEI4z4YRtwmBL Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 15 May 2018 16:09:31 -0000 Received: by ary.qy (Postfix, from userid 501) id D65F52696155; Tue, 15 May 2018 12:09:31 -0400 (EDT) Date: 15 May 2018 12:09:31 -0400 Message-Id: <20180515160931.D65F52696155@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: gtaylor@tnetconsulting.net In-Reply-To: <66d513ca-f33d-748b-e394-bceb6e1da525@spamtrap.tnetconsulting.net> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Too bad that the EFAIL victims never heard of DKIM/DMARC 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, 15 May 2018 16:09:35 -0000 In article <66d513ca-f33d-748b-e394-bceb6e1da525@spamtrap.tnetconsulting.net> you write: >-=-=-=-=-=- > >On 05/15/2018 08:15 AM, Kurt Andersen wrote: >> Manipulating MIME structures in email messages to expose the encrypted >> content: https://efail.de/ > >DKIM will not help protect against #Efail. > >Efail works by copying ciphertext into a new message and arranging for >the client to decrypt it. Said new message is devoid of any association >with DKIM. I suppose, for the 10 seconds from the time the message is created until the attacker's MTA signs it on the way out. The bad guy can put a return address he controls on the malicious message and make the whole thing DMARC compliant. R's, John From nobody Tue May 15 09:33:12 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD51512E852 for ; Tue, 15 May 2018 09:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=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 hodUwBVjCw1S for ; Tue, 15 May 2018 09:33:05 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D0ED126BF7 for ; Tue, 15 May 2018 09:33:05 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id 70-v6so3215641ity.2 for ; Tue, 15 May 2018 09:33:05 -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=VPu9K6AxXoXCYvMWnB5TnahtyMSPnZxRaXmjNzHJ75k=; b=gvqGxQ3NhMDYtALNvNQ79MIp1KvsdGwcOK7gHWZqmHc+kwvWj8OMpeLFaViNs8uGOg kwMeILyThjUW9BoB5QVwXU8F/y9VP2gSssQ2GfbdfbFsY5DiWZ7LCfsh1rFDl85JnrA3 No1RRGVZfCy03c+X6eRSgyi9h2WDQB+SkRyuIbQm0Wi3vMsIH6wfgW3MG0J0cZBiGdPb UWGp1/97DImiXJ7RKzvnKYserWDvfrJprU3hv+J9IbFMQ22CxBKEu4+UJW/btpFtzFZS nltUWiafjZOk+rSqhmzFLsWiV0BrKAphGxLZuuG2eKl8Zcr5iCICyDMSBKscUThLN3S5 IlHg== 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=VPu9K6AxXoXCYvMWnB5TnahtyMSPnZxRaXmjNzHJ75k=; b=hrWWo1UtEwC5egrvWebKCRHhioUooK0KV8LmrB1rE5wG53Nao46QJIVPQFU94rU7vR crNN99zzLYDq8TntKmfGHS0sfRBnta9QIknPUyzp9qQ1kX34D1fD4p9RQME/i2Pcyy70 kkotTWKO9QO/+NsYS+qgyVCxsc9jtOw1QC9R0KZsBOl+kb2FQ5UB7nd8pHI37b28Gt6K 76bf8EGoEI0D/xXxTkLmWkYiri33RtK7LDmOd8eA8T36q9G/AvzMGvVLC1vWpP7uSbJe BbFZlgPx2MCHG/j5xQA9Ds0cfH1kwoyeOjomD2C9KsTTfLgqh240JcV6FSKGezK+2uzO 8bqg== X-Gm-Message-State: ALKqPwfRggJANtWj+lgvHo5H+XANOgsKpN5PZjk1ETr7Q1QfxT6Uwe8b 7/MAx4HiU4NmikoAMp+sRUjosBeVE96CBiSPl+6QGQ80 X-Google-Smtp-Source: AB8JxZrvGDG2kDPd1zDeIdrd/A7k3THEQRfnAFAn7w2d1jJX/zF64+8z/D0KwDqAJ7XVvJkKl+RC5q1ziua6Edqb6Qc= X-Received: by 2002:a24:5091:: with SMTP id m139-v6mr14876406itb.50.1526401984504; Tue, 15 May 2018 09:33:04 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:241a:0:0:0:0:0 with HTTP; Tue, 15 May 2018 09:33:04 -0700 (PDT) In-Reply-To: <20180515160931.D65F52696155@ary.qy> References: <66d513ca-f33d-748b-e394-bceb6e1da525@spamtrap.tnetconsulting.net> <20180515160931.D65F52696155@ary.qy> From: Paul Rock Date: Tue, 15 May 2018 12:33:04 -0400 Message-ID: To: John Levine Cc: dmarc , Grant Taylor Content-Type: multipart/alternative; boundary="000000000000126da9056c4128e4" Archived-At: Subject: Re: [dmarc-ietf] Too bad that the EFAIL victims never heard of DKIM/DMARC 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, 15 May 2018 16:33:11 -0000 --000000000000126da9056c4128e4 Content-Type: text/plain; charset="UTF-8" If someone tries some sort of man in the middle inline injection attack to pull this off, sure, I can see DKIM catching that. But the really really nasty bit is the assumption is that you (the target) are running an email client that automatically decrypts any inbound message and render's the HTML for display irregardless of the message source. I (the bad guy) grab an original encrypted message bound for you, (because I see it transit the network, or get access to your message store, or many other reasons) pull out the message body with the cyphertext, create a new multi-part (assuming we're talking about the direct attack) and send it to you as mailfrom: badguy@badplacehere.xyz, dkim-domain: badplacehere.xyz, from: "PERSON YOU KNOW, FOR REALZ" . You're tapping next next next in your email client, the client loads my message, sends me the decrypted text, and you scratch your head wondering why you got two copies of the message. Or even better, I setup my first body to just be something like innocent like "Hey, have any updates?" and then change the font size to zero, or text color to white or something like that... so you wouldn't even see the original message rendered. On Tue, May 15, 2018 at 12:09 PM, John Levine wrote: > In article <66d513ca-f33d-748b-e394-bceb6e1da525@spamtrap. > tnetconsulting.net> you write: > >-=-=-=-=-=- > > > >On 05/15/2018 08:15 AM, Kurt Andersen wrote: > >> Manipulating MIME structures in email messages to expose the encrypted > >> content: https://efail.de/ > > > >DKIM will not help protect against #Efail. > > > >Efail works by copying ciphertext into a new message and arranging for > >the client to decrypt it. Said new message is devoid of any association > >with DKIM. > > I suppose, for the 10 seconds from the time the message is created > until the attacker's MTA signs it on the way out. The bad guy can put > a return address he controls on the malicious message and make the > whole thing DMARC compliant. > > R's, > John > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- PAUL ROCK *Sr Software Dev Engineer* | AOL Mail P: 703-265-5734 | C: 703-980-8380 AIM: paulsrock 22070 Broderick Dr.| Dulles, VA | 20166-9305 --000000000000126da9056c4128e4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If someone tries some sort of man in the middle inline inj= ection attack to pull this off, sure, I can see DKIM catching that. But the= really really nasty bit is the assumption is that you (the target) are run= ning an email client that automatically decrypts any inbound message and re= nder's the HTML for display irregardless of the message source. I (the = bad guy) grab an original encrypted message bound for you, (because I see i= t transit the network, or get access to your message store, or many other r= easons) pull out the message body with the cyphertext, create a new multi-p= art (assuming we're talking about the direct attack) and send it to you= as mailfrom: badguy@badplaceher= e.xyz, dkim-domain: badplacehere.xy= z, from: "PERSON YOU KNOW, FOR REALZ" <badguy@badplacehere.xyz>. You're tapping= next next next in your email client, the client loads my message, sends me= the decrypted text, and you scratch your head wondering why you got two co= pies of the message. Or even better, I setup my first body to just be somet= hing like innocent like "Hey, have any updates?" and then change = the font size to zero, or text color to white or something like that... so = you wouldn't even see the original message rendered.=C2=A0

On Tue, May 15, 2018 at = 12:09 PM, John Levine <johnl@taugh.com> wrote:
In article <66d513ca-f33d-748b-e394-bce= b6e1da525@spamtrap.tnetconsulting.net> you write:
>-=3D-=3D-=3D-=3D-=3D-
>
>On 05/15/2018 08:15 AM, Kurt Andersen wrote:
>> Manipulating MIME structures in email messages to expose the encry= pted
>> content: https://efail.de/
>
>DKIM will not help protect against #Efail.
>
>Efail works by copying ciphertext into a new message and arranging for =
>the client to decrypt it.=C2=A0 Said new message is devoid of any assoc= iation
>with DKIM.

I suppose, for the 10 seconds from the time the message is created until the attacker's MTA signs it on the way out.=C2=A0 The bad guy can= put
a return address he controls on the malicious message and make the
whole thing DMARC compliant.

R's,
John

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



--
=
PAUL ROCK
Sr Software Dev Engineer=C2= =A0| AOL Mail
P: 703-265-= 5734 | C: 703-980-8380
AIM: paulsrock
<= span style=3D"font-size:14px">22070 Broderick Dr.| Dulles, VA | 2= 0166-9305
--000000000000126da9056c4128e4-- From nobody Tue May 15 09:37:19 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD7012DA6E for ; Tue, 15 May 2018 09:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.334 X-Spam-Level: * X-Spam-Status: No, score=1.334 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, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tnetconsulting.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 V08MbXNq1YVx for ; Tue, 15 May 2018 09:37:16 -0700 (PDT) Received: from tncsrv06.tnetconsulting.net (tncsrv06.tnetconsulting.net [IPv6:2600:3c00::f03c:91ff:fe26:8849]) (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 C7B9612DA6D for ; Tue, 15 May 2018 09:37:16 -0700 (PDT) Received: from REDACTED ([IPv6:2620:0:102a:11:fe50:e322:5780:92c6]) (authenticated bits=0) by tncsrv06.tnetconsulting.net (8.15.2/8.15.2/Debian-3) with ESMTPSA id w4FGbFQH026820 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 15 May 2018 11:37:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tnetconsulting.net; s=2015; t=1526402236; bh=m9ernnlCFvfZ9yElXn5AsGKTi9S8RQKIr+yhUEMUS8U=; h=Subject:To:References:From:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type:Cc:Content-Disposition: Content-Language:Content-Transfer-Encoding:Content-Type:Date:From: In-Reply-To:Message-ID:MIME-Version:References:Reply-To: Resent-Date:Resent-From:Resent-To:Resent-Cc:Sender:Subject:To: User-Agent; b=d2HKT3Jps7qFlg8Z9fhLAud9mXBywuFG0QOXHmUM/NrUbOYMPuBaytoyNvdP4ipaj ZgFikbwT3f5CidBQxlgzbEW1dOEAJsyUZW2kBYaVPF15EMgvsmi2LcUXpCmZ+yUETp YVpGdn1KRhVAcatd/ZsYXrNv2crf1+Lv3ATAdITQ= To: dmarc@ietf.org References: <20180515160931.D65F52696155@ary.qy> From: Grant Taylor Organization: TNet Consulting Message-ID: <621360f7-c20b-277e-c840-e69b380f6426@spamtrap.tnetconsulting.net> Date: Tue, 15 May 2018 10:37:14 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180515160931.D65F52696155@ary.qy> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040103090401070408010106" Archived-At: Subject: Re: [dmarc-ietf] Too bad that the EFAIL victims never heard of DKIM/DMARC 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, 15 May 2018 16:37:18 -0000 This is a cryptographically signed message in MIME format. --------------ms040103090401070408010106 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 05/15/2018 10:09 AM, John Levine wrote: > I suppose, for the 10 seconds from the time the message is created unti= l=20 > the attacker's MTA signs it on the way out. The bad guy can put a retu= rn=20 > address he controls on the malicious message and make the whole thing=20 > DMARC compliant. There is a much larger attack window than that. If an attacker gets a copy of an encrypted message, any where at any=20 time, they can craft a new completely unrelated message that includes=20 the ciphertext and coerce the receiving MUA to decrypt it and exfiltrate = the cleartext. This is not a timed / coordinated attack. An attacker could literally extract something form an archive years=20 later and (potentially) get you to decrypt and exfiltrate it. I say potentially because there is a dependency on the recipient's MUA=20 still having the ability to decrypt old encrypted messages. I.e. cert=20 rotation. --=20 Grant. . . . unix || die --------------ms040103090401070408010106 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CxcwggUpMIIEEaADAgECAhAIzwdZriPvq7FXSbc0jGReMA0GCSqGSIb3DQEBCwUAMIGXMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNzExMTcwMDAw MDBaFw0xODExMTcyMzU5NTlaMCsxKTAnBgkqhkiG9w0BCQEWGmd0YXlsb3JAdG5ldGNvbnN1 bHRpbmcubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvhfMhFM6CDAWL4Mg xrKLLbzTCILpI7uBzgG/HFXxV92MX4fba+pAotqOV8of7uF4YykVw94lCsOmFeVkb8VNSn6Q KSFbfnjXmYgU7XRtFHioTZihIynEXXI1LPMhnDXV9jCEzVvrlBx/6mSPdQcWhG1oMAlGd62w uu/CRE5U70LngVVat0wDJhdzrHxZabQlHhAPAvwMex8ObGDAkuieUCn5pQj2xqVKMB65vdcE ZydA8d8X8mvqHHOrEOg5xIwpca7E4JeUMxzYrdp3kVS7V+wXUui1nPwMb6o8WUe72FnL27BY mGqmtUGUc/ajGDUMS4xvabJ0M4Qc/NVGf56qDwIDAQABo4IB2jCCAdYwHwYDVR0jBBgwFoAU gq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFD8vJWpDFBkhAbiZGgx0EIUgH1EoMA4G A1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1odHRwczov L3NlY3VyZS5jb21vZG8ubmV0L0NQUzBaBgNVHR8EUzBRME+gTaBLhklodHRwOi8vY3JsLmNv bW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWls Q0EuY3JsMIGLBggrBgEFBQcBAQR/MH0wVQYIKwYBBQUHMAKGSWh0dHA6Ly9jcnQuY29tb2Rv Y2EuY29tL0NPTU9ET1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAlBgNVHREEHjAcgRpn dGF5bG9yQHRuZXRjb25zdWx0aW5nLm5ldDANBgkqhkiG9w0BAQsFAAOCAQEArDRhn6+otAvz JNgWiGsEeKawiBwqIlR8NSoiOpNYfpmZWS7A+X2mn/47nUT1KypbS3Mf8j8N1rf/FU53p0So WBsnqPAYajAaLjXnGoOEs8pOW0nK/vFYGJHdh8RXvxpPBOd7HUQCqsc4MGJUgasfrWdwqfAZ C1C0G7rNxY5Uvj8RFBPb7d+RfOaegUBMc5FDiXB3Xs43lUEWoWiMi6R3Y5PlQyrvLJB39cLw iLWlOom79addldgAaWZsxnwUDgQgth5ARr1Jw+nfNIimmauAtxDJMgaV17B4ODeuHI1jlPoG HS4+u/qVAwSYq4vtaCN1PSPHwqrrnERAj40c6yPyvzCCBeYwggPOoAMCAQICEGqb4Tg7/ytr nwHV2binUlYwDQYJKoZIhvcNAQEMBQAwgYUxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVh dGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMSswKQYDVQQDEyJDT01PRE8gUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4X DTEzMDExMDAwMDAwMFoXDTI4MDEwOTIzNTk1OVowgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQI ExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA vrOeV6wodnVAFsc4A5jTxhh2IVDzJXkLTLWg0X06WD6cpzEup/Y0dtmEatrQPTRI5Or1u6zf +bGBSyD9aH95dDSmeny1nxdlYCeXIoymMv6pQHJGNcIDpFDIMypVpVSRsivlJTRENf+RKwrB 6vcfWlP8dSsE3Rfywq09N0ZfxcBa39V0wsGtkGWC+eQKiz4pBZYKjrc5NOpG9qrxpZxyb4o4 yNNwTqzaaPpGRqXB7IMjtf7tTmU2jqPMLxFNe1VXj9XB1rHvbRikw8lBoNoSWY66nJN/VCJv 5ym6Q0mdCbDKCMPybTjoNCQuelc0IAaO4nLUXk0BOSxSxt8kCvsUtQIDAQABo4IBPDCCATgw HwYDVR0jBBgwFoAUu69+Aj36pvE8hI6t7jiY7NkyMtQwHQYDVR0OBBYEFIKvbIz4xf6WYXzo Hz0rcUhexIvAMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQK MAgwBgYEVR0gADBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9D T01PRE9SU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDBxBggrBgEFBQcBAQRlMGMwOwYI KwYBBQUHMAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1JTQUFkZFRydXN0Q0Eu Y3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wDQYJKoZIhvcNAQEM BQADggIBAHhcsoEoNE887l9Wzp+XVuyPomsX9vP2SQgG1NgvNc3fQP7TcePo7EIMERoh42aw GGsma65u/ITse2hKZHzT0CBxhuhb6txM1n/y78e/4ZOs0j8CGpfb+SJA3GaBQ+394k+z3ZBy WPQedXLL1OdK8aRINTsjk/H5Ns77zwbjOKkDamxlpZ4TKSDMKVmU/PUWNMKSTvtlenlxBhh7 ETrN543j/Q6qqgCWgWuMAXijnRglp9fyadqGOncjZjaaSOGTTFB+E2pvOUtY+hPebuPtTbq7 vODqzCM6ryEhNhzf+enm0zlpXK7q332nXttNtjv7VFNYG+I31gnMrwfHM5tdhYF/8v5UY5g2 xANPECTQdu9vWPoqNSGDt87b3gXb1AiGGaI06vzgkejL580ul+9hz9D0S0U4jkhJiA7EuTec P/CFtR72uYRBcunwwH3fciPjviDDAI9SnC/2aPY8ydehzuZutLbZdRJ5PDEJM/1tyZR2niOY ihZ+FCbtf3D9mB12D4ln9icgc7CwaxpNSCPt8i/GqK2HsOgkL3VYnwtx7cJUmpvVdZ4ognzg Xtgtdk3ShrtOS1iAN2ZBXFiRmjVzmehoMof06r1xub+85hFQzVxZx5/bRaTKTlL8YXLI8nAb R9HWdFqzcOoB/hxfEyIQpx9/s81rgzdEZOofSlZHynoSMYIENTCCBDECAQEwgawwgZcxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAIzwdZriPvq7FXSbc0 jGReMA0GCWCGSAFlAwQCAQUAoIICWTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xODA1MTUxNjM3MTRaMC8GCSqGSIb3DQEJBDEiBCBr1SXupyTEF8AwJ2NA KoWEMNFtvUs8s5uhI5Lmxa16yTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglg hkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG BSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG9BgkrBgEEAYI3EAQxga8wgawwgZcxCzAJBgNVBAYT AkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAIzwdZriPvq7FXSbc0jGReMIG/ BgsqhkiG9w0BCRACCzGBr6CBrDCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0 ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0ECEAjPB1muI++rsVdJtzSMZF4wDQYJKoZIhvcNAQEBBQAEggEAcSPXhhgg TVR72sS2qTNq0vtHyi7G7Ytf2cADkd4qOo9Xu59zWuhxOqDCo25+pswuXWHpLz1+9jCgXoB0 NMtggjyPuX5ggZN010LDWlI+0wGYXWh9hID8IYPAC7fx92svGGrdOWC837NrSXC4WhQCGyZP EtIRVrO4WfDk/uVE/GyFCAR51m6UFcNMSBkuqGMmVJnuGlgpvMaITDapesRwPaVmtNHwUioI otZdfFQxJnm5s6vFfuj35RXfL/9lnDuNlH8mCUW54gza7XVUaR475QPFdqQlEPJo26Fvjhs8 MiXrzNQyBpD9JEf0orlYS999n5aaKOr05qUmEQQTVgnYvwAAAAAAAA== --------------ms040103090401070408010106-- From nobody Tue May 15 09:46:55 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6606D126C25 for ; Tue, 15 May 2018 09:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 8NSOpJKm4aBo for ; Tue, 15 May 2018 09:46:51 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::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 6D33F1201F2 for ; Tue, 15 May 2018 09:46:51 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id f6-v6so2197592wmc.4 for ; Tue, 15 May 2018 09:46:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=54OWb1hVfkBfrcDyyjbxv9yVmOCTgChrUA1jGhQEoKk=; b=fxm4nFh40PRLqsjpJ2scq+/yo0p+JgVLqzrqBOzOvqfUbh1/+b4pRXzdEeYDQcWLt4 jpV7nGmI8FH6ZpJeG5TqfeaWl8fEhPcmG3C5nFJ24BDtOWQ14hqwgkyObOWxDlokiDVG BobxdANgxf0koDVEO5E/Is9orX5MP1F5qhf/I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=54OWb1hVfkBfrcDyyjbxv9yVmOCTgChrUA1jGhQEoKk=; b=SimpiONgbnS3kKzsXgy4UUp9L2XLbyeIYUl2ICwhgrAoWl9jR9fHqhbv6Xwzo0mYdW 2bDbifZXQAoMHrC/V3mxz0OapxSb8E+WTaGOTUvZvq+bF707AVnaUV3U2UxRA/zKLzgA x8viSvTwLx9fedt+EIQgDfSezI+sNJftzyQofWOLr3HdC8foXMdRRdBZ7hKGmRd7qG/G b5Ph23XVnTRbtZJov6eoy03SPVWC8QzDIc0lQUi/sSxjn2mwFlC3dk60ohZOeoJnCVuO kJxpjLcSFvHBlp2Zr4jvnERWCLCZoxNTq1gAXGjqIMHREAHLf7DvmwSoKGSPNTZUK7au R3Xg== X-Gm-Message-State: ALKqPweyQEG6gvMK3tWgmR0w0tAyUp87VaRcdcQN69jTiKkzZIveDI2l +5rj/PQ/yiLV4Mfz17/Ysw/wfj9HCUKNBrJNguUACFpg X-Google-Smtp-Source: AB8JxZpadb/qf6ArydBBfWAfARNxzY0edieyTZMyhGUS6DXEL1oXEGiTYz0au6JZ/cRSg6idCOMmKILo/qy6okmMBpY= X-Received: by 2002:a50:9ae1:: with SMTP id p88-v6mr18874438edb.20.1526402809892; Tue, 15 May 2018 09:46:49 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.80.142.201 with HTTP; Tue, 15 May 2018 09:46:49 -0700 (PDT) In-Reply-To: <621360f7-c20b-277e-c840-e69b380f6426@spamtrap.tnetconsulting.net> References: <20180515160931.D65F52696155@ary.qy> <621360f7-c20b-277e-c840-e69b380f6426@spamtrap.tnetconsulting.net> From: "Kurt Andersen (b)" Date: Tue, 15 May 2018 09:46:49 -0700 X-Google-Sender-Auth: sLyY0G-EVLuCLgxGW6RmUeh-fXI Message-ID: To: Grant Taylor Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000044a1a7056c4159d7" Archived-At: Subject: Re: [dmarc-ietf] Too bad that the EFAIL victims never heard of DKIM/DMARC 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, 15 May 2018 16:46:53 -0000 --00000000000044a1a7056c4159d7 Content-Type: text/plain; charset="UTF-8" On Tue, May 15, 2018 at 9:37 AM, Grant Taylor < gtaylor=40tnetconsulting.net@dmarc.ietf.org> wrote: > On 05/15/2018 10:09 AM, John Levine wrote: > >> I suppose, for the 10 seconds from the time the message is created until >> the attacker's MTA signs it on the way out. The bad guy can put a return >> address he controls on the malicious message and make the whole thing DMARC >> compliant. >> > > There is a much larger attack window than that. > > If an attacker gets a copy of an encrypted message, any where at any time, > they can craft a new completely unrelated message that includes the > ciphertext and coerce the receiving MUA to decrypt it and exfiltrate the > cleartext. > People who run their GUI MUA to auto-decrypt and display undefanged HTML probably also run that client as root so the exploit is really quite a lot more risky than even the hype has made out. --Kurt --00000000000044a1a7056c4159d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, May 15, 2018 at 9:37 AM, Grant Taylor <gta= ylor=3D40tnetconsulting.net@dmarc.ietf.org> wrote:
On 05/15/2018 10:09 AM, John Levin= e wrote:
I suppose, for the 10 seconds from the time the message is created until th= e attacker's MTA signs it on the way out.=C2=A0 The bad guy can put a r= eturn address he controls on the malicious message and make the whole thing= DMARC compliant.

 There is a much larger attack window than that.

If an attacker gets a copy of an encrypted message, any where at any time, = they can craft a new completely unrelated message that includes the ciphert= ext and coerce the receiving MUA to decrypt it and exfiltrate the cleartext= .

People who run their GUI MUA to auto-decry= pt and display undefanged HTML probably also run that client as root so the= exploit is really quite a lot more risky than even the hype has made out.<= /div>

--Kurt=C2=A0
--00000000000044a1a7056c4159d7-- From nobody Tue May 15 10:02:25 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C0B126CC4 for ; Tue, 15 May 2018 10:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.734 X-Spam-Level: ** X-Spam-Status: No, score=2.734 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tnetconsulting.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 cz4Cy3fsNrnp for ; Tue, 15 May 2018 10:02:22 -0700 (PDT) Received: from tncsrv06.tnetconsulting.net (tncsrv06.tnetconsulting.net [IPv6:2600:3c00::f03c:91ff:fe26:8849]) (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 3A7FE1243F3 for ; Tue, 15 May 2018 10:02:22 -0700 (PDT) Received: from REDACTED ([IPv6:2620:0:102a:11:fe50:e322:5780:92c6]) (authenticated bits=0) by tncsrv06.tnetconsulting.net (8.15.2/8.15.2/Debian-3) with ESMTPSA id w4FH2Kah027336 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 15 May 2018 12:02:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tnetconsulting.net; s=2015; t=1526403741; bh=GqPUNkUtaYO4UXwNOnTxWBLdyIklu7C7FgZFzifsqF0=; h=Subject:To:References:From:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type:Cc:Content-Disposition: Content-Language:Content-Transfer-Encoding:Content-Type:Date:From: In-Reply-To:Message-ID:MIME-Version:References:Reply-To: Resent-Date:Resent-From:Resent-To:Resent-Cc:Sender:Subject:To: User-Agent; b=RMy9yReG4VB33uukTBXrECAQt1njg9b+Ccwas6L4zzv001KV4Q0TCq92z3G7OwY7d jdrQAWLeD8ku1MJ91W2+PmyOrUMzfB0Rwan5InYyPzEyyMyYlWneGo6dKqUyVxzOxr FER/rKyWKPNwrtoal5BH17p9hhpVZm+qq6sqhptg= To: dmarc@ietf.org References: <66d513ca-f33d-748b-e394-bceb6e1da525@spamtrap.tnetconsulting.net> <20180515160931.D65F52696155@ary.qy> From: Grant Taylor Organization: TNet Consulting Message-ID: <8674ccf9-a563-c000-2009-f869ec0790bf@spamtrap.tnetconsulting.net> Date: Tue, 15 May 2018 11:02:20 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060903060808000506030109" Archived-At: Subject: Re: [dmarc-ietf] Too bad that the EFAIL victims never heard of DKIM/DMARC 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, 15 May 2018 17:02:23 -0000 This is a cryptographically signed message in MIME format. --------------ms060903060808000506030109 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 05/15/2018 10:33 AM, Paul Rock wrote: > You're tapping next next next in your email client, the client loads my= =20 > message, sends me the decrypted text, and you scratch your head=20 > wondering why you got two copies of the message. The recipient shouldn't see the second copy of the decrypted message. I = say this because the decrypted copy (as in text) is used as part of a=20 URL source, and not actually displayed to the recipient. > Or even better, I setup my first body to just be something like innocen= t=20 > like "Hey, have any updates?" and then change the font size to zero,=20 > or text color to white or something like that... so you wouldn't even=20 > see the original message rendered. You could put a generic place holder "Hay, have any updates?" in the=20 message, but you don't need to try to hide anything because it's part of = a src=3D"=E2=80=A6" that is not rendered. What would be funny is for the "Hay, have any updates?" to be the image=20 returned from the aforementioned tag. }:-) --=20 Grant. . . . unix || die --------------ms060903060808000506030109 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CxcwggUpMIIEEaADAgECAhAIzwdZriPvq7FXSbc0jGReMA0GCSqGSIb3DQEBCwUAMIGXMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNzExMTcwMDAw MDBaFw0xODExMTcyMzU5NTlaMCsxKTAnBgkqhkiG9w0BCQEWGmd0YXlsb3JAdG5ldGNvbnN1 bHRpbmcubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvhfMhFM6CDAWL4Mg xrKLLbzTCILpI7uBzgG/HFXxV92MX4fba+pAotqOV8of7uF4YykVw94lCsOmFeVkb8VNSn6Q KSFbfnjXmYgU7XRtFHioTZihIynEXXI1LPMhnDXV9jCEzVvrlBx/6mSPdQcWhG1oMAlGd62w uu/CRE5U70LngVVat0wDJhdzrHxZabQlHhAPAvwMex8ObGDAkuieUCn5pQj2xqVKMB65vdcE ZydA8d8X8mvqHHOrEOg5xIwpca7E4JeUMxzYrdp3kVS7V+wXUui1nPwMb6o8WUe72FnL27BY mGqmtUGUc/ajGDUMS4xvabJ0M4Qc/NVGf56qDwIDAQABo4IB2jCCAdYwHwYDVR0jBBgwFoAU gq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFD8vJWpDFBkhAbiZGgx0EIUgH1EoMA4G A1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1odHRwczov L3NlY3VyZS5jb21vZG8ubmV0L0NQUzBaBgNVHR8EUzBRME+gTaBLhklodHRwOi8vY3JsLmNv bW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWls Q0EuY3JsMIGLBggrBgEFBQcBAQR/MH0wVQYIKwYBBQUHMAKGSWh0dHA6Ly9jcnQuY29tb2Rv Y2EuY29tL0NPTU9ET1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAlBgNVHREEHjAcgRpn dGF5bG9yQHRuZXRjb25zdWx0aW5nLm5ldDANBgkqhkiG9w0BAQsFAAOCAQEArDRhn6+otAvz JNgWiGsEeKawiBwqIlR8NSoiOpNYfpmZWS7A+X2mn/47nUT1KypbS3Mf8j8N1rf/FU53p0So WBsnqPAYajAaLjXnGoOEs8pOW0nK/vFYGJHdh8RXvxpPBOd7HUQCqsc4MGJUgasfrWdwqfAZ C1C0G7rNxY5Uvj8RFBPb7d+RfOaegUBMc5FDiXB3Xs43lUEWoWiMi6R3Y5PlQyrvLJB39cLw iLWlOom79addldgAaWZsxnwUDgQgth5ARr1Jw+nfNIimmauAtxDJMgaV17B4ODeuHI1jlPoG HS4+u/qVAwSYq4vtaCN1PSPHwqrrnERAj40c6yPyvzCCBeYwggPOoAMCAQICEGqb4Tg7/ytr nwHV2binUlYwDQYJKoZIhvcNAQEMBQAwgYUxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVh dGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMSswKQYDVQQDEyJDT01PRE8gUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4X DTEzMDExMDAwMDAwMFoXDTI4MDEwOTIzNTk1OVowgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQI ExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA vrOeV6wodnVAFsc4A5jTxhh2IVDzJXkLTLWg0X06WD6cpzEup/Y0dtmEatrQPTRI5Or1u6zf +bGBSyD9aH95dDSmeny1nxdlYCeXIoymMv6pQHJGNcIDpFDIMypVpVSRsivlJTRENf+RKwrB 6vcfWlP8dSsE3Rfywq09N0ZfxcBa39V0wsGtkGWC+eQKiz4pBZYKjrc5NOpG9qrxpZxyb4o4 yNNwTqzaaPpGRqXB7IMjtf7tTmU2jqPMLxFNe1VXj9XB1rHvbRikw8lBoNoSWY66nJN/VCJv 5ym6Q0mdCbDKCMPybTjoNCQuelc0IAaO4nLUXk0BOSxSxt8kCvsUtQIDAQABo4IBPDCCATgw HwYDVR0jBBgwFoAUu69+Aj36pvE8hI6t7jiY7NkyMtQwHQYDVR0OBBYEFIKvbIz4xf6WYXzo Hz0rcUhexIvAMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQK MAgwBgYEVR0gADBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9D T01PRE9SU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDBxBggrBgEFBQcBAQRlMGMwOwYI KwYBBQUHMAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1JTQUFkZFRydXN0Q0Eu Y3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wDQYJKoZIhvcNAQEM BQADggIBAHhcsoEoNE887l9Wzp+XVuyPomsX9vP2SQgG1NgvNc3fQP7TcePo7EIMERoh42aw GGsma65u/ITse2hKZHzT0CBxhuhb6txM1n/y78e/4ZOs0j8CGpfb+SJA3GaBQ+394k+z3ZBy WPQedXLL1OdK8aRINTsjk/H5Ns77zwbjOKkDamxlpZ4TKSDMKVmU/PUWNMKSTvtlenlxBhh7 ETrN543j/Q6qqgCWgWuMAXijnRglp9fyadqGOncjZjaaSOGTTFB+E2pvOUtY+hPebuPtTbq7 vODqzCM6ryEhNhzf+enm0zlpXK7q332nXttNtjv7VFNYG+I31gnMrwfHM5tdhYF/8v5UY5g2 xANPECTQdu9vWPoqNSGDt87b3gXb1AiGGaI06vzgkejL580ul+9hz9D0S0U4jkhJiA7EuTec P/CFtR72uYRBcunwwH3fciPjviDDAI9SnC/2aPY8ydehzuZutLbZdRJ5PDEJM/1tyZR2niOY ihZ+FCbtf3D9mB12D4ln9icgc7CwaxpNSCPt8i/GqK2HsOgkL3VYnwtx7cJUmpvVdZ4ognzg Xtgtdk3ShrtOS1iAN2ZBXFiRmjVzmehoMof06r1xub+85hFQzVxZx5/bRaTKTlL8YXLI8nAb R9HWdFqzcOoB/hxfEyIQpx9/s81rgzdEZOofSlZHynoSMYIENTCCBDECAQEwgawwgZcxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAIzwdZriPvq7FXSbc0 jGReMA0GCWCGSAFlAwQCAQUAoIICWTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xODA1MTUxNzAyMjBaMC8GCSqGSIb3DQEJBDEiBCCEDPGyx62IXtJqoi4h a3vexwMlBohP9vrxyDIyjGt44TBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglg hkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG BSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG9BgkrBgEEAYI3EAQxga8wgawwgZcxCzAJBgNVBAYT AkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAIzwdZriPvq7FXSbc0jGReMIG/ BgsqhkiG9w0BCRACCzGBr6CBrDCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0 ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0ECEAjPB1muI++rsVdJtzSMZF4wDQYJKoZIhvcNAQEBBQAEggEAoKJoR7nG JJd/sPTysv4/RwCfAH4jGW7dM9ru27eD4WUdj39T6Et5WT7XsDhC21G1SJPHzK+VcPU1x5pu YxEV+8oqBFRKgls45JfR7eGfu4K089cfAJevJA2AGcN/ZQJJYzjz40lsRXRB6EvF96QgqUjl tv74mmwolK/wFp5O4azqVVwSxEgnEvc16zkUf36LwiJhAlAWk7+3dyYUfty0YE0lyXwApmZM 8FrsEB2E8tHR68rD5ZD01BhmozsNXO+RCuY82jbpoSztnqrA3L176XUWiBsEyxSLNqtvIOOf oDUr+g0uDXSKGfurZN9jzv1NRTxsnNZ5WD5N/MuVOGw0ZwAAAAAAAA== --------------ms060903060808000506030109-- From nobody Tue May 15 10:05:09 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE9C1126D3F for ; Tue, 15 May 2018 10:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.334 X-Spam-Level: * X-Spam-Status: No, score=1.334 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, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tnetconsulting.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 OX4qfls1fx75 for ; Tue, 15 May 2018 10:05:01 -0700 (PDT) Received: from tncsrv06.tnetconsulting.net (tncsrv06.tnetconsulting.net [IPv6:2600:3c00::f03c:91ff:fe26:8849]) (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 A03B91243F3 for ; Tue, 15 May 2018 10:05:01 -0700 (PDT) Received: from REDACTED ([IPv6:2620:0:102a:11:fe50:e322:5780:92c6]) (authenticated bits=0) by tncsrv06.tnetconsulting.net (8.15.2/8.15.2/Debian-3) with ESMTPSA id w4FH4xmf027493 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 15 May 2018 12:05:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tnetconsulting.net; s=2015; t=1526403901; bh=uvbsGbTfnHdSL0c4DF8Nwf5+gn6Q2o7kdclTuzSLgMk=; h=Subject:To:References:From:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type:Cc:Content-Disposition: Content-Language:Content-Transfer-Encoding:Content-Type:Date:From: In-Reply-To:Message-ID:MIME-Version:References:Reply-To: Resent-Date:Resent-From:Resent-To:Resent-Cc:Sender:Subject:To: User-Agent; b=XNUUYX7m6+IDCqYhAckxt2TSb+cr+RgQ3/bQo1AgAzH6SJyDoaJFJKcTIpC0ou94Y eJpayS1L505q52l2K1F52pK3XdIFrRphcR9qxbXZtNc4Rjl+NtZlwBRMaF0ZjLoiNM OsI49fe9mUIjidIZrD8MdGhoJw3X+DvxbW3bZjOs= To: dmarc@ietf.org References: <20180515160931.D65F52696155@ary.qy> <621360f7-c20b-277e-c840-e69b380f6426@spamtrap.tnetconsulting.net> From: Grant Taylor Organization: TNet Consulting Message-ID: <3ca9ab1f-1f4c-d39b-687d-709ee6e77978@spamtrap.tnetconsulting.net> Date: Tue, 15 May 2018 11:04:59 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070006000902000303060706" Archived-At: Subject: Re: [dmarc-ietf] Too bad that the EFAIL victims never heard of DKIM/DMARC 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, 15 May 2018 17:05:08 -0000 This is a cryptographically signed message in MIME format. --------------ms070006000902000303060706 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 05/15/2018 10:46 AM, Kurt Andersen (b) wrote: > People who run their GUI MUA to auto-decrypt and display undefanged HTM= L=20 > probably also run that client as root so the exploit is really quite a = > lot more risky than even the hype has made out. I doubt that. I'm sure that some of the people that do run their MUA as root /=20 administrator will also auto-decrypt and render HTML. But I'm fairly confident that auto-decrypting and rendering HTML is far=20 more prevalent than running the MUA as root. It's trivial for an end user to get an MUA to do that without requiring=20 administrative privileges at all. Some MUAs, like the iPhone, do this=20 automatically and end users have to go way out of their way to get root=20 level access. IMHO Efail is completely an unprivileged user level target. --=20 Grant. . . . unix || die --------------ms070006000902000303060706 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CxcwggUpMIIEEaADAgECAhAIzwdZriPvq7FXSbc0jGReMA0GCSqGSIb3DQEBCwUAMIGXMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNzExMTcwMDAw MDBaFw0xODExMTcyMzU5NTlaMCsxKTAnBgkqhkiG9w0BCQEWGmd0YXlsb3JAdG5ldGNvbnN1 bHRpbmcubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvhfMhFM6CDAWL4Mg xrKLLbzTCILpI7uBzgG/HFXxV92MX4fba+pAotqOV8of7uF4YykVw94lCsOmFeVkb8VNSn6Q KSFbfnjXmYgU7XRtFHioTZihIynEXXI1LPMhnDXV9jCEzVvrlBx/6mSPdQcWhG1oMAlGd62w uu/CRE5U70LngVVat0wDJhdzrHxZabQlHhAPAvwMex8ObGDAkuieUCn5pQj2xqVKMB65vdcE ZydA8d8X8mvqHHOrEOg5xIwpca7E4JeUMxzYrdp3kVS7V+wXUui1nPwMb6o8WUe72FnL27BY mGqmtUGUc/ajGDUMS4xvabJ0M4Qc/NVGf56qDwIDAQABo4IB2jCCAdYwHwYDVR0jBBgwFoAU gq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFD8vJWpDFBkhAbiZGgx0EIUgH1EoMA4G A1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1odHRwczov L3NlY3VyZS5jb21vZG8ubmV0L0NQUzBaBgNVHR8EUzBRME+gTaBLhklodHRwOi8vY3JsLmNv bW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWls Q0EuY3JsMIGLBggrBgEFBQcBAQR/MH0wVQYIKwYBBQUHMAKGSWh0dHA6Ly9jcnQuY29tb2Rv Y2EuY29tL0NPTU9ET1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAlBgNVHREEHjAcgRpn dGF5bG9yQHRuZXRjb25zdWx0aW5nLm5ldDANBgkqhkiG9w0BAQsFAAOCAQEArDRhn6+otAvz JNgWiGsEeKawiBwqIlR8NSoiOpNYfpmZWS7A+X2mn/47nUT1KypbS3Mf8j8N1rf/FU53p0So WBsnqPAYajAaLjXnGoOEs8pOW0nK/vFYGJHdh8RXvxpPBOd7HUQCqsc4MGJUgasfrWdwqfAZ C1C0G7rNxY5Uvj8RFBPb7d+RfOaegUBMc5FDiXB3Xs43lUEWoWiMi6R3Y5PlQyrvLJB39cLw iLWlOom79addldgAaWZsxnwUDgQgth5ARr1Jw+nfNIimmauAtxDJMgaV17B4ODeuHI1jlPoG HS4+u/qVAwSYq4vtaCN1PSPHwqrrnERAj40c6yPyvzCCBeYwggPOoAMCAQICEGqb4Tg7/ytr nwHV2binUlYwDQYJKoZIhvcNAQEMBQAwgYUxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVh dGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMSswKQYDVQQDEyJDT01PRE8gUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4X DTEzMDExMDAwMDAwMFoXDTI4MDEwOTIzNTk1OVowgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQI ExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA vrOeV6wodnVAFsc4A5jTxhh2IVDzJXkLTLWg0X06WD6cpzEup/Y0dtmEatrQPTRI5Or1u6zf +bGBSyD9aH95dDSmeny1nxdlYCeXIoymMv6pQHJGNcIDpFDIMypVpVSRsivlJTRENf+RKwrB 6vcfWlP8dSsE3Rfywq09N0ZfxcBa39V0wsGtkGWC+eQKiz4pBZYKjrc5NOpG9qrxpZxyb4o4 yNNwTqzaaPpGRqXB7IMjtf7tTmU2jqPMLxFNe1VXj9XB1rHvbRikw8lBoNoSWY66nJN/VCJv 5ym6Q0mdCbDKCMPybTjoNCQuelc0IAaO4nLUXk0BOSxSxt8kCvsUtQIDAQABo4IBPDCCATgw HwYDVR0jBBgwFoAUu69+Aj36pvE8hI6t7jiY7NkyMtQwHQYDVR0OBBYEFIKvbIz4xf6WYXzo Hz0rcUhexIvAMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQK MAgwBgYEVR0gADBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9D T01PRE9SU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDBxBggrBgEFBQcBAQRlMGMwOwYI KwYBBQUHMAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1JTQUFkZFRydXN0Q0Eu Y3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wDQYJKoZIhvcNAQEM BQADggIBAHhcsoEoNE887l9Wzp+XVuyPomsX9vP2SQgG1NgvNc3fQP7TcePo7EIMERoh42aw GGsma65u/ITse2hKZHzT0CBxhuhb6txM1n/y78e/4ZOs0j8CGpfb+SJA3GaBQ+394k+z3ZBy WPQedXLL1OdK8aRINTsjk/H5Ns77zwbjOKkDamxlpZ4TKSDMKVmU/PUWNMKSTvtlenlxBhh7 ETrN543j/Q6qqgCWgWuMAXijnRglp9fyadqGOncjZjaaSOGTTFB+E2pvOUtY+hPebuPtTbq7 vODqzCM6ryEhNhzf+enm0zlpXK7q332nXttNtjv7VFNYG+I31gnMrwfHM5tdhYF/8v5UY5g2 xANPECTQdu9vWPoqNSGDt87b3gXb1AiGGaI06vzgkejL580ul+9hz9D0S0U4jkhJiA7EuTec P/CFtR72uYRBcunwwH3fciPjviDDAI9SnC/2aPY8ydehzuZutLbZdRJ5PDEJM/1tyZR2niOY ihZ+FCbtf3D9mB12D4ln9icgc7CwaxpNSCPt8i/GqK2HsOgkL3VYnwtx7cJUmpvVdZ4ognzg Xtgtdk3ShrtOS1iAN2ZBXFiRmjVzmehoMof06r1xub+85hFQzVxZx5/bRaTKTlL8YXLI8nAb R9HWdFqzcOoB/hxfEyIQpx9/s81rgzdEZOofSlZHynoSMYIENTCCBDECAQEwgawwgZcxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAIzwdZriPvq7FXSbc0 jGReMA0GCWCGSAFlAwQCAQUAoIICWTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xODA1MTUxNzA0NTlaMC8GCSqGSIb3DQEJBDEiBCBGPoRszijZilbv3cV5 e3NcLLw55JqwsEAeCnBiJugO2jBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglg hkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG BSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG9BgkrBgEEAYI3EAQxga8wgawwgZcxCzAJBgNVBAYT AkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAIzwdZriPvq7FXSbc0jGReMIG/ BgsqhkiG9w0BCRACCzGBr6CBrDCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0 ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0ECEAjPB1muI++rsVdJtzSMZF4wDQYJKoZIhvcNAQEBBQAEggEAM/xnxS7j X1shn8FSLlHoVkD6nG407/51CQk6pgdXzfsnxV/bMZZPfHyl5Fl6OhPXR8Zl9rSU3FsGGQ7M ZkEpLzF+o3oeZk1Wx8PPTtVSRtkeintQy1119q8d/G7SWsi5q1/MfDFJhy6uCsyX5381kcad ZvJj6+FZYY0ayGlfPoV70UyzRZtJ37E0hF0JFHFuHmoqk/NytsTJ/eVsPPqyYu9rj+xDHSm7 szJsnrBYFMRQbadYB31OJ8QOJrf2tdgxlv73BVqVlA0d0HBg7QedNOwsON84esO62xnxsAeN fwnj6xiB2hXq2Ct0jVByse+cVv5vJ8CISgD8LYSqHAQZAQAAAAAAAA== --------------ms070006000902000303060706-- From nobody Fri May 18 07:09:59 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7207B12D963 for ; Fri, 18 May 2018 07:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 7Zm3Njv9NIv9 for ; Fri, 18 May 2018 07:09:54 -0700 (PDT) Received: from smtp14.mail.ru (smtp14.mail.ru [94.100.181.95]) (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 7825712D9FE for ; Fri, 18 May 2018 07:09:49 -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=Imie9eZV1pYYhU0KnUob2QGpixg6lgNQ7xW2FMx9T2I=; b=Rs1pfFSLEy9LjdO/hxzLhOts+lYPc1eHoP3MCatmTNgc7zBnbt0L1Ou5Rk6L8FoJy6P7SgSkaRTaMvJgcq/OwowWm1SdXVHyFbTaa4jxQPZ9Llr+TnQdtbddbaB003EVUDthNueRfzSdVzXWhH4VkeQY5SO6DdqKRNn5IP0lPMQ=; Received: by smtp14.mail.ru with esmtpa (envelope-from ) id 1fJg4p-0000pU-Hn; Fri, 18 May 2018 17:09:47 +0300 To: Kurt Andersen , "dmarc@ietf.org" References: From: Vladimir Dubrovin Openpgp: preference=signencrypt Autocrypt: addr=dubrovin@corp.mail.ru; prefer-encrypt=mutual; keydata= xsFNBFkuo0YBEADhYgaiCbZjws9eRBKJAYMIeuo9x6cArdmG5lcDgyVrtIPz/7MGL/HJua0v xKJtfhk77fb2YKcJvIdCf6HMoJfU412Y/5Bjq7eLmXTBsf7KmpQ9Z6auYujrzLCEb6gHC4gp gauesj6+igIyd8YULbbbCieIht7FVEIQv1Hn6F3eIok6wC3UJi2gEUiRbN4p5fw1RI5IB8yJ /4iFTtZi2iKUvSxZt/6eMAGNYm+OrFFGSfCP6l3uD93ZO3M9x8TluMXXrUQM6J190LOUUeh7 jGklgyUxrJXi44pRLFMbirrBcCQwEcY/lpUb1tvq2Ohb9nhBFBWLoJ1Kplxpi9ueXAsNJ7zw K1R15EElpIYQEmXM7t3dvC+zRIwZOiYTEI+cTqi3+fe/89lVQB15R43lrALl3+GEOj2F9/HP eCJtTzn+ie8+p0lSIWhNb2ozRPaKv1vxEGqkA+1wcgF2EOh3melRKGnf5VKJ4ZL5LZi+55nV NV/MiHv6WuA6QEB08qxgkF1vmpy3olQmpxzRHGnLcKClAnkfgn3Gp4Kkf/cKZ/jmgycf3QiZ OX9pJmChkp7florVmb31gXnZwiwa3AM5j063+JE6r0Uwt5R4TZsOx109U9a0ta4eS6fE22+O pEPKddpaOPnCTB/RDcxFbyXWJw8J5FW6EUbNSaBQTIjZn6jUnQARAQABzSlWbGFkaW1pciBE dWJyb3ZpbiA8ZHVicm92aW5AY29ycC5tYWlsLnJ1PsLBfwQTAQgAKQUCWS6jRgIbIwUJCWYB gAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEKxNqiqt3SqHr3kQAInNgkXiRv61Zs4g B2mxrPtTRij+iDF+UOJVA/A5SjHaMWPVbT0PblbwWkxQvaxBDEPN4NRp+5mLkxD6ETmJJFZx gfmB3N9vhqFjHVb9K6AqGc7qlhlGwoIj6x27F07lmNkYHXMqqdt9Nbk+FvjukDU4WMZYFtXu 4c43hclKCg2i+bgZ5rXNJFsLioaY2Z/6Yml4COwvhDSg+IXF8oZtnf0Y8EP9qPeC3DHpL5n1 IgcB5mpzcBdsQchIVVCYCljVf0g5wslfs0tKvyrOsSF1gX8NK6gY3mZb44f5M2yviL/DFCS2 lmZDX2HqCmgyI0GwLTEW9zuZKE0WT6FF2KbWv3QbkwplygCQYlwCeEDOiemIsGiM11ubvDNe Iotvv06IsC5+6VYb63GBqRty+wEOjBNgz8AsHdljGxZjavQRBHa24+lYASMfLUqqoGPPM9wj mgiyOfS9p+VZumNzjk11mHrTe+Y7HujHVCjC74Ue+QHeyuIjk0bxDQSISh+w1jw9v/nyN8wh /tugEC4DO9LhyJPprZcduHQtlIFXEeZbmvapXqLjgMIz1WUB7hGcUMUkZZWqlkGyLhOdFpJL DkTMxqmazRL/jWLHSIRKWx1tmTn0GXLpXitP8ud8P67jY8mI2A04seuFNZLmtQLxP9qIIdrd f7WYPo19e+0b83BiC7rGzsFNBFkuo0YBEADmrX6Ho18GYRk2GJZ3sy4g61oVuwAED+zGSsFt pYGGsOo/3rp9HRRcWR9qQ0osO14oB7swEhWnv4BMpab2WQ2BXM10W6B94yJsRMcZK4VJVSrP o/IEBrXe4roug+iG60wh4Cmi6Ojoi9OCarl+JVZCSclDy6cEv/MQRgwlNV+jvEqxVokdAwTY HrXpYpISnwCGcR6/eA+CHFvLQOkR+oHFqNuJsdx9e+OXP9MA5YLgi1atyHfkhGdDraLLTyGD aAqOaiOt7LdRL5xlaFejlHydkWEXbxSmIro7hHAFmyreslQ63V1vpLa6czylRqQ/us6iOidu rc+zsNAd7dbKVuOW/YEbiTrKwX7xjOa7lxYkOCBc+xa0Jj57FUoNQQdr678olgF5zqKvgZKa qiYSH6WR/wnKVmB8KQItyGZneq2f3Tqkc/S9Z45Olz7uYnN32uJAgn6awezkcK4iGSjQMzzg onP28LuLGoJVX92HWcYNBRW5T0Jqdro3i+XWLKWNsRSe8ifguH87CPfAtIsUJRUDvdR+XKF8 /TeXZfpdeU5tzOnRXPrST8L3Yw3Hpa//JtCmAXo02uer+fZm0e2+rB0cjn2P65fb5sb0jJNy mp1dwUEs+u0xHN3gHVBtPixCqnPVzFBygBtaPZF+6B6fhFLABNokIyii5NHYNS/NqEGTzwAR AQABwsFlBBgBCAAPBQJZLqNGAhsMBQkJZgGAAAoJEKxNqiqt3SqHOMQQAIojVofS2i1fAmML cnqhJVjB7nNZNTYGPGuqaSOk+P3nViihhkA+dhbntDRAipIzIoCOzBYQ69mY0LQAA1cAxC0T tqoDidp96OoGZfp1zWJu2pQrubfY8iR8+fxWPfQnPakVItp4Rexzg5oWsy070ysMhWemqRps DaozbJJU0dPCxIRCO28H20DLYF9LzK0BUQBJUcrGT7pLwyI2UXT8UdKBkyzezh53en+mnV2W a1U/syFstNBv5Y+XTemh882butmbBqGU4V47FK8BeBZdfrbqyz9fJMPQuV8esA3ucRP5gwDY S4z8QiofEfkPZ0V3ldGnpjJyCXdeYzMFgA/+cTmTO0lAA96+zB0Z/gcNwL/Nq1bX6P31mPsC PrBjlOUUCCBgek4D//oUKzoBF2YPQeMsqt7PKboHtTVeE0279vRifbIRF295X4nKVA4sWHpx V/HrSdpNQraWw7Sq4/iTbcqETNY48oWQBSeilGD+ZXKxtdUte8plVPDFoUxQZ6iQp3YqrEgi eNAwkMkiWb5zQ3YKd3JfsTOd1wd9Cc2jKaSE7fj3moAkSxQNZsgiQzMFThK7S/wcESpJfRxH hicIfJtLXgoQZOjH1zePjmdHxidhD65P8cfey++AYYSYWPyRrN5BW1Aam8FDOBpzU8pvNjWL NXdphurqQpFSRlvcRvXY Message-ID: <1a56f5be-5b6d-6c88-df3b-dac2763ef087@corp.mail.ru> Date: Fri, 18 May 2018 17:09:45 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D76EFAEFAC06DE94DFCB2D7A" Content-Language: ru Authentication-Results: smtp14.mail.ru; auth=pass smtp.auth=dubrovin@corp.mail.ru smtp.mailfrom=dubrovin@corp.mail.ru X-Mras: Ok Archived-At: Subject: Re: [dmarc-ietf] Too bad that the EFAIL victims never heard of DKIM/DMARC 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, 18 May 2018 14:09:58 -0000 This is a multi-part message in MIME format. --------------D76EFAEFAC06DE94DFCB2D7A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit EFAIL exploitation requires MitM conditions. Neither DKIM nor DMARC protect against attacker able to perform MitM. 15.05.2018 17:15, Kurt Andersen пишет: > Manipulating MIME structures in email messages to expose the encrypted > content: https://efail.de/ > > --Kurt > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc -- Vladimir Dubrovin @Mail.Ru --------------D76EFAEFAC06DE94DFCB2D7A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

EFAIL exploitation requires MitM conditions. Neither DKIM nor DMARC protect against attacker able to perform MitM.


15.05.2018 17:15, Kurt Andersen пишет:
Manipulating MIME structures in email messages to expose the encrypted content: https://efail.de/

--Kurt


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



-- 
Vladimir Dubrovin
@Mail.Ru
--------------D76EFAEFAC06DE94DFCB2D7A-- From nobody Fri May 18 07:16:42 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72EB012D96A for ; Fri, 18 May 2018 07:16: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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wordtothewise.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZbUaykuKQ2P for ; Fri, 18 May 2018 07:16:39 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [IPv6:2001:470:1:6d::9a]) by ietfa.amsl.com (Postfix) with ESMTP id AD7D412D7F8 for ; Fri, 18 May 2018 07:16:39 -0700 (PDT) Received: from satsuke.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) by mail.wordtothewise.com (Postfix) with ESMTPSA id C9C2423379 for ; Fri, 18 May 2018 07:17:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1526653058; bh=O4Iaoi17r526NIe4SMn9O+HmgLKwR/GUrmHswapYFyI=; h=From:Subject:Date:References:To:In-Reply-To:From; b=gJDSUVVsZO5OzFwh9qZpeZhmBWTyLxPuXmMsvX51VWbOHbJJfRKS3Fxr8Ta8BYbrP wNjpYzMad9LgD8f9Y2ltJ6scVpfYUsiPWdMrapFmsFozFJcPO10GWx5fAyRzhSuPk9 QVo3eAP5uuXnnfxciqm6eEp2otJQRzGBQPAeeD9I= From: Steve Atkins Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 18 May 2018 07:16:38 -0700 References: <1a56f5be-5b6d-6c88-df3b-dac2763ef087@corp.mail.ru> To: "dmarc@ietf.org" In-Reply-To: <1a56f5be-5b6d-6c88-df3b-dac2763ef087@corp.mail.ru> Message-Id: <5E5AFE4B-CB2E-44A3-9ACD-142F6272F0AB@wordtothewise.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dmarc-ietf] Too bad that the EFAIL victims never heard of DKIM/DMARC 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, 18 May 2018 14:16:42 -0000 > On May 18, 2018, at 7:09 AM, Vladimir Dubrovin = wrote: >=20 >=20 > EFAIL exploitation requires MitM conditions. Neither DKIM nor DMARC = protect against attacker able to perform MitM. >=20 It just requires the attacker to have a copy of the encrypted mail. = Passive mitm is one approach to that, but only one of many. Cheers, Steve >=20 > 15.05.2018 17:15, Kurt Andersen =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >> Manipulating MIME structures in email messages to expose the = encrypted content: https://efail.de/ >>=20 >> --Kurt >>=20 >>=20 >> _______________________________________________ >> dmarc mailing list >>=20 >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >=20 > --=20 > Vladimir Dubrovin > @Mail.Ru >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Fri May 18 07:54:32 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E5012D96C for ; Fri, 18 May 2018 07:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 tTA0Rii6nlri for ; Fri, 18 May 2018 07:54:28 -0700 (PDT) Received: from smtp42.i.mail.ru (smtp42.i.mail.ru [94.100.177.102]) (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 4D73C12DA0D for ; Fri, 18 May 2018 07:54:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=corp.mail.ru; s=mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=8jMUhdm4o4lfU0jsrRNw2pRJQyFqyX15W8WSEz+Skc0=; b=i8wcZ85whm4isYoZql444I7lfiXzliMny/QIC+HLUjO78NXKKgJKMCTtPfu/EcqvDRXmEPuRQKdlixy+C/8SM33X432U3tUl0aXi2aCd/w1lG2nCMKMF89Rrg6mlqpa1wqrRcJbT1zGrdg3oDpe5KZaJ1YVO89yGZd0jVvgNml8=; Received: by smtp42.i.mail.ru with esmtpa (envelope-from ) id 1fJgly-0003vW-TU; Fri, 18 May 2018 17:54:23 +0300 To: dmarc@ietf.org, Steve Atkins References: <1a56f5be-5b6d-6c88-df3b-dac2763ef087@corp.mail.ru> <5E5AFE4B-CB2E-44A3-9ACD-142F6272F0AB@wordtothewise.com> From: Vladimir Dubrovin Openpgp: preference=signencrypt Autocrypt: addr=dubrovin@corp.mail.ru; prefer-encrypt=mutual; keydata= xsFNBFkuo0YBEADhYgaiCbZjws9eRBKJAYMIeuo9x6cArdmG5lcDgyVrtIPz/7MGL/HJua0v xKJtfhk77fb2YKcJvIdCf6HMoJfU412Y/5Bjq7eLmXTBsf7KmpQ9Z6auYujrzLCEb6gHC4gp gauesj6+igIyd8YULbbbCieIht7FVEIQv1Hn6F3eIok6wC3UJi2gEUiRbN4p5fw1RI5IB8yJ /4iFTtZi2iKUvSxZt/6eMAGNYm+OrFFGSfCP6l3uD93ZO3M9x8TluMXXrUQM6J190LOUUeh7 jGklgyUxrJXi44pRLFMbirrBcCQwEcY/lpUb1tvq2Ohb9nhBFBWLoJ1Kplxpi9ueXAsNJ7zw K1R15EElpIYQEmXM7t3dvC+zRIwZOiYTEI+cTqi3+fe/89lVQB15R43lrALl3+GEOj2F9/HP eCJtTzn+ie8+p0lSIWhNb2ozRPaKv1vxEGqkA+1wcgF2EOh3melRKGnf5VKJ4ZL5LZi+55nV NV/MiHv6WuA6QEB08qxgkF1vmpy3olQmpxzRHGnLcKClAnkfgn3Gp4Kkf/cKZ/jmgycf3QiZ OX9pJmChkp7florVmb31gXnZwiwa3AM5j063+JE6r0Uwt5R4TZsOx109U9a0ta4eS6fE22+O pEPKddpaOPnCTB/RDcxFbyXWJw8J5FW6EUbNSaBQTIjZn6jUnQARAQABzSlWbGFkaW1pciBE dWJyb3ZpbiA8ZHVicm92aW5AY29ycC5tYWlsLnJ1PsLBfwQTAQgAKQUCWS6jRgIbIwUJCWYB gAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEKxNqiqt3SqHr3kQAInNgkXiRv61Zs4g B2mxrPtTRij+iDF+UOJVA/A5SjHaMWPVbT0PblbwWkxQvaxBDEPN4NRp+5mLkxD6ETmJJFZx gfmB3N9vhqFjHVb9K6AqGc7qlhlGwoIj6x27F07lmNkYHXMqqdt9Nbk+FvjukDU4WMZYFtXu 4c43hclKCg2i+bgZ5rXNJFsLioaY2Z/6Yml4COwvhDSg+IXF8oZtnf0Y8EP9qPeC3DHpL5n1 IgcB5mpzcBdsQchIVVCYCljVf0g5wslfs0tKvyrOsSF1gX8NK6gY3mZb44f5M2yviL/DFCS2 lmZDX2HqCmgyI0GwLTEW9zuZKE0WT6FF2KbWv3QbkwplygCQYlwCeEDOiemIsGiM11ubvDNe Iotvv06IsC5+6VYb63GBqRty+wEOjBNgz8AsHdljGxZjavQRBHa24+lYASMfLUqqoGPPM9wj mgiyOfS9p+VZumNzjk11mHrTe+Y7HujHVCjC74Ue+QHeyuIjk0bxDQSISh+w1jw9v/nyN8wh /tugEC4DO9LhyJPprZcduHQtlIFXEeZbmvapXqLjgMIz1WUB7hGcUMUkZZWqlkGyLhOdFpJL DkTMxqmazRL/jWLHSIRKWx1tmTn0GXLpXitP8ud8P67jY8mI2A04seuFNZLmtQLxP9qIIdrd f7WYPo19e+0b83BiC7rGzsFNBFkuo0YBEADmrX6Ho18GYRk2GJZ3sy4g61oVuwAED+zGSsFt pYGGsOo/3rp9HRRcWR9qQ0osO14oB7swEhWnv4BMpab2WQ2BXM10W6B94yJsRMcZK4VJVSrP o/IEBrXe4roug+iG60wh4Cmi6Ojoi9OCarl+JVZCSclDy6cEv/MQRgwlNV+jvEqxVokdAwTY HrXpYpISnwCGcR6/eA+CHFvLQOkR+oHFqNuJsdx9e+OXP9MA5YLgi1atyHfkhGdDraLLTyGD aAqOaiOt7LdRL5xlaFejlHydkWEXbxSmIro7hHAFmyreslQ63V1vpLa6czylRqQ/us6iOidu rc+zsNAd7dbKVuOW/YEbiTrKwX7xjOa7lxYkOCBc+xa0Jj57FUoNQQdr678olgF5zqKvgZKa qiYSH6WR/wnKVmB8KQItyGZneq2f3Tqkc/S9Z45Olz7uYnN32uJAgn6awezkcK4iGSjQMzzg onP28LuLGoJVX92HWcYNBRW5T0Jqdro3i+XWLKWNsRSe8ifguH87CPfAtIsUJRUDvdR+XKF8 /TeXZfpdeU5tzOnRXPrST8L3Yw3Hpa//JtCmAXo02uer+fZm0e2+rB0cjn2P65fb5sb0jJNy mp1dwUEs+u0xHN3gHVBtPixCqnPVzFBygBtaPZF+6B6fhFLABNokIyii5NHYNS/NqEGTzwAR AQABwsFlBBgBCAAPBQJZLqNGAhsMBQkJZgGAAAoJEKxNqiqt3SqHOMQQAIojVofS2i1fAmML cnqhJVjB7nNZNTYGPGuqaSOk+P3nViihhkA+dhbntDRAipIzIoCOzBYQ69mY0LQAA1cAxC0T tqoDidp96OoGZfp1zWJu2pQrubfY8iR8+fxWPfQnPakVItp4Rexzg5oWsy070ysMhWemqRps DaozbJJU0dPCxIRCO28H20DLYF9LzK0BUQBJUcrGT7pLwyI2UXT8UdKBkyzezh53en+mnV2W a1U/syFstNBv5Y+XTemh882butmbBqGU4V47FK8BeBZdfrbqyz9fJMPQuV8esA3ucRP5gwDY S4z8QiofEfkPZ0V3ldGnpjJyCXdeYzMFgA/+cTmTO0lAA96+zB0Z/gcNwL/Nq1bX6P31mPsC PrBjlOUUCCBgek4D//oUKzoBF2YPQeMsqt7PKboHtTVeE0279vRifbIRF295X4nKVA4sWHpx V/HrSdpNQraWw7Sq4/iTbcqETNY48oWQBSeilGD+ZXKxtdUte8plVPDFoUxQZ6iQp3YqrEgi eNAwkMkiWb5zQ3YKd3JfsTOd1wd9Cc2jKaSE7fj3moAkSxQNZsgiQzMFThK7S/wcESpJfRxH hicIfJtLXgoQZOjH1zePjmdHxidhD65P8cfey++AYYSYWPyRrN5BW1Aam8FDOBpzU8pvNjWL NXdphurqQpFSRlvcRvXY Message-ID: Date: Fri, 18 May 2018 17:54:20 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <5E5AFE4B-CB2E-44A3-9ACD-142F6272F0AB@wordtothewise.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Authentication-Results: smtp42.i.mail.ru; auth=pass smtp.auth=dubrovin@corp.mail.ru smtp.mailfrom=dubrovin@corp.mail.ru X-Mras: Ok Archived-At: Subject: Re: [dmarc-ietf] Too bad that the EFAIL victims never heard of DKIM/DMARC 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, 18 May 2018 14:54:31 -0000 Another case is you e-mail account is compromised, and DKIM/DMARC are helpless again. Actually, you probably do not need to spoof the e-mail address and can attack with random From:, because message is decoded regardless of address in the From: and this attack does not require sender's signature to be checked. I haven't checked though. P.S. In addition, in most MUAs vulnerable, you can bypass DKIM/DMARC (and actually any headers check on MTA side) with message/partial. This kind of bypass is explained here http://securityvulns.comLdocument310.html but it's another story. 18.05.2018 17:16, Steve Atkins пишет: >> On May 18, 2018, at 7:09 AM, Vladimir Dubrovin wrote: >> >> >> EFAIL exploitation requires MitM conditions. Neither DKIM nor DMARC protect against attacker able to perform MitM. >> > It just requires the attacker to have a copy of the encrypted mail. Passive mitm is one approach to that, but only one of many. > > Cheers, > Steve > >> 15.05.2018 17:15, Kurt Andersen пишет: >>> Manipulating MIME structures in email messages to expose the encrypted content: https://efail.de/ >>> >>> --Kurt >>> >>> >>> _______________________________________________ >>> 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 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc -- Vladimir Dubrovin @Mail.Ru From nobody Fri May 18 14:01:13 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0EF412E04A for ; Fri, 18 May 2018 14:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyyaulmbG95S for ; Fri, 18 May 2018 14:01:04 -0700 (PDT) Received: from mail-pl0-x22f.google.com (mail-pl0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE78C12E03C for ; Fri, 18 May 2018 14:01:04 -0700 (PDT) Received: by mail-pl0-x22f.google.com with SMTP id n10-v6so5257819plp.0 for ; Fri, 18 May 2018 14:01:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=pPstE8zKf2oJRggV88zaDEBoXsnOJU4uM00l2hgxezQ=; b=D3A5ap0MOoy3l2wy8OmZ2CRlg9RJLw9abRtoyijnmxLmHph4JAywlirWIRW6y2Qog4 5ktPyQZtd/IzCw5/gOW9wL1QPOJOLIMgGK4TFa5ZKaYPBrv7lE3CErSqoT3S44R4ALDM BXT/O8GLU5W6Ne/HGql9l4zOtFm/hKTbLUgXYt0Ig4PQnZ38dlNTWI+opVTnirkWonUx hj2vdYYJdtWdMjZ7o+Ms+UY27nGreL0pNyQsLvS39widN9817oi10cnnyz0EueO88jso jUd+XScvInqypjMRXHRarGb+bSk/Xt4UKb79j1fe3HgGiCgiRrdIovCd2NgcoW/wlv39 C1qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=pPstE8zKf2oJRggV88zaDEBoXsnOJU4uM00l2hgxezQ=; b=nkjRGRebyl83jEis0SQs3nGDfVrjaEI/cSGnBXbOF7VoM3UBXapjBe+negXP7M3zRF 8dJ7oSIkvWYWBKa3/ok/zPek/8Lv6INfgCww1l3d1UBjIxjnBv/7IzZ95bA7nMWR7HG0 nZUPv+ao3BiFszBTDW37DdyyuXE663dl7FbWYLs4yVQRbvh0VaQnpJf0j9wwAKH6k99X Xx0ZmAjkYapd5tFL6P0kCQKgdLgafP39d6o2R85ZznQTry8UljRGn0lZco0tj0qoLTbO DNXv3xXNhWPdeVO2IM2D72ySgNgTsNZ6Krn9Xqb/Wj7WNwJzRZl+fDGCsK/POjRC/Xn7 MYjA== X-Gm-Message-State: ALKqPwdUfC/0MZsBLjR/2JY4Ci6K93ffi1eeTObrk88OkntfgNCrd9xQ pVaIIbqEVtIIYLG55NtVrXakWP3P X-Google-Smtp-Source: AB8JxZrp5Z4JT9jlHIOHNuYEZqD7qSodf8APyW79iq/qKmHse9EY5iIK7wvXfwqo873j1A9QLl692Q== X-Received: by 2002:a17:902:7082:: with SMTP id z2-v6mr10829345plk.373.1526677261910; Fri, 18 May 2018 14:01:01 -0700 (PDT) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net. [76.218.8.128]) by smtp.gmail.com with ESMTPSA id n10-v6sm18763679pfj.68.2018.05.18.14.00.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 May 2018 14:00:59 -0700 (PDT) From: Dave Crocker To: IETF DMARC WG Message-ID: <99d92251-3ba1-c233-eccf-1785c2338859@gmail.com> Date: Fri, 18 May 2018 14:00:57 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] Review of: draft-ietf-dmarc-arc-protocol-14 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, 18 May 2018 21:01:11 -0000 Review of: Authenticated Received Chain (ARC) Protocol I-D: draft-ietf-dmarc-arc-protocol-14 orgination Review by: D. Crocker Review date: (The usual caveat about my reviews: Comments are a mixture of major and minor, substantive and trivial, objective and stylistic. Do with them as you wish. /d) Summary: The draft starts using terms of art that haven't been defined yet. Also it should do quite a bit more of cross-citing, when using a term, so the read knows where to go to find out the underlying technical detail that the term covers. The beginning of a spec should have summary text that explains a) explains the problem or needs space; what issue is being addressed by the spec? b) what goals are being sought; how can the reader know whether the spec has done its job? c) the basic approach/design of the spec; and optionally how this differs from existing, related work. This allows a superficial reading by technical and non-technical folk, where the latter don't proceed to the rest of the document, but they walk away with a useful and accurate sense of what this spec is about. Given the current draft's existing organization, all 3 of these should be in Section 1. The draft does not really explain why certain mechanisms or choices are present. For example, every time there is a reference to DKIM similarities, there should be text explaining why DKIM wasn't just used. Also, an ARC set has two signatures, rather than one. Why? General comments on readability: * Make sure discussions are partitioned well, and that topics aren't conflated. * Try for shorter sentences and make sure all sequences are extremely clear and logical -- having validation come before signing/sealing is an issue here. * When using a term, make sure it has been defined earlier. When the term is defined externally, make sure the citation to it is precise, ie, fine-grained into the external document. (the draft does a pretty good job of this.) * Make sure specialized terms have narrow application -- 'fail' vs. 'validate' is an example of a possible problem here, since they are formal terms. The design of DKIM extensively considere signature survivability in transit. It's limitations in that regard are well-known. There should be some commentary about ARC on this issue. I think the substance is merely that ARC signature survivability is approximately the same as DKIM's when relaxed mode is usedm but this should be documented explicitly. In particular, any differences in survivability expected from differences in the choice of header fields that are covered should be discussed carefully. ("carefully" doesn't necessarily require verbosity...) Organizational issue: I'm finding myself thinking that the ARC text should be split into separate documents, but I'm not sure what to suggest. Some of the text is essentially specifying an extension to DKIM. Some of it is extending Authentication Results. Some of it is extending DMARC. When a spec is really covering a number of separate (but related) topics, I usually find that things get /much/ simpler if they are documented separately. First, the text usually is simpler. Second, the lifecycle of the components can proceed independently. DMARC is what's motivating this work but, really, it isn't DMARC work (in the technical sense; I'm not raising an issue about it's being in that working group.) I often note the distinction between what motivates some work, versus the nature of the work. For example, email authentication would be a good idea even if there were no abuse; but the abuse is an effective motivator. Another attempt to summarize the nature of ARC: ARC is a response to message handling authentication fragility (which encompsses both SPF and DKIM.) It deals with some types of fragility by providing mid-transit message analysis and signing. The analysis is to perform authentication prior to expected breakage, and then to package the analysis results for consideration by later receivers, including the final destination. Reporting is an adjunct function. As with DMARC, it might turn out to be especially useful, but it's not a primary goal. Yet DMARC is heavily referenced in the draft. I'd like to find a way to take it completely out of the critical path of the main document. Taking it out of everything but the Introduction would be ideal. This permits focusing on ARC as a basic enhancement of authentication, rather than as integral with DMARC. Detailed: > Abstract > > The Authenticated Received Chain (ARC) protocol creates a mechanism > whereby a series of handlers of an email message can conduct > authentication of the email message as it passes among them on the > way to its destination, and create an attached, authenticated record > of the status at each step along the handling path, for use by the > final recipient in making choices about the disposition of the > message. Changes in the message that might break existing > authentication mechanisms can be identified through the ARC Set of > header fields. Given that 'authentication' is in the title, redundant use of that core semantic word in the explanatory text "authentication of the email message" in summary statements like the Abstract is actually not very helpful. What does it mean to 'conduct' authentication of a message? It could mean many things. Which one is actually meant? We should not assume the reader has a background in this general area, nevermind this specific area. (Yes, this is 'just' the abstract, but that's the bit of text that gets circulated, to recruit more readers. So its readability should target a wide audiencew.) Hmmm. 'conduct' authentication sounds like verification rather than signing. The value add of ARC is that a series of handlers affix authentication information. I suggest adding this existing, excellent sentence from the Intro: ARC provides an authenticated "chain of custody" for a message, allowing each entity that handles the message to see what entities handled it before, and to see what the authentication status of the message was at each step in the handling. (I added 'authenticated'.) > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 > 1.1. General Concepts . . . . . . . . . . . . . . . . . . . . 5 > 1.2. Differences Between ARC and DKIM . . . . . . . . . . . . 5 > 1.3. Definitions and Terminology . . . . . . . . . . . . . . . 6 > 1.3.1. Terms defined and used in this document . . . . . . . 6 > 1.3.2. Referenced Definitions . . . . . . . . . . . . . . . 7 > 2. Protocol Elements and Features . . . . . . . . . . . . . . . 7 > 2.1. The "ARC Set" of Header Fields . . . . . . . . . . . . . 8 > 2.1.1. Instance Tags . . . . . . . . . . . . . . . . . . . . 9 > 2.2. Chain Validation Status . . . . . . . . . . . . . . . . . 9 > 2.3. Trace Information . . . . . . . . . . . . . . . . . . . . 9 > 2.4. Key Management . . . . . . . . . . . . . . . . . . . . . 9 > 2.5. All Failures are Permanent . . . . . . . . . . . . . . . 10 > 2.6. Chain of Custody . . . . . . . . . . . . . . . . . . . . 10 > 2.7. Optional Participation . . . . . . . . . . . . . . . . . 10 > 2.8. Broad Responsibility to Seal . . . . . . . . . . . . . . 10 > 2.9. One Chain to Rule Them All . . . . . . . . . . . . . . . 11 > 2.10. Sealing is Always Safe . . . . . . . . . . . . . . . . . 11 > 3. The ARC Header Fields . . . . . . . . . . . . . . . . . . . . 11 > 3.1. Instance ('i=') Tag . . . . . . . . . . . . . . . . . . . 11 > 3.2. ARC-Authentication-Results (AAR) . . . . . . . . . . . . 12 > 3.3. ARC-Message-Signature (AMS) . . . . . . . . . . . . . . . 12 > 3.4. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . . . 13 > 3.4.1. Covered Header Fields . . . . . . . . . . . . . . . . 13 > 3.4.2. The 'cv' Tag . . . . . . . . . . . . . . . . . . . . 14 > 4. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . 14 > 4.1. Authentication-Results Information . . . . . . . . . . . 15 > 4.2. Handling DNS Problems While Validating ARC . . . . . . . 16 > 4.3. Responding to ARC Validity Violations During the SMTP > Transaction . . . . . . . . . . . . . . . . . . . . . . . 16 > 5. Sealer Actions . . . . . . . . . . . . . . . . . . . . . . . 16 > > > > Andersen, et al. Expires October 25, 2018 [Page 2] > > > Internet-Draft ARC-Protocol April 2018 > > > 5.1. Marking and Sealing "cv=fail" (Invalid) Chains . . . . . 17 > 6. Recording and Reporting the Results of ARC Evaluation . . . . 17 > 6.1. Information from an ARC Evaluation . . . . . . . . . . . 17 > 6.2. Recording (local) ARC Evaluation Results . . . . . . . . 17 > 6.3. DMARC Reporting of ARC Findings - Interim . . . . . . . . 18 > 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 > 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 > 8.1. Authentication-Results Method Registry Update . . . . . . 19 > 8.2. Email Authentication Result Names Registry Update . . . . 19 > 8.3. Definitions of the ARC header fields . . . . . . . . . . 19 > 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 > 9.1. Header Size . . . . . . . . . . . . . . . . . . . . . . . 20 > 9.2. DNS Operations . . . . . . . . . . . . . . . . . . . . . 20 > 9.3. Message Content Suspicion . . . . . . . . . . . . . . . . 21 > 10. Evaluating the Efficacy of the ARC Protocol (Experimental > Considerations) . . . . . . . . . . . . . . . . . . . . . . . 21 > 10.1. Success Consideration . . . . . . . . . . . . . . . . . 21 > 10.2. Failure Considerations . . . . . . . . . . . . . . . . . 22 > 10.3. Open Questions . . . . . . . . . . . . . . . . . . . . . 22 > 10.3.1. Value of the ARC-Seal (AS) Header . . . . . . . . . 22 > 10.3.2. DNS Overhead . . . . . . . . . . . . . . . . . . . . 22 > 10.3.3. Distinguishing Valuable from Worthless Trace > Information . . . . . . . . . . . . . . . . . . . . 22 > 11. Implementation Status . . . . . . . . . . . . . . . . . . . . 23 > 11.1. GMail test reflector and incoming validation . . . . . . 24 > 11.2. AOL test reflector and internal tagging . . . . . . . . 24 > 11.3. dkimpy . . . . . . . . . . . . . . . . . . . . . . . . . 24 > 11.4. OpenARC . . . . . . . . . . . . . . . . . . . . . . . . 25 > 11.5. Mailman 3.2 patch . . . . . . . . . . . . . . . . . . . 25 > 11.6. Copernica/MailerQ web-based validation . . . . . . . . . 25 > 11.7. Rspamd . . . . . . . . . . . . . . . . . . . . . . . . . 26 > 11.8. PERL MAIL::DKIM module . . . . . . . . . . . . . . . . . 26 > 11.9. PERL Mail::Milter::Authentication module . . . . . . . . 27 > 11.10. Sympa List Manager . . . . . . . . . . . . . . . . . . . 27 > 11.11. Oracle Messaging Server . . . . . . . . . . . . . . . . 27 > 11.12. MessageSystems Momentum and PowerMTA platforms . . . . . 28 > 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 > 12.1. Normative References . . . . . . . . . . . . . . . . . . 28 > 12.2. Informative References . . . . . . . . . . . . . . . . . 29 > 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 30 > Appendix A. Appendix A - Design Requirements . . . . . . . . . . 31 > A.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 31 > A.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 31 > Appendix B. Appendix B - Example Usage . . . . . . . . . . . . . 31 > B.1. Example 1: Simple mailing list . . . . . . . . . . . . . 31 > B.1.1. Here's the message as it exits the Origin: . . . . . 31 > B.1.2. Message is then received at example.org . . . . . . . 32 > B.1.3. Example 1: Message received by Recipient . . . . . . 34 > > > > Andersen, et al. Expires October 25, 2018 [Page 3] > > > Internet-Draft ARC-Protocol April 2018 > > > B.2. Example 2: Mailing list to forwarded mailbox . . . . . . 35 > B.2.1. Here's the message as it exits the Origin: . . . . . 35 > B.2.2. Message is then received at example.org . . . . . . . 36 > B.2.3. Example 2: Message received by Recipient . . . . . . 40 > B.3. Example 3: Mailing list to forwarded mailbox with source 42 > B.3.1. Here's the message as it exits the Origin: . . . . . 42 > B.3.2. Message is then received at example.org . . . . . . . 43 > B.3.3. Example 3: Message received by Recipient . . . . . . 48 > Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 50 > Appendix D. Comments and Feedback . . . . . . . . . . . . . . . 51 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 > > 1. Introduction This initial part of this section should lay out the nature of the problem being solved and the nature of the benefit being sought. I think it does a reasonable job of this. > Modern email authentication techniques such as the Sender Policy > Framework (SPF) [RFC7208] and DomainKeys Identified Mail (DKIM) > [RFC6376] have become common. However, their end-to-end utility is > limited by the effects of intermediaries along the transmission path, > which either are not listed (for SPF) or which break digital > signatures (for DKIM). These issues are described in substantial > detail in those protocols' defining documents as well as in [RFC6377] > and [RFC7960]. > > Technologies that build upon the use of SPF and DKIM can reduce the > success of fraudulent email campaigns. To this end, Domain-based > Mail Authentication, Reporting and Conformance (DMARC) [RFC7489], > validates the domain of the RFC5322.From header field. However its > use along email transmission paths that have independent > intermediaries, such as some forwarders and essentially all mailing > list services, produces false positive rejections that are > problematic, both for the message authors, the intermediary > service(s), and for those they are interacting with. > > [RFC7960] documented the need for a mechanism which would survive > legitimate alteration of a message, in spite of breaking the > associated SPF and DKIM information so that the end receiver breaking the associated SPF and DKIM information -> associated SPF and DKIM information that is broken (subtle distinction. The first ARC signer presumably did the breaking, but later signers presumably didn't...) > system(s) can avoid those false positive rejections on delivery. > Authenticated Received Chain (ARC) builds upon DKIM mechanisms to > provide a sequence of signatures that provide a view of the handling > sequence for a message, especially the points where alterations of > the content might have occurred. Equipped with this more complete Authenticated Received Chain (ARC) adapts DKIM so that signatures are affixed to the message, as a recorded audit of the message handling sequence, especially... > information, the recipient system(s) can make a more informed > handling choice, reducing or eliminating the rejections that would handling -> disposition (handling includes relaying, and that's not what is meant here.) > occur with the use of DKIM and/or SPF alone. > > > > > > > Andersen, et al. Expires October 25, 2018 [Page 4] > > > Internet-Draft ARC-Protocol April 2018 > > > 1.1. General Concepts My hope, for a sub-section like this, is that it supplies enough detail to be useful for a non-technical reader to understand the basic approach ARC is taking to solve the problem layed out in the initial part of the Introduction. > ARC provides a "chain of custody" for a message, allowing each entity > that handles the message to see what entities handled it before, and > to see what the authentication status of the message was at each step > in the handling. The handling entity can then put its own entry into > the chain of custody and then relay the message to the next handler. This section is missing quite a bit of conceptual explanation for ARC's purpose and design. I suggest adding something like this here: The ARC chain of custody provides information to augment receiver analysis, when the authentication information provided by the originator fails. ARC supplies related analysis information that is obtained during transit. ARC adds intermediate analysis report information to the message, along with two signatures. The first signs the message, itself, in a manner that is similar to DKIM. The second signs the chain of signatures, by ARC-participating intermediaries, thereby creating an authenticated chain of custody. > > When the message reaches final delivery, the decision to accept and > deliver the message, or, alternatively, to reject, discard, or > quarantine it, can take the chain of custody into account, applying > local policy in addition to policies advertised by the (purported) > sending domain. Consider, for example, this scenario: applying -> evaluating whether to apply (btw, why plural 'policies'? DMARC asserts a single policy.) > 1. A sender from mysender.example posts a message to a mailing list > hosted at listmania.example; > > 2. The mailing list modifies the message by prepending the list name > to the subject line, then sends it to the subscribers; > > 3. One of the subscribers is alice@mail.service.example, which > receives the message from listmania.example. > > Assuming the original message was DKIM-signed and mysender.example > published an SPF record, the handling by the mailing list will break > the DKIM signature because of the message modification, and the > forwarding will cause the SPF check to fail in the next step. But > listmania.example can add ARC headers to the message to add itself to > the document's chain of custody. When mail.service.example sees the > message, it can see that SPF and DKIM validation fail, but it can > also see that both of these succeeded when they were checked by > listmania.example, and can verify listmania's assertion. but it can see that listmania.example reports that it succeeded when that site received the message. (the reason for suggesting the wording change is to move from implying that it actually succeeded to the more tentative -- but accurate -- fact that listmania's claim of success requires trusting listmania... IMO this essential distinction cannot be stressed enough, about ARC.) > > As part of its evaluation of the message for delivery, > mail.service.example can see that mysender.example publishes a DMARC > policy asking that unauthenticated messages be rejected. But is can > also see the assertion by listmania.example that the message was > correctly authenticated when the message arrived there, and if it > accepts that assertion, it can accept the message for further > processing, rather than reject it, based on the additional > information that ARC has provided. This is pedantic, but I suggest having a paragraph break for the last part, to so that this essential point is harder to miss. Hence: If mail.service.example accepts the assertion by the intermediary, listmania.example, then it can accept the message... > > 1.2. Differences Between ARC and DKIM There should probably be some text here that explain why these differences are needed. That is, answer the question: Why not just use DKIM? (BTW, the early discussions consider differences that would make the signature somewhat more survivable during transit, but there's no reference to that here. I don't know whether that goal survived...) > In DKIM, every participating signing agent attaches a signature that > is based on some of the content of the message, local policy, and the > domain name of the signing agent's Administrative Management Domain > (ADMD). Any verifier can process such a signature; a verified delete 'participating' 'local policy' doesn't have any obvious meaning to me. The domain name doesn't have to be tied to the ADMD. It usually is, but it doesn't have to be. For example, an authorized third party such as a bulk sending service might sign on behalf of a client; this practice is common. So perhaps: , and a domain name. Just drop the additional detail. > > > Andersen, et al. Expires October 25, 2018 [Page 5] > > > Internet-Draft ARC-Protocol April 2018 > > > signature means that the domain referenced in the signature's "d=" > parameter has some responsibility for handling the message. An > artifact of using digital signature technology for this means that > verification also ensures that the portion of the message that was > "covered" by the signature has not been altered since the signature > was applied. The signatures themselves are generally independent of > one another. > > In contrast, a validated ARC Set conveys the following pieces of > information: ARC Set hasn't been defined, so the reader won't know what it means. For this introductory section, before technical definitions and details have been offered, I suggest keeping the discussion more generic or at least self-explanatory. Perhaps: In contrast, ARC supplies a set of signatures; their validation conveys... > > 1. An assertion that, at the time that the intermediary ADMD > processed the message, the various assertions (such as SPF, DKIM- > Signature(s) and/or ARC Chain) already attached to the message by > other ADMDs were or were not valid; "the intermediary ADMD"? There can be a sequence of them. I think you mean something like "the first ARC intermediary ADMD" or somesuch. > > 2. As with DKIM, an assertion that, for a validated ARC signature, > the domain name in the signature takes some responsibility for > handling of the message and that the covered content of the > message is unchanged since that signature was applied; > > 3. A further assertion that binds the ARC evaluation results into > the ARC Chain sequence. This is a well-formed and relatively simple sentence, but I'm finding myself having no idea what it actually means. Really. I suggest re-forming the sentence to establish what the purpose/benefit of this point is. "ARC evaluation results"? What does this mean. It hasn't been introduced yet. > > 1.3. Definitions and Terminology > > This section defines terms used in the rest of the document. > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in > BCP14 ([RFC2119][RFC8174]). > > Because many of the core concepts and definitions are found in > [RFC5598], readers should to be familiar with the contents of > [RFC5598], and in particular, the potential roles of intermediaries > in the delivery of email. Many of the core concepts and definitions used here are found in Internet Mail Architecture [RFC5598]. So readers are encouraged to be familiar with it, an in particular... (Found myself thinking it better to include the doc title and not just the citation.) > > Syntax descriptions use Augmented BNF (ABNF) [RFC5234]. > > 1.3.1. Terms defined and used in this document Style suggestion: Use hanging indents, rather than bullets, with the term unquoted and as the label. So, for example: ARC-Authentication-Results (AAR): an ARC header field described in Section 3.2. Also, I think that the definitions section should contain actual definitions, not just pointers to other sections. The danger, of course, is the possibility of creating multiple definitions for the same term. The way to avoid that is to make sure that the later discussion of the term, supplying the technical detail, doesn't contain a 'definition'. That is, define here, elaborate there. > o "ARC-Authentication-Results" (AAR) - an ARC header field described > in Section 3.2. > > o "ARC-Message-Signature" (AMS) - an ARC header field described in > Section 3.3. > > > > > Andersen, et al. Expires October 25, 2018 [Page 6] > > > Internet-Draft ARC-Protocol April 2018 > > > o "ARC-Seal" (AS) - an ARC header field described in Section 3.4. > > o "ARC Set" - A single group of the header fields introduced in > Section 2.1 is called an "ARC Set". I think the 'single group' is a group created by a single ARC participating site, yet? Making this clear, here, would be helpful. > > o "ARC Chain" - the complete sequence of ARC Sets for a message. > The ARC Chain represents a "chain of custody" for the message, > recording its authentication status at each ARC-participating ADMD > that handled the message. > > 1.3.2. Referenced Definitions Might want to move the above text that suggests familiarity with 5598 to be here, since you've got direct citations to it here. > The following terms are defined in other RFCs. Those definitions can > be found as follows: > > o ADMD - [RFC5598], Section 2.3 > > o MTA - [RFC5598], Section 4.3.2 > > o MSA - [RFC5598], Section 4.3.1 > > o MDA - [RFC5598], Section 4.3.3 > > The three header fields that are part of this specification borrow > heavily from existing specifications. Rather than repeating all of > the formal definitions that are being reused in ARC, this document > only describes and specifies changes in syntax and semantics. Presumably the above paragraph is refined by the following one, but there's nothing in the writing the makes that explicit. I suggest swapping the paragraphs, and adapting the above (with text to make it refer explicitly to the next one.) > > Language, syntax, and other details are imported from DKIM [RFC6376]. > Specific references can be found below. > > 2. Protocol Elements and Features Hmmm. As I've read through this section, I'm finding myself thinking there needs to be a distinction between core concepts, like key management and chain of custody, versus details of practice, such as all failures are permanent. And this distinction should split into two sections. > As with other domain authentication technologies (such as SPF, DKIM, > and DMARC), ARC makes no claims about the contents of the email > message it has sealed. However, for a valid and passing ARC Chain, a > Final Receiver is able to ascertain: "valid and passing"? what does this mean? eg, what would valid and not passing mean? "Final Receiver" is capitalized, but hasn't been defined. I assume this is a modification of the RFC 5598 Receiver term. Might want to cite Receiver in terminology, above, and not capitalize final. (Note that because ARC covers re-posted messages that go through intermediaries such as mailing list, there really can be multiple 'receivers', in RFC 5598 terminology; so the 'final' qualifier makes sense, but it needs to be explained.) 'seal' is a term of art -- and an important one for ARC -- but it hasn't been defined. > > o all (participating) domains that claim responsibility for handling > (and possibly modifying) the email message in transit; > > o trace information, including: > > * the [RFC7601] Authentication-Results each participating ADMD > saw; and > > * additional data needed to compile a DMARC report for the > sending domain. Hmmm. This formally ties ARC to DMARC and it doesn't specify what the detail is. Since ARC really is only tied to DKIM, I suggest altering the wording to this. > > > > Andersen, et al. Expires October 25, 2018 [Page 7] > > > Internet-Draft ARC-Protocol April 2018 > > > Given this information, each receiver is able to make a more informed > local policy decision regarding message processing and, ultimately, > delivery to the end user in spite of authentication failure(s) and to > inform the message orgination system(s) through the DMARC report(s). orgination -> origination I assume there is nothing in ARC that alters the nature or detail in a DMARC report? Hence the 'inform' comment here seems to imply ARC-related detail in DMARC reports that won't be supplied... > Every participant in an ARC Chain, except for the originating sender originating sender -> Originator Another rfc 5598 term. > and Final Receiver, is both an ARC Validator (when receiving) and > then an ARC Sealer (when sending a message onward). This uses detail (validator and sealer) that hasn't been defined yet. Perhaps fudge the issue: and final Receiver, does both validation of existing ARC headers and signing of new ARC information (when sending a message onward.) > > _INFORMATIONAL_: It is important to understand that validating and > then immediately sealing a message leaves no room for message > modification, and many early implementations of ARC did not initially > work because both operations were performed in a single pass over the > message. > > The following protocol features are functional parts and design > decisions related the protocol that are not specific to either > Validators or Sealers, but ensure that the ARC Chain conveys this > information to a Final Receiver. The following features are common to participants doing either (or both) of validating or signing. These ensure that the ARC Chain... > > 2.1. The "ARC Set" of Header Fields > > Each "ARC Set" consists of the following three new header fields: delete 'new'. Explain where each set comes from. ie, who generates a set? > > 1. ARC-Authentication-Results (referred to below as "AAR"): > virtually identical in syntax to an Authentication-Results field > [RFC7601], this field records the results of all message > authentication checks done by the recording ADMD at the time the > message arrived. Additional information is placed in this field > compared to a standard Authentication-Results field in order to > support a more complete DMARC report; What is the specific info that is additional? Put in a pointer to the AAR specification. > > 2. ARC-Message-Signature (referred to below as "AMS"): virtually > identical in syntax to DKIM-Signature, this field contains the > signature about the message header and body as they existed at > the time of handling by the ADMD adding it (including any > modifications made by the sealing ADMD); and header -> header fields about -> over handling -> signing of the handling by the ADMD... sealing ADMD) -> of the signing. The ADMD does the signing after making modifications to the signing. How is this different from a DKIM signature? > > 3. ARC-Seal (referred to below as "AS"): highly similar in structure > and format to a DKIM-Signature, this field applies a digital > signature that protects the integrity of all three of these new > fields when they are added by an ADMD, plus all instances of > these fields added by prior ADMDs. > > An ARC participant always adds all of these header fields before > relaying a message to the next handling agent _en route_ to its > destination. Moreover, they each have an "instance number" that > increases with each ARC Set in the handling chain so that thei thei -> the > > > Andersen, et al. Expires October 25, 2018 [Page 8] > > > Internet-Draft ARC-Protocol April 2018 > > > original order can be preserved and the three related header fields > can be processed as a set. > > 2.1.1. Instance Tags > > ARC includes an indicator in its header fields to show the order in > which the header fields comprising an ARC Chain were added, and the > specific members of each ARC Set. This is known as the "instance", > and the indicator is an "i=" tag/value. That is, the members of the > first ARC Set affixed to a message will all include "i=1". This is > described in detail in section Section 3.1. > > 2.2. Chain Validation Status > > ARC includes a mechanism which denotes the state of the ARC Chain at > each step. The "chain validation status" ("cv" tag/value) is used to > communicate the current chain status within the ARC Chain and also > through Authentication-Results and ARC-Authentication-Results stamps > as well as DMARC reporting. This language seems to mean that chain status is communicated in 3 ways (cv, auth-results, and arc-auth-results.) I suspect that that is not the intended meaning, but I don't even have a guess about what is actually meant. Really. Also, 'mechanism' might not be the most helpful word. I suspect 'indicator' is closer. > > The chain validation status has one of three possible values: > > o none: There was no chain on the message when it arrived for > validation; typically occurs when the message arrives at a Message > Transfer Agent (MTA) or mediator from a Message Submission Agent > (MSA) or when any upstream handlers may not be participating in > ARC handling; > > o fail: The message has a chain whose validation failed; > > o pass: The message has a chain whose validation succeeded. I suggest adding a pointer to the definition of chain validation (3.4.2) here, and a citing the computation of validation as per Section 4. > > 2.3. Trace Information > > ARC includes trace information encoded in the AAR. While section trace of what? explain its nature, enough to distinguish it from a variety of reasonable other meanings. In particular, of course, how is it different from Received? > Section 3.2 defines what information must be provided, sealing ADMDs > may provide additional information, and validating receivers may use > this trace information as they find it useful. The text here isn't specifying detail, so don't use normative language. must be -> is may provide -> can provide delete the ", and..." clause. It's using normative language but provides no substance. > > 2.4. Key Management > > The public keys for ARC header fields follow the same requirements, > syntax and semantics as those for DKIM signatures, described in > Section 3.6 of [RFC6376]. ARC places no requirements on the > selectors and/or domains used for the ARC header field signatures. > > > > > > > Andersen, et al. Expires October 25, 2018 [Page 9] > > > Internet-Draft ARC-Protocol April 2018 > > > 2.5. All Failures are Permanent > > Because ARC Chains are transmitted across multiple intermediaries, > all errors, even temporary ones, become unrecoverable and are > considered permanent. > > Any error validating or sealing a chain, for whatever reason, MUST > result in a "cv=fail" verdict as documented in Section 3.4.2. > > 2.6. Chain of Custody > > At a high level, an ARC Chain represents a chain of custody of > authentication and other trace information (AAR) related to a > message, signed by each handler of the message. Each link in the > chain (AMS) is designed to be brittle, insofar as it survives only > until the next modification of the message. However, the sequence of > intermediaries in the handling chain (AS) is designed to remain > intact over the entirety of the chain. I suspect "chain of custody of authentication" is not a correct summary of what ARC does; I'm not even sure what it means. The language needs to distinguish purpose from method. Authentication is a method, not a purpose. I'd guess the summary description should be something like: An ARC Chain establishes a validated handling sequence for message, through participating email handlers of it. Whatever the final text of such a summary winds up being, it should appear much sooner -- presumably in the Introduction or at least in the definitions -- and it shouldn't be repeated deeper in the document. An AMS is a 'link in the chain'??? I susect not really, though I can see why it might be called that. I suspect each seal constitutes a link. > > The ARC Chain can be conceptualized through an analogy with the chain > of custody for legal evidence. The material evidence itself is > sealed within an tamper-proof bag (AMS) each time. When handed to a > new party, that party both vouches for the state of the received > evidence container (AAR) and signs for the evidence on a chain of > custody report form (AS). As with all analogies, this one should not > be taken to interpretive extremes, but primarily used as a conceptual > framework. can be conceptualized through an analogy with the -> is similar to a (I had a 10th grade English teacher who beat my convoluted language to death, until I learned to simplify it and make it more direct. For the most part.) material evidence -> material evidence (the message) each time -> by each participating handler The comparison to legal c-o-e gets tortured and isn't explained adequately. For example, it uses 'evidence container' as if the term is established, but it hasn't been and is used only once. And the AAR isn't the container. It's a report of the assessment of the contents in the container. > > An ARC Chain that is valid and passing has the attributes listed > above in Section 2. 'passing'??? something like failures are permanent is not an 'attribute'. this adds to my suggestion to distinguish core concepts (possibly worth calling attributes) from practices. > > 2.7. Optional Participation > > Validating an existing chain and then adding your own ARC Set to a > message allows you to claim responsibility for handling the message > and modifications, if any, done by your ADMD to benefit message > delivery downstream. However, no ADMD is obligated to perform these > actions. claim responsibility -> claim some responsibility 'handling modifications'? (the parallel construction doesn't quite work.) done by your ADMD to benefit message delivery downstream -> done by you. (Not sure that use of you/your here works. At the least, the document should be reviewed carefully for the perspective of such usage, to decide whether it is consistent and accurate. I'm not objecting to the form -- though some with nitpick the informality in a spec -- but rather expressing concern that it not be inconsistent.) However -> NOTE: (The however declares a contrast with the preceding text, but there isn't any contrast.) > 2.8. Broad Responsibility to Seal > > Any mediator ([RFC5598], section 5) that modifies a message may seal > its own changes. ARC is not solely intended for perimeter MTAs. introduce mediator in the terminology section. 'may'? or SHOULD? There's nothing here that asserts or describes 'responsibility'. Also, the language here seems to proscribe sealing for handlers that don't modify the message. Is that intended? > > > > > > > > Andersen, et al. Expires October 25, 2018 [Page 10] > > > Internet-Draft ARC-Protocol April 2018 > > > 2.9. One Chain to Rule Them All > > A message can have only one ARC Chain on it at a time (see can -> MUST > Section 3.1). Once broken, the chain cannot be continued, as the cannot -> MUST NOT (?) > chain of custody is no longer valid and responsibility for the > message has been lost. For further discussion of this topic and the > designed restriction which prevents chain continuation or re- > establishment, see [ARC-USAGE]. > > 2.10. Sealing is Always Safe Offhand, I suspect the title is not correct. Each Seal is another opportunity for failure. > Even when an ARC Chain is valid and passes, its value is limited to > very specific cases. An ARC Chain is specifically designed to > provide additional information to a receiver evaluating message > delivery in the context of an authentication failure and otherwise be > benign. Specifically: > > o properly adding an ARC Set to a message does not damage or > invalidate an existing chain, > > o sealing a chain when you did not modify a message does not > negatively affect the chain, and unless the seal later fails to validate... > > o validating a message exposes no new threat vectors (see > Section 9). > > _INFORMATIONAL_: If an ADMD is unsure whether it will be re-emitting > and/or modifying a message, it may elect to seal all inbound mail. > For complex or nested ADMD relationships such as found in some hosted > mail solutions, this "inbound seal" can be used to facilitate > traversal of internal boundaries as well as properly conveying > incoming state to any egress MTAs that may need to assert a seal upon > exit from the ADMD. Since these internal relationships are highly > implementation dependent, this protocol definition can not usefully > explore such usage except to note that it is intentionally allowed > within the scope of this specification. > > 3. The ARC Header Fields > > 3.1. Instance ('i=') Tag 3.1. The Common Instance ('i=') Tag (I found it disconcerting to have the section say header fields and have the first sub-section not be a header field. The suggested title change might avoid that reaction.) > The header fields comprising a single ARC Set are identified by a > common "instance" tag value. The instance tag is a string in each > header field value that complies with the "tag-spec" ABNF found in > Section 3.2 of [RFC6376]. The tag-name is "i" and the value is the > text representation of a positive integer, indicating the position in > the ARC sequence this set occupies, where the first ARC Set is > numbered 1. In ABNF terms: The second sentence is generic about all tags used in the spec, not just i=. So it should be moved elsewhere, if it isn't already redundant. > > > > Andersen, et al. Expires October 25, 2018 [Page 11] > > > Internet-Draft ARC-Protocol April 2018 > > > position = 1*2DIGIT ; 1 - 50 > instance = [FWS] %x69 [FWS] "=" [FWS] position [FWS] ";" Why an upper limit of 50? > Valid ARC Sets MUST have exactly one instance of each header field > (of three) for a given instance value and signing algorithm. > > (_INFORMATIONAL:_ Initial development of ARC is only being done with > a single allowed signing algorithm, but parallel work in the DCRUP > working group [1] is expanding that. For handling multiple signing > algorithms, see [ARC-MULTI].) Algorithm agility is a long-established requirement for use in security components. The approach typically defines a registry for algorithms, while specifyin the requirement that all implementations support a default. > > The 'i' tag value can range from 1-50 (inclusive). > > ARC Chains longer than the defined maximum count MUST be marked as > failed. > > _INFORMATIONAL_: Because the AMS and AS header field values are made header field values -> header fields made up of -> use unordered > up of tag-spec constructs, the i= tag may be found anywhere within > the header field value, but is represented throughout this spec in the header field value -> the contents of the header field > the initial position for convenience. Implementers are encouraged to > place the i= tag at the beginning of the field value to facilitate > human inspection of the headers. Implementers -> However implementers > > 3.2. ARC-Authentication-Results (AAR) > > The ARC-Authentication-Results header field is syntactically and > semantically identical, except for the header field name itself and > its instance tag, to an Authentication-Results header field (defined > in Section 2.2 of [I-D-7601bis]). Except for the header field name itself and the presence of an instance tag, the ARC-Authentication-Results header field is syntactically and semantically identical to an Authentication- Results header field (defined in Section 2.2 of [I-D-7601bis]). > > Formally, the header field is specified as follows using ABNF > [RFC5234]: > > arc-info = instance [CFWS] ";" authres-payload arc-info = instance [CFWS] ";" authres-payload ; per I-D-7601bis (Note that instance /is/ order dependent in this ABNF...) > arc-authres-header = "ARC-Authentication-Results:" [CFWS] arc-info > > The AAR MUST contain all Authentication-Results from within the > participating ADMD, regardless of how many Authentication-Results > headers are on the message. participating ADMD -> participating ADMD creating this AAR > 3.3. ARC-Message-Signature (AMS) > > The ARC-Message-Signature header field is simplified version of a > DKIM-Signature header field [RFC6376], with the following > modifications: > > o There is an "i" tag, as described in Section 3.1. Adding a tag is not a 'simplification'... > > > > Andersen, et al. Expires October 25, 2018 [Page 12] > > > Internet-Draft ARC-Protocol April 2018 > > > o There is no "v" tag defined for the AMS header. As required for > undefined tags (in [RFC6376]), if seen, it MUST be ignored. > > ARC-related header fields (ARC-Seal, ARC-Message-Signture, ARC- > Authentication-Results) MUST NOT be included in the content covered > by the signature in the signature in this header field. "by the signature in the signature"??? Anyhow this proscription seems an odd use of MUST NOT, to me. There should be a formal specification of what MUST, SHOULD, and/or MAY be included. Anything not listed there is excluded. > > The AMS SHOULD include any DKIM-Signature header fields already > present on the message in the header fields covered by this > signature. "present on the message in the header fields covered by this signature"??? > > Authentication-Results header fields MUST NOT be included since they > are likely to be deleted by downstream ADMDs (per Section 5 of > [RFC7601]), thereby breaking the AMS signature. > > 3.4. ARC-Seal (AS) > > The ARC-Seal header field is syntactically and semantically similar > to a DKIM-Signature field, with the following exceptions: Delete: ", with the following exceptions" Saying "similar" is enough. > o Tag "i" tag is described in Section 3.1. o Tags "a", "b", "d, "s", "t" from Section 3.5 of [RFC6376]. o Tag, "cv" is defined in Section 3.4.2 > o The ARC-Seal covers none of the body content of the message. It > only covers specific header fields as defined below: > Section 3.4.1. No body canonicalization is done. > > o Only "relaxed" header canonicalization (Section 3.4.2 of > [RFC6376]) is used. > > o The only supported tags are "i" (from Section 3.1 of this > document), and "a", "b", "d, "s", "t" from Section 3.5 of > [RFC6376]. > > o An additional tag, "cv" is defined in Section 3.4.2 See above for suggested cleanup/streamlining of tag specifications > 3.4.1. Covered Header Fields > > The ARC-Seal signs a specific canonicalized form of the ARC Set "specific canonicalized form"??? what does this mean, given that 'relaxed' is dictated above. > header values. The ARC set header values are compiled in increasing compiled in -> arranged into (this being a computer science discipline, and 'compiled' being a term of art, let's avoid possible confusion...) > instance order, starting at 1, and include the set being added at the > time of sealing the message. > > Within a set, the header fields are listed in the following order: > > 1. ARC-Authentication-Results > > 2. ARC-Message-Signature > > > > > Andersen, et al. Expires October 25, 2018 [Page 13] > > > Internet-Draft ARC-Protocol April 2018 > > > 3. ARC-Seal > > Where the ARC-Seal is the one being generated, it is input to the > hash function in its final form except with an empty "b=" value, in > the same manner by which a DKIM-Signature signs itself ([RFC6376], > section 3.7). > > Note that the signing scope for the ARC-Seal is modified in the > situation where a chain has failed validation (see Section 5.1). I don't quite understand what this means. > 3.4.2. The 'cv' Tag > > A new tag "cv" (chain validation) indicates the outcome of evaluating > the existing ARC Chain upon arrival at the ADMD that is adding this > header field. The values are defined per Section Section 2.2. Section Section -> Section add: and are based on the Verifier Actions of Section 4. > In ABNF terms: > > chain-status = ("none" / "fail" / "pass") > seal-cv-tag = %x63.76 [FWS] "=" [FWS] chain-status Nevermind the values. What is the basis for asserting a value? Where is that defined? > > 4. Verifier Actions I continue to find it odd that the section on Verifier Actions precedes Signer Actions. I continue to suggest swapping them, to reflect the actual handling sequence for a message. > A verifier takes the following steps to validate the ARC Chain. > Canonicalization, hash functions, and signature validation methods > are imported from Section 5 of [RFC6376]. > > 1. Collect all ARC Sets currently on the message. If there were > none, the ARC state is "none" and the algorithm stops here. were -> are > > 2. Check the morphology of the ARC Chain. If any of these > conditions are not met, the chain state is "fail" and the > algorithm stops here: > > 1. Each ARC Set must be complete (e.g., contains exactly one of > each of the three ARC-specific header fields); e.g. -> i.e. (if there are more conditions than the one stated here, how is the algorithm to know what to check for?) > > 2. The instance values must form a continuous sequence from 1..N > with no gaps or repeats; continuous -> contiguous 1..N -> from 1 to the highest instance value found (N) (N wasn't defined.) > > 3. The cv value for all ARC-Seal(s) must be non-failing: > > 1. For i > 1, the value must be "pass"; > > 2. For i = 1, the value must be "none". > > 3. For each ARC-Message-Signature from the "N"th instance to the > first, validate the AMS: 3. From set N..1, validate each ARC-Message-Signature: > > > Andersen, et al. Expires October 25, 2018 [Page 14] > > > Internet-Draft ARC-Protocol April 2018 > > > 1. If the "N"th instance (most recent) signature fails, then the > chain state is "fail" and the algorithm stops here. *** I think there needs to be some careful discipline to distinguish validation failure from resulting status (eg, chain) failure. I suggest the discipline to be using different language rigorously. I propose 'does not validate' for the former and 'fails' for the latter. > > 2. If one of the prior AMS signatures fails to validate (for > instance "M"), then set the oldest-pass value to the lowest > AMS instance number which passed (M+1) and go onto the next > step (there is no need to check any other (older) AMS > signatures). This does not affect the validity of the chain. 2. If a prior AMS signature (instance M) does not validate, then set Oldest-Pass to M+1 and go... > > 3. If all AMS signatures verify, set the oldest-pass value to > zero (0). "oldest"? hmmm. It's actually the newest. That is, it is the most recent signature, in the chain of signatures. > > 4. For each ARC-Seal from the "N"th instance to the first, validate > the seal. 4. From ARC-Seal N..1, validate each seal > > 1. If any seal is not valid, the chain state is "fail" and the > algorithm stops here. 1. If a Seal does not validate, the chain statis is fail; terminate the algorithm here. > > 2. If all seals pass validation, then the chain state is "pass", > and the algorithm is complete. 2. If all seals validate... > > The end result of the verifier's checks via this algorithm MUST be > added into the Authentication-Results header(s) for the ADMD. for /which/ ADMD? > > _INFORMATIONAL_: Recipients of an ARC Chain that is invalid or does "invalid or does not pass" seems redundant. > not pass SHOULD NOT draw negative conclusions without a good > understanding of the wider handling context. Until ARC usage is This normative sentence has no substance. It does not specify a specific action and it cannot be tested. It also is arguably outside the scope of the spec... > widespread, intermediaries will continue to modify messages without > ARC seals. They'll do that after it's widespread too. > > As with a failing DKIM signature ([RFC6376] Section-6.3), a message > with a failing ARC Chain MUST be treated the same as a message with > no ARC Chain. +1 > > 4.1. Authentication-Results Information > > Certain information pertinent to ascertaining message disposition can > be lost in transit when messages are handled by intermediaries. For > example, failing DKIM signatures are sometimes removed by MTAs, and Since a failed DKIM signature is to be treated the same as having no DKIM signature, its removal should not affect disposition... > most DKIM signatures on messages modified by intermediaries will Except, for example, when adding Received:. So the statement needs some sort of qualifier. Not elegant, but perhaps something simple like "substantially modified". (I could argue for 'substantively' rather than 'substantially', but that's just fussy...) > fail. Recording the following information in the Authentication- > Results stamped as part of the ARC evaluation provides a mechanism > for this information to survive transit through a particular ADMD. > > Stamped ARC evaluation results is limited to the Chain Validation > status (cv) from Section 2.2. "stamped"? > > > > > Andersen, et al. Expires October 25, 2018 [Page 15] > > > Internet-Draft ARC-Protocol April 2018 > > > The ptypes and properties defined in this section SHOULD be recorded > in the Authentication-Results: > > o smtp.client-ip - The connecting client IP address from which the > message is received; > > o header.oldest-pass - The instance number of the oldest AMS that > still validates, or 0 if all pass. Shouldn't the label identify which method is involved, to ensure the reference is unambiguous? > > 4.2. Handling DNS Problems While Validating ARC > > DNS-based failures to verify a chain are treated no differently than > any other ARC violation. They result in a "cv=fail" verdict. Should there be any wiggle room allowed here, for holding the message and retrying the DNS query, given how often DNS queries have a temporary failure? > > 4.3. Responding to ARC Validity Violations During the SMTP Transaction > > If a receiver determines that the ARC Chain has failed, the receiver > MAY signal the breakage through the extended SMTP response code 5.7.7 > [RFC3463] "message integrity failure" [ENHANCED-STATUS] and > corresponding SMTP response code. > > 5. Sealer Actions > > An ARC sealer MUST take the following actions when presented with a > message: > > 1. Before creating an ARC signature, perform any other, normal > authentication and/or signing, so that the ARC signature can > cover those results. can cover those results -> has the option of covering any resulting message additions or modifications > > 2. Build and attach the new ARC Set: > > 1. If an ARC Chain exists on the message, then set "N" equal to > the highest instance number found on the chain (i=); > otherwise set "N" equal to zero for the following steps. exists -> already exists > 2. Generate and attach to the message an ARC-Authentication- > Results header field as defined in Section Section 3.2, using > instance number N+1 and the same content from the previous > step. Section Section > 3. Generate and attach to the message an ARC-Message-Signature > header field as defined in Section 3.3 above, using instance > number N+1. > > 4. Generate and attach to the message an ARC-Seal header field > using the general algorithm described in Section 3.4 above, > > > > > Andersen, et al. Expires October 25, 2018 [Page 16] > > > Internet-Draft ARC-Protocol April 2018 > > > the chain validation status as determined in Section 4, and > instance number N+1. > > 5.1. Marking and Sealing "cv=fail" (Invalid) Chains > > The header fields signed by the AS header field b= value in the case > of a chain failure MUST be only the matching instance headers created > by the MTA which detected the malformed chain, as if this newest ARC > Set was the only set present. This seems oddly worded. The fine-grained detail of saying b= seems distracting or possibly misleading. I'm not exactly sure what's precisely meant to be specified here, but here's a guess: In the case of a chain failure, the header fields covered by the newest AS signature MUST be only those specified for the newest ARC set, of the signer that detected the malformed chain. > > _INFORMATIONAL:_ In the case of a malformed or otherwise invalid > chain there is no way to generate a deterministic set of AS header > fields ({#implicit_as_h}) so this approach is mandated. Do you mean deterministic or do you mean accurate? In either case, it might be worth elaborating on your point a bit more. I suspect you also mean 'set of AS header fields across the entire chain'? > > 6. Recording and Reporting the Results of ARC Evaluation > > The evaluation of an ARC Chain provides information which will be > useful to both the receiver (or intermediary) and to the initial > sender of the message. This information should be preserved and > reported as follows. sender -> originator 'should'? normative? > > 6.1. Information from an ARC Evaluation > > The evaluation of an ARC Chain produces a list of domain names for > participating intermediaries which handled the message, to wit: "for"? perhaps "of"? > o A list of the "d=" domains found in the validated ARC-Seal header > fields > > o The "d=" domain found in the most recent (highest instance number) > AMS header field (since that is the only one necessarily > validated) > > In the case of a failed chain, only the terminal ARC Set is covered > by the ARC-Seal so the reporting is limited to the findings in that > terminal ARC Set. > > 6.2. Recording (local) ARC Evaluation Results > > Receivers who process an attached ARC Chain SHOULD add an > "arc=[pass|fail|policy]" method annotation into a locally-affixed > Authentication-Results [RFC7601] header field along with any salient > comment(s). > > Details of the ARC Chain which was evaluated should be included in > the Authentication-Results and AAR headers per Section Section 4.1. > > > > > > Andersen, et al. Expires October 25, 2018 [Page 17] > > > Internet-Draft ARC-Protocol April 2018 > > > 6.3. DMARC Reporting of ARC Findings - Interim > > Receivers SHOULD indicate situations in which ARC evaluation > influenced the results of their local policy determination. DMARC > reporting of ARC-informed decisions can be accomplished by adding a > local_policy comment explanation containing the list of data > discovered in the ARC evaluation, which at a minimum SHOULD include: > * the Chain Validation status, * the domain and selector for each AS, > * the IP addresses of the mail originating ADMD: > > > none > fail > fail > > local_policy > arc=pass ams[2].d=d2.example ams[2].s=s1 as[2].d=d2.example > as[2].s=s2 as[1].d=d1.example as[1].s=s3 client-ip[1]=10.10.10.13 > > > > In the sample above, d2.example is the sealing domain for ARC[2] and > d1.example is the sealing domain for ARC[1]. > > Intermediary message handlers SHOULD generate DMARC reports on > messages which transit their system just like any other message which > they receive. This will result in multiple reports for each mediated > message as they transit the series of handlers. DMARC report > consumers should be aware of this behaviour and make the necessary > accommodations. > > 7. Privacy Considerations > > The ARC Chain provides a verifiable record of the handlers for a > message. Anonymous remailers will probably not find this compatible > with their operating goals. Reporting back to the Originator also divulges Receiver details. << REVIEWED ENDED HERE >> D/ -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed May 30 02:22:42 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DA21241F3 for ; Wed, 30 May 2018 02:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.899 X-Spam-Level: X-Spam-Status: No, score=-2.899 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=univie.ac.at Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1armXa6jiTr for ; Wed, 30 May 2018 02:22:38 -0700 (PDT) Received: from grace.univie.ac.at (grace.univie.ac.at [IPv6:2001:62a:4:25::25:115]) (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 4281812D94F for ; Wed, 30 May 2018 02:22:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=univie.ac.at; s=rev2; h=To:Date:Message-Id:Subject:Mime-Version: Content-Type:From:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=esjCOA8PnxdbJMLEtn0Id1YuQzl/r6mWeDUWkwIm1Ic=; b=O42hnZkNF+24bf9glQUFc5pjMg VVTuw2SCUS6r58f7uCjltyCYsgmJHKEJkLysrtdcaArDYq21Ly0bL0RMFcnYvVMH583XCyGQ74w72 R2iJCe8SYRMeYDrM1wRmCg+KIyc+d5w6bnhhItjjOeRBMWtnmRcXWsjn7xURRQIWqFcw=; Received: from jarvis.univie.ac.at ([131.130.3.112] helo=jarvis.univie.ac.at) by grace.univie.ac.at with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1fNxJT-0004vH-G4 for dmarc@ietf.org; Wed, 30 May 2018 11:22:35 +0200 Received: from 84-112-240-30.cable.dynamic.surfer.at ([84.112.240.30] helo=[192.168.0.171]) by jarvis.univie.ac.at with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1fNxJT-0001UE-Av for dmarc@ietf.org; Wed, 30 May 2018 11:22:35 +0200 From: Lukas Puehringer Content-Type: multipart/alternative; boundary="Apple-Mail=_67789FDF-D0DA-4250-89FD-72E0DFB72C53" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Message-Id: <68F27598-1572-4BC7-AF4F-8A9A72A0A76B@univie.ac.at> Date: Wed, 30 May 2018 11:22:34 +0200 To: dmarc@ietf.org X-Mailer: Apple Mail (2.3445.6.18) X-Univie-Virus-Scan: scanned by ClamAV on jarvis.univie.ac.at X-Univie-DANE: verified mail.ietf.org Archived-At: Subject: [dmarc-ietf] DMARC viewer - open source self-hosted report analysis 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, 30 May 2018 09:22:41 -0000 --Apple-Mail=_67789FDF-D0DA-4250-89FD-72E0DFB72C53 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear DMARC community, I would like to share a software project that I=E2=80=99ve been working = on in the course of a CS masters thesis project at the University of = Vienna. "DMARC viewer" is a Django-based web application to visually analyze = DMARC aggregate reports. It provides an "analysis view editor=E2=80=9D = to compose and store sets of filters, based on the attributes of = aggregate reports. The source code is available on GitHub (MIT licensed) and includes = detailed instructions about deployment and usage: https://github.com/dmarc-viewer/dmarc-viewer = A live demo using random test data can be found at: https://dmarc-viewer.abteil.org Any feedback is highly appreciated! Thanks, Lukas Puehringer= --Apple-Mail=_67789FDF-D0DA-4250-89FD-72E0DFB72C53 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dear = DMARC community,

I = would like to share a software project that I=E2=80=99ve been working on = in the course of a CS masters thesis project at the University of = Vienna.

"DMARC viewer" is a Django-based web application to = visually analyze DMARC aggregate reports. It provides an "analysis = view editor=E2=80=9D to compose and store sets of filters, based on the = attributes of aggregate reports.

The source code is available on GitHub = (MIT licensed) and includes detailed instructions about deployment and = usage:
https://github.com/dmarc-viewer/dmarc-viewer

A live demo using random = test data can be found at:
https://dmarc-viewer.abteil.org

Any feedback is highly = appreciated!

Thanks,
Lukas = Puehringer
= --Apple-Mail=_67789FDF-D0DA-4250-89FD-72E0DFB72C53--