From nobody Tue Aug 1 06:36:13 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8AF1252BA for ; Tue, 1 Aug 2017 06:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbFM4YddNlgP for ; Tue, 1 Aug 2017 06:36:10 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79709132168 for ; Tue, 1 Aug 2017 06:35:56 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id r199so6132117vke.4 for ; Tue, 01 Aug 2017 06:35:56 -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; bh=v5Mzxokt9dTVPXCicWT7NPdXteqmyecv3hu/9fpIvkw=; b=CUUNdU3ZG2NWvDBuabhPmxxFYCL1/z0oXYD8gfM6W6NYl+tZjJVpQ76FZlF4b3UYjm s1BpXVdPt4tqM5MC2PgiWtshVUS9z3uCwS5xTOn1jfW77cV+DtSGx/WhaYshfm0vB5s0 iJqz8pnvFZdBqRaj9MVlT27a0RJkXhooQn7Fo= 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; bh=v5Mzxokt9dTVPXCicWT7NPdXteqmyecv3hu/9fpIvkw=; b=jTV1pbyyq4G3PdpJ4EQZQfB/f+uMhxkAZ0X0lqh8DslBoB8ALmIL4DAVbBgTI0K2A/ A5at0L0ixBjyrFvf3E35JgFRAjHO5gwRYv3BJbhLwGMxehdZtqWnzI00408559QMvX7s b2bf3sq99lRON6hPVA0lmF1oXqkSsft3rYdviMFEjUVY4KImHmcYmAjzht3TJuJJ3fSB c8NcnUmKrlnlw3T+AYdwhLRKvAs64zd1itzfemOPAQwc3Qm3NIdWiaeOO+7UgiUjgefb NA7kX79yQANYr/5R00OkT5It5IbvoP8cL2qghpVqId1sTNB4qzVrRb2S6HHZKR1PCJd1 2xoA== X-Gm-Message-State: AIVw113PvqgozzJ83B1FQ8NQ8EKwvWJg/xIhzPNnOnrMu/NFWuG9IOJs BSoFGv+SRPjFQOWwJQEN2BQh2FpxAWJx X-Received: by 10.31.139.207 with SMTP id n198mr876426vkd.3.1501594555505; Tue, 01 Aug 2017 06:35:55 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.176.26.19 with HTTP; Tue, 1 Aug 2017 06:35:55 -0700 (PDT) In-Reply-To: <893E5116-5433-4544-A016-42F3784718FA@kitterman.com> References: <3775088D-356B-48EA-82C2-117655840F83@kitterman.com> <893E5116-5433-4544-A016-42F3784718FA@kitterman.com> From: "Kurt Andersen (b)" Date: Tue, 1 Aug 2017 06:35:55 -0700 X-Google-Sender-Auth: lWhNbVa86bl3L2QlLOEeyFito2M Message-ID: To: Scott Kitterman , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a114584d013f8eb0555b13a79" Archived-At: Subject: Re: [dmarc-ietf] dns failures in the draft 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, 01 Aug 2017 13:36:12 -0000 --001a114584d013f8eb0555b13a79 Content-Type: text/plain; charset="UTF-8" Accidentally went off list - bringing it back here for everyone else to see. On Tue, Aug 1, 2017 at 4:08 AM, Scott Kitterman wrote: > On August 1, 2017 2:12:58 AM EDT, "Kurt Andersen (b)" > wrote: > >On Mon, Jul 31, 2017 at 10:59 PM, Scott Kitterman > > > >wrote: > >> > >> > >> If I understand correctly, the desired behavior is don't reject (5xx) a > >> message due to an ARC related DNS failure. Why not put it that way? > >> It seems like it would be clearer and simpler to specify it that way. > >> > > > > It's more than not 5xx'ing - it's "don't accept a message if you need > > ARC to determine whether it's acceptable if DNS prevents you from > > evaluating ARC". > > > >--Kurt > Right, but I don't think you need to say that explicitly. BTW, this was > off list. Did you intend that? If not, feel free to reply on list. > Scott K --001a114584d013f8eb0555b13a79 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Accidentally went off list - br= inging it back here for everyone else to see.

On Tue, Aug 1, 2017 at 4:08 AM, Scott Kit= terman <sklist@kitterman.com> wrote:
On August 1, 2017 2:12:5= 8 AM EDT, "Kurt Andersen (b)" <kboth@drkurt.com> wrote:
>On Mon, Jul 31, 2017 at 10:59 PM, Scott Kitterman
><sklist@kitterman.com>= ;
>wrote:
>>
>>
>> If I understand correctly, the desired behavior is don't rejec= t (5xx) a
>> message due to an ARC related DNS=C2=A0 failure.=C2=A0 Why not put= it that way?
>> It seems like it would be clearer and simpler to specify it that w= ay.
>>
>
> It's more than not 5xx'ing - it's "don't accept a= message if you need
> ARC to determine whether it's acceptable if DNS prevents you from<= br> > evaluating ARC".
>
>--Kurt
=C2=A0
Right, but I don't think you need to say that explicitly.=C2=A0= BTW, this was off list.=C2=A0 Did you intend that?=C2=A0 If not, feel free= to reply on list.
Scott K

=C2=A0

--001a114584d013f8eb0555b13a79-- From nobody Sun Aug 6 22:21:33 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D401212942F for ; Sun, 6 Aug 2017 22:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=DKfq/DtA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=gIvGLFji Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3-jSbPGa9vw for ; Sun, 6 Aug 2017 22:21:28 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EC1A1287A5 for ; Sun, 6 Aug 2017 22:21:28 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id E0A6720C45 for ; Mon, 7 Aug 2017 01:21:27 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Mon, 07 Aug 2017 01:21:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=gGoyjlUM+F0pvGYV5HTiGtG4OdTnuLozFeykP6Lx2 Rs=; b=DKfq/DtA60mOoFSSJt1j1oAsX7hicVhuhb4ry1itmB2QuHefAkCCEeDD3 PFrEdQiEzuVhGPVrlZnD6o31NzeZCtoB7TLlAlrvofNkeTFqWcJKZfMpj3UkfuSL miCFFo/xeRR3XDQge0aGZiFZTdSoqzOFQHnVbpHmEmO32ek5MAAX0vXxh/7g1z4t nH6l3fkfUWHxVPn5SIHWWzLwbhUSq/e8oVPjexryVFRYnv6fyl+RrzHBembS30tO cksPetGewCwGqeW2VkHo57eqK6kSdsToWJkuBf1aePaxHhHvCNO3XPF7NNF7n1tJ KpKi3CtIKyxH4lZLPij9g+q16/pzg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=gGoyjlUM+F0pvGYV5HTiGtG4OdTnu LozFeykP6Lx2Rs=; b=gIvGLFjiAFXTtUoekmhMPcvEW68zkp+/6rYULVNFeUG01 vRDNU+9Ts+rLD5SFO9dZW6LHccyfFPrp1+YhdVrRJg93EE8rGyiFwUtQUtms6P1M tsI9kBvi+F5Zkz34TgXayGDqmvm2MzDvmBZskb2qIlwSJi1gbfUDqYVBJxbhR02a QDvUJm5j+6orSNteZdYfw7hkh85XcV4S09WKBMnq7tU8DAjnvZnVhs7Mkgb4OYZ4 pPoTb6bFh1fuWj+8t3xdai4G9VyBOK/Eaw9A0IVmsyTQifW3Y1KDUKCGqjXAlfVw GERhxDJRUdkMyWGZdC7wW36QylokGKNzU8TTC7PtQ== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id B0E4C9E24F; Mon, 7 Aug 2017 01:21:27 -0400 (EDT) Message-Id: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> From: Bron Gondwana To: dmarc@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150208328721912480" X-Mailer: MessagingEngine.com Webmail Interface - ajax-7b2cde4a Date: Mon, 07 Aug 2017 15:21:27 +1000 Archived-At: Subject: [dmarc-ietf] ARC-Seal is meaningless security theatre 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 Aug 2017 05:21:32 -0000 This is a multi-part message in MIME format. --_----------=_150208328721912480 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" I thought long and hard about using a less inflammatory title, but I figure maybe going in hard is the right way here, because I'd rather fix this before it becomes a standard! (and thanks Dave for your thoughtful questions during the Prague DMARC session which prompted some of my thinking) Unfortunately I didn't get a full chance to think about ARC and how it all functions before Prague, and then I hadn't fully internalised it by the DMARC session - I was still refactoring the code I wrote on the weekend and testing it some more, as well as getting the signing side done. It took a few days to fully understand how all those signatures work together. I had let others focus on ARC within our company rather than looking at it myself until now. So my apologies for coming along late with this manifesto! I've been trying to think of a more polite and diplomatic way to say it, but so far I haven't see anything to convince me that ARC-Seal is anything other than snake oil. It's excessive crypto for no benefit, and with the way I've had it described to me and the way it's being used right now at least at Google (sealing every message on the way in), it adds confusion rather than clarity to message provenance. Let me explain. Starting with purpose. ARC conflates two purposes: a) providing a new signature when you change a message in ways that break its existing signature. b) providing a signature where there is none, but SPF passed and you would have trusted the source email anyway. Apparently "just DKIM sign everything" isn't viable due to key management problems and "sending on behalf of". I'm willing to stipulate that, because we have to work with the reality of deployed systems with any new standard if it wants traction. There is a third purpose that needs signatures: c) new email received from trusted/internal host with no signature yet This is generally handled by DKIM-signing the message before sending it outside an organisation's trusted infrastructure. FastMail for example DKIM signs our outbound email during the final scan before adding to the outbound queues. Internally it travels around with an internal-only header that identifies the sending user to allow us to choose which DKIM signatures to apply, then we sign on final injection into the outbound queue. I suspect other organisations do the same, and this is what DKIM was designed for. My understanding of ARC is that is not supposed to replace DKIM for this case. Anyway, we are conflating: 1) I need to sign this email which I didn't modify because the next hop wouldn't be able to verify that it was sent from an authorised source any more; with 2) I'm modifying this message and I am asserting that I believed it was from an authorised source and correctly signed before I modified it Right now AAR and AMS are exactly the same for those two cases. The problem is - advice on "when should I ARC-Seal" is really woolly, leading to a third case being conflated in here: 3) I'm not modifying this message or breaking its signature, I'm just adding my own signature as it passes through Case three is the real problem. By adding an AAR, AMS and AS in that case, you're adding crypto which is misleading. I will make my case below :) I use the following parties: d=gmail.com - a sender and eventual receiver. I could sub fastmail.com here just as easily, but "everyone" knows gmail, and they currently ARC- Seal all incoming email. d=mailinglist.com - a mailing list which modifies all email, and hence needs to apply ARC to every message for case (2) above. d=forwarder.com - a site that just forwards email without changing the message at all - something like pobox.com, our alias service. d=sketchy.com - another forwarder who isn't well known or trusted. Trust isn't transitive, gmail trusts mailinglist.com to validate signatures and to only apply clean transformations (change sender, add a footer) to any email it receives, but it doesn't trust sketchy.com at all. mailinglist.com on the other hand isn't sure about sketchy.com, but has no reason to consider it less trustworthy than other forwarders because it doesn't have a giant machine learning database to handle site reputation. Now let's consider the following message history. The mail is going to follow this path: gmail.com => sketchy.com => mailinglist.com => forwarder.com => gmail.com This seems somewhat contrived, but maybe sketchy.com is some university system where a club has set up an alias that goes to their mailing list, and one of the members is an alumnus using a separate university alumni system which forwards to their gmail account. That's not a totally unreasonable mail flow. Here's a message where sketchy.com just forwards the message, with no changes made: original message: DKIM-Signature: d=gmail.com (VALID) From: To: first hop: AS: i=1, d=sketchy.com, cv=none (VALID) AMS: i=1, d=sketchy.com (VALID) AAR: i=1, dkim=pass, spf=pass, arc=none DKIM-Signature: d=gmail.com (VALID) From: To: ENV-To: second hop: AS: i=2, d=mailinglist.com, cv=pass (VALID) AMS: i=2, d=mailinglist.com (VALID) AAR: i=2, dkim=pass, spf=fail, arc=pass AS: i=1, d=sketchy.com, cv=none (VALID) AMS: i=1, d=sketchy.com (INVALID) AAR: i=1, dkim=pass, spf=pass DKIM-Signature: d=gmail.com (INVALID) From: To: We see that both DKIM and i=1 AMS are now invalid, only the AS chain continues to validate. The DKIM still passed on arrival to mailinglist.com, because sketchy.com didn't actually modify the message, but won't pass again after this. third hop: AS: i=3, d=forwarder.com, cv=pass (VALID) AMS: i=3, d=forwarder.com (VALID) AAR: i=3, dkim=fail, spf=fail, arc=pass AS: i=2, d=mailinglist.com, cv=pass (VALID) AMS: i=2, d=mailinglist.com (VALID) AAR: i=2, dkim=pass, spf=fail, arc=pass AS: i=1, d=sketchy.com, cv=none (VALID) AMS: i=1, d=sketchy.com (INVALID) AAR: i=1, dkim=pass, spf=pass DKIM-Signature: d=gmail.com (INVALID) From: To: ENV-To: and finally gmail seal it on the way in: AS: i=4, d=gmail.com, cv=pass (VALID) AMS: i=4, d=gmail.com (VALID) AAR: i=4, dkim=fail, spf=fail, arc=pass AS: i=3, d=forwarder.com, cv=pass (VALID) AMS: i=3, d=forwarder.com (VALID) AAR: i=3, dkim=fail, spf=fail, arc=pass AS: i=2, d=mailinglist.com, cv=pass (VALID) AMS: i=2, d=mailinglist.com (VALID) AAR: i=2, dkim=pass, spf=fail, arc=pass AS: i=1, d=sketchy.com, cv=none (VALID) AMS: i=1, d=sketchy.com (INVALID) AAR: i=1, dkim=pass, spf=pass DKIM-Signature: d=gmail.com (INVALID) From: To: ENV-To: In here we have two things that are interesting: 1) the oldest AMS that still validates. Nothing was changed since then.2) the AAR with the same i= value (i=2) which shows that DKIM still passed then. So we can tell from these headers that the only place which modified the message was mailinglist.com. So far so good. Absent ANY value at all are the ARC headers with i=1, i=3 or i=4. They add no value. Likewise the ARC-Seal at i=2 only adds value because it signs the AAR at i=2. This is literally the only proof we have at this point that sketchy.com didn't completely rewrite the message. This same value could be obtained by having sketchy.com and forwarder.com and gmail's inbound do no ARC processing at all other than validating the AMS of mailinglist.com rather than the DKIM signature at forwarder.com and gmail.com inbound. The only way to know that sketchy.com didn't modify the message is because mailinglist.com's AAR said that dkim still passed at that time. But mailinglist.com could easily lie about that if it wanted to, the chain would still be unbroken. Further, ARC-Seal doesn't capture the really interesting bits - which are "what was the envelope at this point" or even "what was the date at this point" - meaning you can re-purpose old ARC-Seals for as long as you like if the selectors still exist, and they will continue to validate. OK, this has become pretty long and rambly, but here's the thing: *AS adds nothing over just having AMS signing its own AAR, and then you only have to verify ONE signature, the most recent.* Any site which lies about AAR and also modifies the message can just as easily file the serial numbers off an existing ARC chain, pretend it received the message from a point in that chain, and then mint a convincing AAR, a valid AMS and a valid AS which chains with the existing set of seals. The seals don't include any previous facts about the message other than the hashes in the lower i= AMS headers, and a single modification to message content will render them invalid. Short of a global registry of all known email mesages (in which case ARC is pointless), you can't tell if those ARC headers were lifted off another message and reused. You either trust the most recent signer and trust that THEY validated the previous signer/SPF (and so on) or the chain is broken anyway, so why add a parallel, easily falsified, chain of signatures? So since ARC-Seal doesn't add any value, and adds complexity and cost (in extra DNS lookups and crypto) and failure points (in potential DNS tempfails which break the chain even though the underlying crypto is sound and could be verified later) - it's a waste and, as I stated in the subject, snakeoil with no benefit. What is valuable is AMS and AAR, and along with that - advice to not add your own AMS unless you really have to. If you aren't breaking the existing signature, don't add your own, because it confuses provenance on the message. ARC would be a better standard if it removed AS entirely, and had AMS sign its own AAR (e.g. by adding another tag to the AMS header which is the hash of the associated AAR) A more cheap and nasty fix, assuming it's too late/complex to change the protocol more, would be to keep AS, but change the validation to only require checking the most recent AS, since validating the rest is meaningless. Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_150208328721912480 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
I thought long and hard about using a less inflammatory title, but I figure maybe going in hard is the right way here, because I'd rather fix this before it becomes a standard! (and thanks Dave for your thoughtful questions during the Prague DMARC session which prompted some of my thinking)

Unfortunately I didn't get a full chance to think about ARC and how it all functions before Prague, and then I hadn't fully internalised it by the DMARC session - I was still refactoring the code I wrote on the weekend and testing it some more, as well as getting the signing side done.  It took a few days to fully understand how all those signatures work together.  I had let others focus on ARC within our company rather than looking at it myself until now.

So my apologies for coming along late with this manifesto!  I've been trying to think of a more polite and diplomatic way to say it, but so far I haven't see anything to convince me that ARC-Seal is anything other than snake oil.  It's excessive crypto for no benefit, and with the way I've had it described to me and the way it's being used right now at least at Google (sealing every message on the way in), it adds confusion rather than clarity to message provenance.

Let me explain.  Starting with purpose.

ARC conflates two purposes:

a) providing a new signature when you change a message in ways that break its existing signature.

b) providing a signature where there is none, but SPF passed and you would have trusted the source email anyway.

Apparently "just DKIM sign everything" isn't viable due to key management problems and "sending on behalf of".  I'm willing to stipulate that, because we have to work with the reality of deployed systems with any new standard if it wants traction.

There is a third purpose that needs signatures:

c) new email received from trusted/internal host with no signature yet

This is generally handled by DKIM-signing the message before sending it outside an organisation's trusted infrastructure.  FastMail for example DKIM signs our outbound email during the final scan before adding to the outbound queues.  Internally it travels around with an internal-only header that identifies the sending user to allow us to choose which DKIM signatures to apply, then we sign on final injection into the outbound queue.  I suspect other organisations do the same, and this is what DKIM was designed for.  My understanding of ARC is that is not supposed to replace DKIM for this case.

Anyway, we are conflating:

1) I need to sign this email which I didn't modify because the next hop wouldn't be able to verify that it was sent from an authorised source any more; with

2) I'm modifying this message and I am asserting that I believed it was from an authorised source and correctly signed before I modified it

Right now AAR and AMS are exactly the same for those two cases.

The problem is - advice on "when should I ARC-Seal" is really woolly, leading to a third case being conflated in here:

3) I'm not modifying this message or breaking its signature, I'm just adding my own signature as it passes through

Case three is the real problem.  By adding an AAR, AMS and AS in that case, you're adding crypto which is misleading.  I will make my case below :)  I use the following parties:

d=gmail.com - a sender and eventual receiver.  I could sub fastmail.com here just as easily, but "everyone" knows gmail, and they currently ARC-Seal all incoming email.

d=mailinglist.com - a mailing list which modifies all email, and hence needs to apply ARC to every message for case (2) above.

d=forwarder.com - a site that just forwards email without changing the message at all - something like pobox.com, our alias service.

d=sketchy.com - another forwarder who isn't well known or trusted.

Trust isn't transitive, gmail trusts mailinglist.com to validate signatures and to only apply clean transformations (change sender, add a footer) to any email it receives, but it doesn't trust sketchy.com at all.  mailinglist.com on the other hand isn't sure about sketchy.com, but has no reason to consider it less trustworthy than other forwarders because it doesn't have a giant machine learning database to handle site reputation.

Now let's consider the following message history.  The mail is going to follow this path:

gmail.com => sketchy.com => mailinglist.com => forwarder.com => gmail.com

This seems somewhat contrived, but maybe sketchy.com is some university system where a club has set up an alias that goes to their mailing list, and one of the members is an alumnus using a separate university alumni system which forwards to their gmail account.  That's not a totally unreasonable mail flow.

Here's a message where sketchy.com just forwards the message, with no changes made:

original message:

DKIM-Signature: d=gmail.com (VALID)
From: <foo@gmail.com>
To: <list-name@sketchy.com>

first hop:

AS: i=1, d=sketchy.com, cv=none (VALID)
AMS: i=1, d=sketchy.com (VALID)
AAR: i=1, dkim=pass, spf=pass, arc=none
DKIM-Signature: d=gmail.com (VALID)
From: <foo@gmail.com>
To: <list-name@sketchy.com>
ENV-To: <name@mailinglist.com>

second hop:

AS: i=2, d=mailinglist.com, cv=pass (VALID)
AMS: i=2, d=mailinglist.com (VALID)
AAR: i=2, dkim=pass, spf=fail, arc=pass
AS: i=1, d=sketchy.com, cv=none (VALID)
AMS: i=1, d=sketchy.com (INVALID)
AAR: i=1, dkim=pass, spf=pass
DKIM-Signature: d=gmail.com (INVALID)
From: <name@mailinglist.com>
To: <alias@forwarder.com>

We see that both DKIM and i=1 AMS are now invalid, only the AS chain continues to validate.  The DKIM still passed on arrival to mailinglist.com, because sketchy.com didn't actually modify the message, but won't pass again after this.

third hop:

AS: i=3, d=forwarder.com, cv=pass (VALID)
AMS: i=3, d=forwarder.com (VALID)
AAR: i=3, dkim=fail, spf=fail, arc=pass
AS: i=2, d=mailinglist.com, cv=pass (VALID)
AMS: i=2, d=mailinglist.com (VALID)
AAR: i=2, dkim=pass, spf=fail, arc=pass
AS: i=1, d=sketchy.com, cv=none (VALID)
AMS: i=1, d=sketchy.com (INVALID)
AAR: i=1, dkim=pass, spf=pass
DKIM-Signature: d=gmail.com (INVALID)
From: <name@mailinglist.com>
To: <alias@forwarder.com>
ENV-To: <bar@gmail.com>

and finally gmail seal it on the way in:

AS: i=4, d=gmail.com, cv=pass (VALID)
AMS: i=4, d=gmail.com (VALID)
AAR: i=4, dkim=fail, spf=fail, arc=pass
AS: i=3, d=forwarder.com, cv=pass (VALID)
AMS: i=3, d=forwarder.com (VALID)
AAR: i=3, dkim=fail, spf=fail, arc=pass
AS: i=2, d=mailinglist.com, cv=pass (VALID)
AMS: i=2, d=mailinglist.com (VALID)
AAR: i=2, dkim=pass, spf=fail, arc=pass
AS: i=1, d=sketchy.com, cv=none (VALID)
AMS: i=1, d=sketchy.com (INVALID)
AAR: i=1, dkim=pass, spf=pass
DKIM-Signature: d=gmail.com (INVALID)
From: <name@mailinglist.com>
To: <alias@forwarder.com>
ENV-To: <bar@gmail.com>

In here we have two things that are interesting:

1) the oldest AMS that still validates.  Nothing was changed since then.
2) the AAR with the same i= value (i=2) which shows that DKIM still passed then.

So we can tell from these headers that the only place which modified the message was mailinglist.com.  So far so good.  Absent ANY value at all are the ARC headers with i=1, i=3 or i=4.  They add no value.  Likewise the ARC-Seal at i=2 only adds value because it signs the AAR at i=2.  This is literally the only proof we have at this point that sketchy.com didn't completely rewrite the message.  This same value could be obtained by having sketchy.com and forwarder.com and gmail's inbound do no ARC processing at all other than validating the AMS of mailinglist.com rather than the DKIM signature at forwarder.com and gmail.com inbound.

The only way to know that sketchy.com didn't modify the message is because mailinglist.com's AAR said that dkim still passed at that time.  But mailinglist.com could easily lie about that if it wanted to, the chain would still be unbroken.

Further, ARC-Seal doesn't capture the really interesting bits - which are "what was the envelope at this point" or even "what was the date at this point" - meaning you can re-purpose old ARC-Seals for as long as you like if the selectors still exist, and they will continue to validate.

OK, this has become pretty long and rambly, but here's the thing:

AS adds nothing over just having AMS signing its own AAR, and then you only have to verify ONE signature, the most recent.

Any site which lies about AAR and also modifies the message can just as easily file the serial numbers off an existing ARC chain, pretend it received the message from a point in that chain, and then mint a convincing AAR, a valid AMS and a valid AS which chains with the existing set of seals.  The seals don't include any previous facts about the message other than the hashes in the lower i= AMS headers, and a single modification to message content will render them invalid.  Short of a global registry of all known email mesages (in which case ARC is pointless), you can't tell if those ARC headers were lifted off another message and reused.

You either trust the most recent signer and trust that THEY validated the previous signer/SPF (and so on) or the chain is broken anyway, so why add a parallel, easily falsified, chain of signatures?

So since ARC-Seal doesn't add any value, and adds complexity and cost (in extra DNS lookups and crypto) and failure points (in potential DNS tempfails which break the chain even though the underlying crypto is sound and could be verified later) - it's a waste and, as I stated in the subject, snakeoil with no benefit.

What is valuable is AMS and AAR, and along with that - advice to not add your own AMS unless you really have to.  If you aren't breaking the existing signature, don't add your own, because it confuses provenance on the message.  ARC would be a better standard if it removed AS entirely, and had AMS sign its own AAR (e.g. by adding another tag to the AMS header which is the hash of the associated AAR)

A more cheap and nasty fix, assuming it's too late/complex to change the protocol more, would be to keep AS, but change the validation to only require checking the most recent AS, since validating the rest is meaningless.

Cheers,

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd


--_----------=_150208328721912480-- From nobody Mon Aug 7 07:51:58 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF281323B5 for ; Mon, 7 Aug 2017 07:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eudaemon.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMXcMU2qIJJW for ; Mon, 7 Aug 2017 07:51:55 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B15341323B2 for ; Mon, 7 Aug 2017 07:51:55 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id l82so4124658ywc.2 for ; Mon, 07 Aug 2017 07:51:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eudaemon.net; s=dkey; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=xuQw6SbwZxVxsqkKQvpKTgMNDI6lxyLjvKAyT9tvMzc=; b=Ybx0YjUr2jH/WNDNabH+qX8CJsSfC7luEPC5aA8wS794zwkN7RSFSV3DCDo1mZExYs w0cr8eXWnQP/lq/V6tPgCmmXicsOD+9/CuGPevaWxuZ0Wg0GkDE4H44qxhdSRigIWZZO mciO0LobXvsi3F5OOmfw8gn9JLQNv+j6b8ZDk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=xuQw6SbwZxVxsqkKQvpKTgMNDI6lxyLjvKAyT9tvMzc=; b=fVW9kFaQIKOM28m1CzGcht964mWJwuZMBPo5NHK01gSjSyG6lW0pAsSSIdEAeNzMpn S2sYo4N+q7tYf3FpumdlPLiQYJ6z7jdXUhkq8bQ56cBGMOOPcCRKG4LDAkjRU4wcy/fs TFRYlFqCLrJx3EmS8byNxTthO37uoPYqiXHZ4mfZUPDaPw87TO5+jW6cGe5wgoHU1Z17 JDee55eHYPuEozCpXfTjwhdQ3R0wwv2yZClSCXxhV6sth13WaR5RRukXKXVzG3k5FARa yScXl36sJcVszXyNkGZt6EEaAIY+wfb6BIo0IAiQ0JLzqlFHUPqnMarq+1SinthzjeAs F8wQ== X-Gm-Message-State: AHYfb5jdXMt5aypqz7q83Kaj3Fmc+y3sp682N0cnrUG5BF/Zj6h8FJDL kYrpsnp2BvuJ4JH1 X-Received: by 10.129.85.5 with SMTP id j5mr750947ywb.120.1502117514731; Mon, 07 Aug 2017 07:51:54 -0700 (PDT) Received: from [192.168.0.30] (208-104-133-98.brvd.dsl.dyn.comporium.net. [208.104.133.98]) by smtp.gmail.com with ESMTPSA id m6sm3004042ywb.67.2017.08.07.07.51.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Aug 2017 07:51:53 -0700 (PDT) From: Tim Draegen Message-Id: <15EF8F78-61CD-41B9-B7A2-317D483A56C1@eudaemon.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_43A2795B-EF2A-4F93-A478-62FF7BA996CF" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 7 Aug 2017 10:50:52 -0400 In-Reply-To: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> Cc: dmarc@ietf.org To: Bron Gondwana References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre 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 Aug 2017 14:51:57 -0000 --Apple-Mail=_43A2795B-EF2A-4F93-A478-62FF7BA996CF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Aug 7, 2017, at 1:21 AM, Bron Gondwana = wrote: >=20 > A more cheap and nasty fix, assuming it's too late/complex to change = the protocol more, would be to keep AS, but change the validation to = only require checking the most recent AS, since validating the rest is = meaningless. Bron, thanks for sharing your insight. I don't think it's too = late/complex to incorporate direct real world experience into the = specification. I tried to express my own attitude in the Prague meeting: the email = space is special because it is huge. It doesn't make sense to pretend = that it isn't. Instead, let's build tech to solve real problems, test it = against the install base, and make the tech better based on what is = learned. AFAICT, ARC is at the very beginning of the "test it against the install = base" phase. --Apple-Mail=_43A2795B-EF2A-4F93-A478-62FF7BA996CF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On = Aug 7, 2017, at 1:21 AM, Bron Gondwana <brong@fastmailteam.com> wrote:

A = more cheap and nasty fix, assuming it's too late/complex to change the = protocol more, would be to keep AS, but change the validation to only = require checking the most recent AS, since validating the rest is = meaningless.

Bron, = thanks for sharing your insight. I don't think it's too late/complex to = incorporate direct real world experience into the = specification.

I tried to express my = own attitude in the Prague meeting: the email space is special because = it is huge. It doesn't make sense to pretend that it isn't. Instead, = let's build tech to solve real problems, test it against the install = base, and make the tech better based on what is learned.

AFAICT, ARC is at the very beginning of the "test = it against the install base" phase.


= --Apple-Mail=_43A2795B-EF2A-4F93-A478-62FF7BA996CF-- From nobody Mon Aug 7 16:15:07 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB27129B25 for ; Mon, 7 Aug 2017 16:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=ZptgZzxd; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WxHYYyn2 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GaLH1gBiOt29 for ; Mon, 7 Aug 2017 16:15:04 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3A45128C9C for ; Mon, 7 Aug 2017 16:15:03 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 612CC20B36 for ; Mon, 7 Aug 2017 19:15:03 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Mon, 07 Aug 2017 19:15:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=ZXb4MsCnC5XQmtyTzznxZWBkAVr3dt9YbkDnkcZpz bI=; b=ZptgZzxdH+XFSYFNhuQ9RdII1b7JlKgjHZUt7sPzY1JJIWCAPfo6rvqmL vFZ9jrTwfRtODcg1KPwsyKCz8XAWNjb6dkAcbHDKmzWPseayux8BW3oU9T7LPAGL sISqX1z4KjchI7XJHbkxTBVfmK6xTeohVfpLYsnmYHsj0TqzsmqSNSQbyLIVuVbf xUaTqP3ZqMmjAQfPj7njXtYxE+Kr9AYK2eP1cVDcYM+wA+kO6o8QUbQS3o+5/UIS RuRbuZALLR/MRX8LIheMd1gEQbiw3KSVIporB/49KnyD1XerSAoLdiNJeKpTQ0Ws xV121I+P2FL2zDxO1XIsm+u7pmskA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=ZXb4MsCnC5XQmtyTzznxZWBkAVr3d t9YbkDnkcZpzbI=; b=WxHYYyn2NkRVrG09jCAsnekHa0J1QEQ/Wk6O85LhJ/1sG 5YfoO7AVSLjzqSd7d0Rv47VUPYogyl3tZer38cIH4vj/eVggzFujV+1IEcctAlmA Pej6r7L+zB9PTaK8EV47Rs1bhVv9z7fPj2RBQztgaEeICFZTROZBvd3zWfXZu9ZV oJJCPXIWP4YSYpbbS1cL6JF6iJU+0t96HUthcJG8Tp0lXW4iHL6CaheDoNXBwdKu rNmlaqwNniF8EgU2MTe3HbEBkG+PAxuIW4lxvE8sjroCQsTVJHU6R8OLI/JiOfvy Muhp42qQupdblNEtQa01rlzhIVCGkHFHTWRJy9trA== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 3C6DFBAB72; Mon, 7 Aug 2017 19:15:03 -0400 (EDT) Message-Id: <1502147703.2912496.1066193024.16846450@webmail.messagingengine.com> From: Bron Gondwana To: dmarc@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150214770329124961" X-Mailer: MessagingEngine.com Webmail Interface - ajax-7b2cde4a Date: Tue, 08 Aug 2017 09:15:03 +1000 Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre 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 Aug 2017 23:15:06 -0000 This is a multi-part message in MIME format. --_----------=_150214770329124961 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Tue, 8 Aug 2017, at 00:50, Tim Draegen wrote: >> On Aug 7, 2017, at 1:21 AM, Bron Gondwana >> wrote:>> >> A more cheap and nasty fix, assuming it's too late/complex to change >> the protocol more, would be to keep AS, but change the validation to >> only require checking the most recent AS, since validating the rest >> is meaningless.> > Bron, thanks for sharing your insight. I don't think it's too > late/complex to incorporate direct real world experience into the > specification.> > I tried to express my own attitude in the Prague meeting: the email > space is special because it is huge. It doesn't make sense to pretend > that it isn't. Instead, let's build tech to solve real problems, test > it against the install base, and make the tech better based on what is > learned.> > AFAICT, ARC is at the very beginning of the "test it against the > install base" phase. Thanks Tim, We'll set ARC up at FastMail and experiment with it for sure. The code is pretty much ready to slot into place, and while nobody is filtering on it, it's easy enough to play with. It's not like ARC is worse than nothing (apart from maybe the increased DNS load). Regardless of our opinion of how good it is, we'll certainly implement anything which helps our users' mail be delivered! But it would be nice to help make it even better if we get a chance to influence the technology choices :) Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_150214770329124961 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Tue, 8 Aug 2017, at 00:50, Tim Draegen wrote:
On Aug 7, 2017, at 1:21 AM, Bron Gondwana <brong@fastmailteam.com> wrote:

A more cheap and nasty fix, assuming it's too late/complex to change the protocol more, would be to keep AS, but change the validation to only require checking the most recent AS, since validating the rest is meaningless.

Bron, thanks for sharing your insight. I don't think it's too late/complex to incorporate direct real world experience into the specification.

I tried to express my own attitude in the Prague meeting: the email space is special because it is huge. It doesn't make sense to pretend that it isn't. Instead, let's build tech to solve real problems, test it against the install base, and make the tech better based on what is learned.

AFAICT, ARC is at the very beginning of the "test it against the install base" phase.

Thanks Tim,

We'll set ARC up at FastMail and experiment with it for sure.  The code is pretty much ready to slot into place, and while nobody is filtering on it, it's easy enough to play with.

It's not like ARC is worse than nothing (apart from maybe the increased DNS load).  Regardless of our opinion of how good it is, we'll certainly implement anything which helps our users' mail be delivered!  But it would be nice to help make it even better if we get a chance to influence the technology choices :)

Bron.


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


--_----------=_150214770329124961-- From nobody Mon Aug 7 16:22:43 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F23D4128C9C for ; Mon, 7 Aug 2017 16:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 ZeNY2wL-PJhG for ; Mon, 7 Aug 2017 16:22:37 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::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 72917129B25 for ; Mon, 7 Aug 2017 16:22:37 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id k43so8043893uaf.3 for ; Mon, 07 Aug 2017 16:22:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=hbYv9vUcxN4YC03927qY9BVU00gBB6uGT1RwenJEYxw=; b=LkTyxP33bZtuuXYbPT/iC5qLIIeL2TI998oduG0ASGFcSld78ribx55Og2gZv/xD10 IYaxW2ri9tPTeBj26VpqRPlmnoURUz7yQMLYXHRUeCfFwnshM4aYwG7XBDNhm1yl/6gQ Iwx3zWGJJ+sazxlQCqBH/C211b/TnmFPdPnxB267xlANlrDp45Rem2IZTPh3nO/J9XNg gcRY6dEcKoH9XuaZljwwApQnOCEw4F0xkTMhvVceq30CmMmW9rwu+P1x3u4wyBIigius Q5c2i3JhG+Px0Pk0JPNZ/Z9Il79Jz8rx8J/9/sB2+3qCJy3TCzPJv5zY+APumdzoV4Qh hHrQ== 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=hbYv9vUcxN4YC03927qY9BVU00gBB6uGT1RwenJEYxw=; b=SPczU6hBvfu+E/lbeiIZ3KhV85Amwnt2f/tbHTOgfMtab9bWrF/l3HZ/q75QvK6pL4 hQFfqoXLIVl12lBk5rrVGzp4IxGSa1B8ON8OCpqwMvvbodofRvHaSmPMoqU77wgraeH8 uUcdTLtd/vzlHqJZowhTLh3zZV/DqDSkSyf64K2cr3UYs8TAl2LHD5fGWJOaC98ECbaf 1syOmmwZvmRDDKTTOA4jbvyXeatso+34JJ+4FxPMB2SK7KhqZet/60JcN9h8q3K5+JGT 5nxm+5jU+t44jGaotyQDlQP2oiadFosEPkvQ5n8k/0XivsSC3JBTeAMJR3Ht7+6GbpT2 6NDw== X-Gm-Message-State: AHYfb5hY7RML8Pv0zmYLDMobhLO4bCqn8VFyRcVK4NyzipjIT+J7VmQ/ +VNFsHin3kuh4AMoEw1JaarTQc8i5pFU1Vcebw== X-Received: by 10.176.64.166 with SMTP id i35mr1618140uad.42.1502148156313; Mon, 07 Aug 2017 16:22:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.151.25 with HTTP; Mon, 7 Aug 2017 16:22:15 -0700 (PDT) In-Reply-To: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> From: Seth Blank Date: Mon, 7 Aug 2017 16:22:15 -0700 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1243b24243110556321f99" Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre 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 Aug 2017 23:22:41 -0000 --94eb2c1243b24243110556321f99 Content-Type: text/plain; charset="UTF-8" On Sun, Aug 6, 2017 at 10:21 PM, Bron Gondwana wrote: > > *AS adds nothing over just having AMS signing its own AAR, and then you > only have to verify ONE signature, the most recent.* > > > > You either trust the most recent signer and trust that THEY validated the > previous signer/SPF (and so on) or the chain is broken anyway, so why add a > parallel, easily falsified, chain of signatures? > There's a critical reason the ARC Seal exists that you're missing: ARC is about maintaining a chain of custody so that a final receiver can be certain of which domains modified a message in transit. Like DMARC, DKIM, and SPF, we're trying to ascertain if the message was handled by the domain it said it was handled by - we're not passing judgement on the contents of the messages itself. When validating an ARC signed message, one verifies the latest AMS (which must validate), and *the entire chain* of ARC Seals, not only the latest. This guarantees you a list of all message signatories - the chain of custody we're talking about. When evaluating the chain for final receipt, there are two states to worry about as a matter of local policy: 1) you trust all the signatories on the chain 2) there is an untrusted signatory on the chain In state #1, you're done - if you trust the signatories then you trust they're not playing games with the AMS and AAR contents or manipulating the message in malicious ways. Now you can make a delivery decision as local policy dictates. In state #2, you're also done - if you don't trust all the signatories, then there are a multitude of routes for the message to be garbage, including but not limited to everything you've outlined above. The critical thing about the ARC Seal is that it guarantees this behavior in state #1 - if you trust all the d= values in the ARC Seals, they all validate, and you have cv=pass, then you know for certain everyone who has manipulated the message (and maybe some who handled but did not modify). Without the ARC Seal this determination is not possible and there is no way to evaluate the ARC chain for delivery as a final receiver. Seth --94eb2c1243b24243110556321f99 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= un, Aug 6, 2017 at 10:21 PM, Bron Gondwana <brong@fastmailteam.com> wrote:
<= div style=3D"font-family:Arial">
AS adds nothing over just having AMS si= gning its own AAR, and then you only have to verify ONE signature, the most= recent.

<snip>

You either trust the most recent signer an= d trust that THEY validated the previous signer/SPF (and so on) or the chai= n is broken anyway, so why add a parallel, easily falsified, chain of signa= tures?

<= div>There's a critical reason the ARC Seal exists that you're missi= ng:

=

When validating an ARC signed message, one verifies the= latest AMS (which must validate), and *the entire chain* of ARC Seals, not= only the latest. This guarantees you a list of all message signatories - t= he chain of custody we're talking about.

When = evaluating the chain for final receipt, there are two states to worry about= as a matter of local policy:
1) you trust all the signatories on= the chain
2) there is an untrusted signatory on the chain
<= div>


<= div>The critical thing about the ARC Seal is that it guarantees this behavi= or in state #1 - if you trust all the d=3D values in the ARC Seals, they al= l validate, and you have cv=3Dpass, then you know for certain everyone who = has manipulated the message (and maybe some who handled but did not modify)= .



= --94eb2c1243b24243110556321f99-- From nobody Mon Aug 7 19:41:40 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22250124B18 for ; Mon, 7 Aug 2017 19:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxrq_P4h3kaf for ; Mon, 7 Aug 2017 19:41:36 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42F94126B71 for ; Mon, 7 Aug 2017 19:41:35 -0700 (PDT) Received: (qmail 24466 invoked from network); 8 Aug 2017 02:41:34 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 8 Aug 2017 02:41:34 -0000 Date: 8 Aug 2017 02:41:12 -0000 Message-ID: <20170808024112.5073.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org Cc: brong@fastmailteam.com In-Reply-To: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre 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, 08 Aug 2017 02:41:39 -0000 In article <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> you write: >I thought long and hard about using a less inflammatory title, but I >figure maybe going in hard is the right way here, because I'd rather >fix this before it becomes a standard! (and thanks Dave for your >thoughtful questions during the Prague DMARC session which prompted >some of my thinking) For the most part you're right, but there seem to be a few corner cases that make it worthwhile. Since it only makes sense to look at the ARC chain on mail that comes from senders that are generally reliable, I've asked why you don't just whitelist those senders and be done with it. The answer, at least at very large mail systems, is that a mailing list sends nice clean mail, but then it starts forwarding lots of spam. I've seen this on some of the ICANN lists where someone got his address book stolen that had both the lists and individuals' addresses, so we're now getting mail through the lists with faked addresses of a frequent participant. ARC passes along info from previous hops so the recipient can retroactively do filtering that the mailing list didn't. I personally don't expect to do that, but if Gmail says they will, I presume they will. R's, John From nobody Mon Aug 7 21:02:06 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76B27120727 for ; Mon, 7 Aug 2017 21:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=jUsjXY58; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=abrGaL29 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEW7JnCwc1jt for ; Mon, 7 Aug 2017 21:02:01 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 897EB1243F3 for ; Mon, 7 Aug 2017 21:02:01 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id D258D20A42 for ; Tue, 8 Aug 2017 00:02:00 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Tue, 08 Aug 2017 00:02:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=UGbE8lgsJgGjw3Jip wmO9sKhRXF6FKhJy5LrLVbFlHQ=; b=jUsjXY58YVnqkUrWF+LFGxjlg+FH7g3JK d7toZIISbF/BfnCRE/wzurnunRioq5lTws0RxDHewfjlk+QBGH0jV8bjBM0EcOuY EKrgTJR7DcS+O2zkXiNH61kJRFlh6rwcxAoD7fAnlRIAO4O2PfOHw/DPM/TXJ1Iy zseK2Bm0SmVbOmqSZRP2HuQFvfaAZz8JqTuzFJlBdTtaapgctN3QYd9ClUGhRoq7 NXCPTjiQVYcpgJkWzboilUGNmO5D5flQPlljITUp4reWSzFRzIEmuq78SqmIrGB6 n+iLjo98hG1+EKk5CiXX1EOWHRdi9HUPMCZOdUO3tOAxsTuhvPG9Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=UGbE8l gsJgGjw3JipwmO9sKhRXF6FKhJy5LrLVbFlHQ=; b=abrGaL29fmMt8ZpvVRtXG1 1izEjd+g3SJDy2/zhTjSkRONQsVfMztz1nmZ73k3BpfnoaP4vahIE8WhjXqi/ukA I5aGFGa9hU5E2yN/3czH+6uzXk1ZdEKg2bxexnf5m2rBqUDhM3rs3eeuC+rzmsDn dTUUNsECXKR7X6pMNmTp3oegwv89BWZ9dyn8oZJ/h8t9UYQoScfOQ9rZn2KeRLVA Xd5cUkli2jRc04zp/Uh6NRiXG7Oyblcm3vVLROy6DmvcFRAmD4Ubu4YQ02UFw32A XKCOvpqMuPae1FRWCy+cZLd71OUAK518R7HX7dnvpeLO7bjyXhwjRmjt+/XhKDkQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id A31E49E260; Tue, 8 Aug 2017 00:02:00 -0400 (EDT) Message-Id: <1502164920.4114743.1066377640.37EA2DB1@webmail.messagingengine.com> From: Bron Gondwana To: dmarc@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150216492041147433" X-Mailer: MessagingEngine.com Webmail Interface - ajax-7b2cde4a In-Reply-To: <15EF8F78-61CD-41B9-B7A2-317D483A56C1@eudaemon.net> References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <15EF8F78-61CD-41B9-B7A2-317D483A56C1@eudaemon.net> Date: Tue, 08 Aug 2017 14:02:00 +1000 Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre 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, 08 Aug 2017 04:02:03 -0000 This is a multi-part message in MIME format. --_----------=_150216492041147433 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Tue, 8 Aug 2017, at 00:50, Tim Draegen wrote: >> On Aug 7, 2017, at 1:21 AM, Bron Gondwana >> wrote:>> >> A more cheap and nasty fix, assuming it's too late/complex to change >> the protocol more, would be to keep AS, but change the validation to >> only require checking the most recent AS, since validating the rest >> is meaningless.> > Bron, thanks for sharing your insight. I don't think it's too > late/complex to incorporate direct real world experience into the > specification.> > I tried to express my own attitude in the Prague meeting: the email > space is special because it is huge. It doesn't make sense to pretend > that it isn't. Instead, let's build tech to solve real problems, test > it against the install base, and make the tech better based on what is > learned.> > AFAICT, ARC is at the very beginning of the "test it against the > install base" phase. Thanks Tim, We'll set ARC up at FastMail and experiment with it for sure. The code is pretty much ready to slot into place, and while nobody is filtering on it, it's easy enough to play with. It's not like ARC is worse than nothing (apart from maybe the increased DNS load). Regardless of our opinion of how good it is, we'll certainly implement anything which helps our users' mail be delivered! But it would be nice to help make it even better if we get a chance to influence the technology choices :) Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_150216492041147433 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Tue, 8 Aug 2017, at 00:50, Tim Draegen wrote:

A more cheap and nasty fix, assuming it's too late/complex to change the protocol more, would be to keep AS, but change the validation to only require checking the most recent AS, since validating the rest is meaningless.

Bron, thanks for sharing your insight. I don't think it's too late/complex to incorporate direct real world experience into the specification.

I tried to express my own attitude in the Prague meeting: the email space is special because it is huge. It doesn't make sense to pretend that it isn't. Instead, let's build tech to solve real problems, test it against the install base, and make the tech better based on what is learned.

AFAICT, ARC is at the very beginning of the "test it against the install base" phase.

Thanks Tim,

We'll set ARC up at FastMail and experiment with it for sure.  The code is pretty much ready to slot into place, and while nobody is filtering on it, it's easy enough to play with.

It's not like ARC is worse than nothing (apart from maybe the increased DNS load).  Regardless of our opinion of how good it is, we'll certainly implement anything which helps our users' mail be delivered!  But it would be nice to help make it even better if we get a chance to influence the technology choices :)

Bron.


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


--_----------=_150216492041147433-- From nobody Mon Aug 7 21:11:00 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8038120727 for ; Mon, 7 Aug 2017 21:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=WvdwqYXv; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nHpUcp7y Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8ifX3dATLjJ for ; Mon, 7 Aug 2017 21:10:55 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC5C8120721 for ; Mon, 7 Aug 2017 21:10:55 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 2FD3F2095B for ; Tue, 8 Aug 2017 00:10:55 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Tue, 08 Aug 2017 00:10:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=I+xlOYsIVZq4ur/yd toDTpXXwnrg0j4Otn0jTnxlqi0=; b=WvdwqYXvlqhhBxTZ9LUzFPswHHVK5cZH7 EQj3v8pIxxCaF3HUfhLQrv2oWPSZxUKVmDvOE1XFWjuFIQzpxuxjI0wwLfXRhRq/ r0cwxvJOJCX7Ld4iQ9Thn+bylqPSSSIEP0xQOe80ZXtIMu2kE2R1WFMg0cxJMFTU LD/03C2gR8Fifz3N7UvAcal4rGP2JwvGJoP5oYk3xR0C0BqHp3VPIRZjbAM8kJLt BcoTucGuwQbF+6Bz0YbBXTC89T9DTfbJrBkLy8OEmEZCOr56R6QBu/b7cH+S8HBy 8o25fpCfTKSbKrxDcoWu2BGw7n8emspuPP8wMYlM7Mr9jhrMZ5qCg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=I+xlOY sIVZq4ur/ydtoDTpXXwnrg0j4Otn0jTnxlqi0=; b=nHpUcp7ywauivHNayFV0l2 8mCpmaXRcK71EO90cEZr+Q5ReifFYPaIGVcumfojQGt6PF3VQZDzF6WCO43WBzJ7 KQhhEOaeCmBZBPsfshBOF1j4TFUWrn8r2qVWnsNNECmf2Lr2mnoIufq2CAbBBChP U5EzOqQZwtYP0BFq1ZWQJPJy1JAYAQzp37NuDWUZ54l1qAVkEXEehh1FHkgStdBn Er4EhXJqCXRJxWpQrsSbG5zUkALMqD7mZYGjbbYpCc50mIc/wtczk4kFMFqPUCr1 /JwaWNsCtqKoEhLbSSl486Unmu/DTquJk2DaWwCyo1qez0QjVMrz5OOQvr2lzL7A == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 06EF59E24F; Tue, 8 Aug 2017 00:10:54 -0400 (EDT) Message-Id: <1502165454.4116080.1066378520.2314FE46@webmail.messagingengine.com> From: Bron Gondwana To: dmarc@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150216545441160800" X-Mailer: MessagingEngine.com Webmail Interface - ajax-7b2cde4a Date: Tue, 08 Aug 2017 14:10:54 +1000 References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> In-Reply-To: Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre 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, 08 Aug 2017 04:10:58 -0000 This is a multi-part message in MIME format. --_----------=_150216545441160800 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Tue, 8 Aug 2017, at 09:22, Seth Blank wrote: > On Sun, Aug 6, 2017 at 10:21 PM, Bron Gondwana > wrote:>> *AS adds nothing over just having AMS signing its own AAR, and then >> you only have to verify ONE signature, the most recent.*>> >> >> >> You either trust the most recent signer and trust that THEY validated >> the previous signer/SPF (and so on) or the chain is broken anyway, so >> why add a parallel, easily falsified, chain of signatures?> > There's a critical reason the ARC Seal exists that you're missing: I'm not missing it, I'm saying it doesn't work. > ARC is about maintaining a chain of custody so that a final receiver > can be certain of which domains modified a message in transit. Like > DMARC, DKIM, and SPF, we're trying to ascertain if the message was > handled by the domain it said it was handled by - we're not passing > judgement on the contents of the messages itself. Yeah, I believed that was true until I thought about the crypto. Except we don't know that the message was handled by a domain it says it was handled by. We only know that _A_ message was handled by the domain it says it was handled by. That could be any message. > When validating an ARC signed message, one verifies the latest AMS > (which must validate), and *the entire chain* of ARC Seals, not only > the latest. This guarantees you a list of all message signatories - > the chain of custody we're talking about. Except it doesn't, because all the AS before the first liar could have been grabbed from a different message and you can't tell. > When evaluating the chain for final receipt, there are two states to > worry about as a matter of local policy:> 1) you trust all the signatories on the chain > 2) there is an untrusted signatory on the chain > > In state #1, you're done - if you trust the signatories then you trust > they're not playing games with the AMS and AAR contents or > manipulating the message in malicious ways. Now you can make a > delivery decision as local policy dictates.> > In state #2, you're also done - if you don't trust all the > signatories, then there are a multitude of routes for the message > to be garbage, including but not limited to everything you've > outlined above.> > The critical thing about the ARC Seal is that it guarantees this > behavior in state #1 - if you trust all the d= values in the ARC > Seals, they all validate, and you have cv=pass, then you know for > certain everyone who has manipulated the message (and maybe some who > handled but did not modify).> > Without the ARC Seal this determination is not possible and there is > no way to evaluate the ARC chain for delivery as a final receiver. Sure there is. In case #1, you can check who signed each AMS and check that each of them had an associated AAR in which they validated the previous AMS. No chain required. In fact, you can just check the most recent AMS, because you know they checked the previous one. You trust them to have done the checks they claim to have done. AS just adds theatre. I'm not sure if there's a point to me proving this by forging a message with an AS of a site that it never went through. If you aren't willing to agree that the most recent liar can repurpose an existing chain, I'm happy to avoid making the forgery, otherwise I'll make up a forgery and send it to the list. But since you either trust every hop to do good checks, or you don't trust the entire message - then the ARC-Seal is literally adding nothing. It adds no meaning, just extra work. Hence my snakeoil claim. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_150216545441160800 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Tue, 8 Aug 2017, at 09:22, Seth Blank wrote:
On Sun, Aug 6, 2017 at 10:21 PM, Bron Gondwana <brong@fastmailteam.com> wrote:
AS adds nothing over just having AMS signing its own AAR, and then you only have to verify ONE signature, the most recent.

<snip>

You either trust the most recent signer and trust that THEY validated the previous signer/SPF (and so on) or the chain is broken anyway, so why add a parallel, easily falsified, chain of signatures?

There's a critical reason the ARC Seal exists that you're missing:

I'm not missing it, I'm saying it doesn't work.

ARC is about maintaining a chain of custody so that a final receiver can be certain of which domains modified a message in transit. Like DMARC, DKIM, and SPF, we're trying to ascertain if the message was handled by the domain it said it was handled by - we're not passing judgement on the contents of the messages itself.

Yeah, I believed that was true until I thought about the crypto.  Except we don't know that the message was handled by a domain it says it was handled by.  We only know that _A_ message was handled by the domain it says it was handled by.  That could be any message.

When validating an ARC signed message, one verifies the latest AMS (which must validate), and *the entire chain* of ARC Seals, not only the latest. This guarantees you a list of all message signatories - the chain of custody we're talking about.

Except it doesn't, because all the AS before the first liar could have been grabbed from a different message and you can't tell.

When evaluating the chain for final receipt, there are two states to worry about as a matter of local policy:
1) you trust all the signatories on the chain
2) there is an untrusted signatory on the chain

In state #1, you're done - if you trust the signatories then you trust they're not playing games with the AMS and AAR contents or manipulating the message in malicious ways. Now you can make a delivery decision as local policy dictates.

In state #2, you're also done - if you don't trust all the signatories, then there are a multitude of routes for the message to be garbage, including but not limited to everything you've outlined above.

The critical thing about the ARC Seal is that it guarantees this behavior in state #1 - if you trust all the d= values in the ARC Seals, they all validate, and you have cv=pass, then you know for certain everyone who has manipulated the message (and maybe some who handled but did not modify).

Without the ARC Seal this determination is not possible and there is no way to evaluate the ARC chain for delivery as a final receiver.

Sure there is.  In case #1, you can check who signed each AMS and check that each of them had an associated AAR in which they validated the previous AMS.  No chain required.  In fact, you can just check the most recent AMS, because you know they checked the previous one.  You trust them to have done the checks they claim to have done.

AS just adds theatre.

I'm not sure if there's a point to me proving this by forging a message with an AS of a site that it never went through.  If you aren't willing to agree that the most recent liar can repurpose an existing chain, I'm happy to avoid making the forgery, otherwise I'll make up a forgery and send it to the list.

But since you either trust every hop to do good checks, or you don't trust the entire message - then the ARC-Seal is literally adding nothing.  It adds no meaning, just extra work.  Hence my snakeoil claim.

Bron.

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


--_----------=_150216545441160800-- From nobody Tue Aug 8 06:36:24 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 376B0132393 for ; Tue, 8 Aug 2017 06:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yi57w7CK9hzx for ; Tue, 8 Aug 2017 06:36:18 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18281132378 for ; Tue, 8 Aug 2017 06:36:04 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id g189so13193245vke.5 for ; Tue, 08 Aug 2017 06:36:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=mNU4/dWSaaIxsxXgQ5JnVfCl2cOY+E/VJF+RPUTIFpI=; b=Xz+tWiHRzlLWSIYyRnJZHhvW5rijkC4E3nNcVC2aofn9ZLc4EOjaV1FoVnYscl0dCG bqyTXdAhG7ptZ9VsNvcIrpgmn3ryiNN8n8IXv7CGUthn2nz5oeS9YCFW44bCSYN0GmQ1 x5LrFvz0JBenZy14YnWKiAP9WngVsGCjNs/UU= 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=mNU4/dWSaaIxsxXgQ5JnVfCl2cOY+E/VJF+RPUTIFpI=; b=RWg0syp7LDPoztOYBXi4WMA1JqFwm94uzOwFGoKuhVAUM+LeB670ss8Ut4xgOLcMSE KxUfvX3yjtYwJn499xw0SMZVGJkz564ScQUxoyh2funywC9L1o3qv40XvDvsfrXFBOOD 5yw5mTGIrKqk8dRROCpQaQxX3IyOLsnRTKPwS1otAxcMHncXZzUQnvAlm+ZT0oczGgUq S/dEtH523anI6ZNMy2PkAKFTl+lrVe+OLwA4RmaeJ+qeLXd/mbpC3yIrxawxcP7NEP7h 1AgskBvXRrbU72ZDVSgzGiUcNGFZGtGKw1FAIux27HHEEltUyWN7nvjAr/9Eay0TUYGc sHCg== X-Gm-Message-State: AHYfb5gokpJY0Ei6nOfNOgc2GQ/JoG7gcD1kI1aQXcVJaLQ7nA6OevvP yA+QJ0gDHfCfVNXPjcYISKjCuLWBnrMwp2w= X-Received: by 10.31.93.6 with SMTP id r6mr2295155vkb.99.1502199363004; Tue, 08 Aug 2017 06:36:03 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.176.26.19 with HTTP; Tue, 8 Aug 2017 06:36:02 -0700 (PDT) In-Reply-To: <1502165454.4116080.1066378520.2314FE46@webmail.messagingengine.com> References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502165454.4116080.1066378520.2314FE46@webmail.messagingengine.com> From: "Kurt Andersen (b)" Date: Tue, 8 Aug 2017 06:36:02 -0700 X-Google-Sender-Auth: naCi6bukanXcqQBmAM7pKFUZ8qw Message-ID: To: Bron Gondwana Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c09198a6a0d3905563e0bc8" Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre 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, 08 Aug 2017 13:36:22 -0000 --94eb2c09198a6a0d3905563e0bc8 Content-Type: text/plain; charset="UTF-8" On Mon, Aug 7, 2017 at 9:10 PM, Bron Gondwana wrote: > . . . If you aren't willing to agree that the most recent liar can > repurpose an existing chain, I'm happy to avoid making the forgery, > otherwise I'll make up a forgery and send it to the list. > > But since you either trust every hop to do good checks, or you don't trust > the entire message - then the ARC-Seal is literally adding nothing. It > adds no meaning, just extra work. Hence my snakeoil claim. > Is your concern that the last hop (or any other) can essentially do a wholesale replacement of the message contents and that there is no way to distinguish that from a semantically meaningless footer tweak? I'm not sure that I understand your assertion that you can forge an AS any more than you could forge a DKIM signature. --Kurt --94eb2c09198a6a0d3905563e0bc8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Aug 7, 2017 at 9:10 PM, Bron Gondwana <brong@fastmailteam.com= > wrote:
. . .=C2=A0 If you a= ren't willing to agree that the most recent liar can repurpose an exist= ing chain, I'm happy to avoid making the forgery, otherwise I'll ma= ke up a forgery and send it to the list.

But since you either trust every hop to do= good checks, or you don't trust the entire message - then the ARC-Seal= is literally adding nothing.=C2=A0 It adds no meaning, just extra work.=C2= =A0 Hence my snakeoil claim.

=
Is your concern that the last hop (or any = other) can essentially do a wholesale replacement of the message contents a= nd that there is no way to distinguish that from a semantically meaningless= footer tweak?

I'm not sure that I understand your assertion that you can for= ge an AS any more than you could forge a DKIM signature.

--Kurt
--94eb2c09198a6a0d3905563e0bc8-- From nobody Tue Aug 8 06:59:23 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3077F132427 for ; Tue, 8 Aug 2017 06:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=EzFMS9cR; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=TnJ3+b2R Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id daUZ-V5e4PbB for ; Tue, 8 Aug 2017 06:59:20 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D73E132426 for ; Tue, 8 Aug 2017 06:59:20 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id B642820BAA; Tue, 8 Aug 2017 09:59:19 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Tue, 08 Aug 2017 09:59:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=xCtlI5 lPxh2CAPOLVpvqGTLMeK2G9Yx4Er0/iBGsauk=; b=EzFMS9cRVbNXKmloFkg7wX ZsISh2tHPgNkFSdzr4RN7KzI5eQBE+KscEvS9krchejg0q51SvsMAlj+MT9dpiIV xZ1ZyaP5Dlgej1H/UZhx9bZIQ8vmKM5xdj1GrXI90fNaXxhkZ/q/Pn/2mdVAZJPq TPFhO0y2RmopmJejxVe8difjaiFCyxpYAnuO2LzB9WdgKdI7t1A+OvnjoLMDip53 RdSpetIj8dEA5pzwzVQRXP9vIQXD9879bgX+46S04e8p6hP34dpDwkO7iGYBgYOb i7HQOEHoRRlySBsdCiiFnW5jyhWBYcq9eNUdqIFOAzoPJ4XVb+IvYyrVKReO5ZCg == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=xCtlI5 lPxh2CAPOLVpvqGTLMeK2G9Yx4Er0/iBGsauk=; b=TnJ3+b2RoxjjNPl/QbMvTh NMRma8kBBQgpTS/t4IkVkTjokCcFDVOQ5kEBSjCXiE2wnc1yv2CkfI5s+BTJrWF3 ND075ZWvi0SZ9W6/7vosKDMe5embrIEy5TZPC4Dt0bXvUwvBYhQEo/DYuiSWuwfO 1/Tmbu+tUP5BX0PXYzB2WxEj7bIMSowh58iVD/T3KvFvXEDPXAOgoCIcKQbbvc0l IKaFFzKudRh9eOyh+PhysmldP1VQVTFnsC/QuFu197ni04+O8hripALxWt9PEs/v Nium3AIFUmrLdOoK7xV9dWRMPiKeIZ2Tepttz3GWH16nP2h0RDJfvbZk3azr/9Xw == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 9545DBAB72; Tue, 8 Aug 2017 09:59:19 -0400 (EDT) Message-Id: <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> From: Bron Gondwana To: "Kurt Andersen (b)" Cc: dmarc@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150220075939466861" X-Mailer: MessagingEngine.com Webmail Interface - ajax-4448c6f4 Date: Tue, 08 Aug 2017 23:59:19 +1000 References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502165454.4116080.1066378520.2314FE46@webmail.messagingengine.com> In-Reply-To: Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre 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, 08 Aug 2017 13:59:22 -0000 This is a multi-part message in MIME format. --_----------=_150220075939466861 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Tue, 8 Aug 2017, at 23:36, Kurt Andersen (b) wrote: > On Mon, Aug 7, 2017 at 9:10 PM, Bron Gondwana > wrote:>> __ >> >> . . . If you aren't willing to agree that the most recent liar can >> repurpose an existing chain, I'm happy to avoid making the forgery, >> otherwise I'll make up a forgery and send it to the list.>> >> >> But since you either trust every hop to do good checks, or you >> don't trust the entire message - then the ARC-Seal is literally >> adding nothing. It adds no meaning, just extra work. Hence my >> snakeoil claim.>> >> >> > Is your concern that the last hop (or any other) can essentially do a > wholesale replacement of the message contents and that there is no way > to distinguish that from a semantically meaningless footer tweak?> > I'm not sure that I understand your assertion that you can forge an AS > any more than you could forge a DKIM signature. The whole point of verifying the chain of AS all the way back to i=1 is that you can tell that the message went through those servers, in that order. But it's bogus, because AS doesn't sign anything except itself and some AMS and AAR. Once AMS doesn't validate any more (any change at all) then you can't really tell that the message passed through there, just the _a_ message passed through there. So I could take an existing message that had passed through Google and create a brand new message and pass it off as if it had passed through Google before passing through my server on its way to you. In which case - the AS is meaningless. It claims something which is only true if everyone plays by the rules. But if everyone plays by the rules, then it's excessive. You could just check the previous AAR and know that the previous site had validated the hop before it, and so on. It's crypto that doesn't add anything of value. It's not actively damaging (other than the advice to do excessive DNS lookups), but it's also not doing anything meaningful, and it's adding something forgeable that looks like it means something. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_150220075939466861 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Tue, 8 Aug 2017, at 23:36, Kurt Andersen (b) wrote:
On Mon, Aug 7, 2017 at 9:10 PM, Bron Gondwana <brong@fastmailteam.com> wrote:


. . .  If you aren't willing to agree that the most recent liar can repurpose an existing chain, I'm happy to avoid making the forgery, otherwise I'll make up a forgery and send it to the list.


But since you either trust every hop to do good checks, or you don't trust the entire message - then the ARC-Seal is literally adding nothing.  It adds no meaning, just extra work.  Hence my snakeoil claim.



Is your concern that the last hop (or any other) can essentially do a wholesale replacement of the message contents and that there is no way to distinguish that from a semantically meaningless footer tweak?

I'm not sure that I understand your assertion that you can forge an AS any more than you could forge a DKIM signature.

The whole point of verifying the chain of AS all the way back to i=1 is that you can tell that the message went through those servers, in that order.

But it's bogus, because AS doesn't sign anything except itself and some AMS and AAR.  Once AMS doesn't validate any more (any change at all) then you can't really tell that the message passed through there, just the _a_ message passed through there.

So I could take an existing message that had passed through Google and create a brand new message and pass it off as if it had passed through Google before passing through my server on its way to you.

In which case - the AS is meaningless.  It claims something which is only true if everyone plays by the rules.  But if everyone plays by the rules, then it's excessive.  You could just check the previous AAR and know that the previous site had validated the hop before it, and so on.  It's crypto that doesn't add anything of value.

It's not actively damaging (other than the advice to do excessive DNS lookups), but it's also not doing anything meaningful, and it's adding something forgeable that looks like it means something.

Bron.

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


--_----------=_150220075939466861-- From nobody Tue Aug 8 07:28:18 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E35DF132337 for ; Tue, 8 Aug 2017 07:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNCxae71wkit for ; Tue, 8 Aug 2017 07:28:15 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32FE213232F for ; Tue, 8 Aug 2017 07:28:15 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 2E415C403DE for ; Tue, 8 Aug 2017 09:28:13 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1502202493; bh=f7HUM/4fqdDSgCPyYZF4UC0Jc5k5/GGVKXYI3QfJR/8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=A4ZdPklPKbgZXq7gBZhQvUxFtiGDdOstt8JqX81tBlgWfzUBNfRP+5TUsDaOkk9lX wM3Jh/vjfyt17KBhMmW+SFOopiI+HoDEQCOnPcUIKCpl0mpvdYdbtNceVEJnXoS9IX AvJL1I0hzCWDY3kigywTASAe3OCOZ/lhqAnCBRMI= From: Scott Kitterman To: dmarc@ietf.org Date: Tue, 08 Aug 2017 10:28:12 -0400 Message-ID: <2720431.u3G7bbkkxK@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-125-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre 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, 08 Aug 2017 14:28:17 -0000 On Tuesday, August 08, 2017 11:59:19 PM Bron Gondwana wrote: > On Tue, 8 Aug 2017, at 23:36, Kurt Andersen (b) wrote: > > On Mon, Aug 7, 2017 at 9:10 PM, Bron Gondwana > > wrote:>> __ > > > >> . . . If you aren't willing to agree that the most recent liar can > >> > >> repurpose an existing chain, I'm happy to avoid making the forgery, > >> otherwise I'll make up a forgery and send it to the list.>> > >> > >> But since you either trust every hop to do good checks, or you > >> don't trust the entire message - then the ARC-Seal is literally > >> adding nothing. It adds no meaning, just extra work. Hence my > >> snakeoil claim.>> > > > > Is your concern that the last hop (or any other) can essentially do a > > wholesale replacement of the message contents and that there is no way > > to distinguish that from a semantically meaningless footer tweak?> > > I'm not sure that I understand your assertion that you can forge an AS > > any more than you could forge a DKIM signature. > > The whole point of verifying the chain of AS all the way back to i=1 > is that you can tell that the message went through those servers, in > that order. > But it's bogus, because AS doesn't sign anything except itself and some > AMS and AAR. Once AMS doesn't validate any more (any change at all) > then you can't really tell that the message passed through there, just > the _a_ message passed through there. > So I could take an existing message that had passed through Google and > create a brand new message and pass it off as if it had passed through > Google before passing through my server on its way to you. > In which case - the AS is meaningless. It claims something which is > only true if everyone plays by the rules. But if everyone plays by the > rules, then it's excessive. You could just check the previous AAR and > know that the previous site had validated the hop before it, and so on. > It's crypto that doesn't add anything of value. > It's not actively damaging (other than the advice to do excessive DNS > lookups), but it's also not doing anything meaningful, and it's adding > something forgeable that looks like it means something. > Bron. I think the "Once AMS doesn't validate anymore ..." argument is an suggestion that it's fragile, not that it's pointless. I have concerns myself about the robustness of this design, but I think that's best addressed through deployment and experimentation. The fail case isn't very interesting. If it doesn't validate it, ignore it. I'm not sure yet what exactly the pass case buys, but I'm not convinced it's nothing. Scott K From nobody Tue Aug 8 07:58:00 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 533B013259A for ; Tue, 8 Aug 2017 07:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUwciU-XFULa for ; Tue, 8 Aug 2017 07:57:57 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.31]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62339132440 for ; Tue, 8 Aug 2017 07:57:57 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES533.agna.amgreetings.com ([::1]) with mapi id 14.03.0266.001; Tue, 8 Aug 2017 10:57:56 -0400 From: "MH Michael Hammer (5304)" To: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] ARC-Seal is meaningless security theatre Thread-Index: AQHTDz0MukjK9j/op0uQZ5fX3X6NFKJ5zJaAgABQpgCAAJ3lAIAABoGAgAAIEgD//8QusA== Date: Tue, 8 Aug 2017 14:57:55 +0000 Message-ID: References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> In-Reply-To: <2720431.u3G7bbkkxK@kitterma-e6430> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.6.169] x-kse-attachmentfiltering-interceptor-info: protection disabled x-kse-serverinfo: USCLES533.agna.amgreetings.com, 9 x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean, bases: 8/8/2017 10:40:00 AM x-kse-dlp-scaninfo: Skipped Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre 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, 08 Aug 2017 14:57:59 -0000 > -----Original Message----- > From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Scott Kitterman > Sent: Tuesday, August 08, 2017 10:28 AM > To: dmarc@ietf.org > Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre >=20 > On Tuesday, August 08, 2017 11:59:19 PM Bron Gondwana wrote: > > On Tue, 8 Aug 2017, at 23:36, Kurt Andersen (b) wrote: > > > On Mon, Aug 7, 2017 at 9:10 PM, Bron Gondwana > > > wrote:>> __ > > > > > >> . . . If you aren't willing to agree that the most recent liar can > > >> > > >> repurpose an existing chain, I'm happy to avoid making the forgery= , > > >> otherwise I'll make up a forgery and send it to the list.>> > > >> > > >> But since you either trust every hop to do good checks, or you > > >> don't trust the entire message - then the ARC-Seal is literally > > >> adding nothing. It adds no meaning, just extra work. Hence my > > >> snakeoil claim.>> > > > > > > Is your concern that the last hop (or any other) can essentially do > > > a wholesale replacement of the message contents and that there is no > > > way to distinguish that from a semantically meaningless footer > > > tweak?> I'm not sure that I understand your assertion that you can > > > forge an AS any more than you could forge a DKIM signature. > > > > The whole point of verifying the chain of AS all the way back to i=3D1 > > is that you can tell that the message went through those servers, in > > that order. > > But it's bogus, because AS doesn't sign anything except itself and > > some AMS and AAR. Once AMS doesn't validate any more (any change at > > all) then you can't really tell that the message passed through there, > > just the _a_ message passed through there. > > So I could take an existing message that had passed through Google and > > create a brand new message and pass it off as if it had passed through > > Google before passing through my server on its way to you. > > In which case - the AS is meaningless. It claims something which is > > only true if everyone plays by the rules. But if everyone plays by > > the rules, then it's excessive. You could just check the previous AAR > > and know that the previous site had validated the hop before it, and so= on. > > It's crypto that doesn't add anything of value. > > It's not actively damaging (other than the advice to do excessive DNS > > lookups), but it's also not doing anything meaningful, and it's adding > > something forgeable that looks like it means something. > > Bron. >=20 > I think the "Once AMS doesn't validate anymore ..." argument is an > suggestion that it's fragile, not that it's pointless. I have concerns m= yself > about the robustness of this design, but I think that's best addressed th= rough > deployment and experimentation. >=20 > The fail case isn't very interesting. If it doesn't validate it, ignore = it. >=20 > I'm not sure yet what exactly the pass case buys, but I'm not convinced i= t's > nothing. >=20 > Scott K >=20 I think the other thing that needs to be remembered is that DMARC, and subs= equently ARC, is a request to the mailbox provider/validator. ARC is presum= ably used as an input for local policy in consideration of overriding DMARC= failures. The fact that ARC validation is successful at the mailbox provid= er is ultimately a matter of local policy and presumably some sort of reput= ation schema.=20 Mike From nobody Tue Aug 8 17:16:42 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A5113219D for ; Tue, 8 Aug 2017 17:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=kTDYSzQH; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=iLDHYxjz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VI7y2r3gfr9 for ; Tue, 8 Aug 2017 17:16:37 -0700 (PDT) Received: from ntbbs.winserver.com (dkim.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB901320CC for ; Tue, 8 Aug 2017 17:16:36 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4865; t=1502237792; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=rJ/h1tFuR7PI63TUNGieXXJZtdI=; b=kTDYSzQHgbrezvq8HoTYC6HOwNfkm5277L7uQQTO4KBsHl6V1+/JZUJqkR0Pip viome+gPg/2ZTABwCyCIjIX/bC9U2//+HjBC7uP2I2ddyMHiieTHcuXI8Gn9neW+ I1DODj/GRbMVLwSb5cliiKxwxxUT3ILWOPpfV/JnPmqOY= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Tue, 08 Aug 2017 20:16:32 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 2301655279.1.1096; Tue, 08 Aug 2017 20:16:31 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4865; t=1502237768; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=Lzd/8O8 H8mAlMH2NkjPTfxzdLoPfsSvqUvjyHV5c+YE=; b=iLDHYxjziDd/lk0rC78P/IU Ie89VgZQdBpPQ7lr7gnDX7l8zI5MauUQLMeK8KiAe1EUarxkmYzIe9kLmg1BnrDE 5TQWz1ja+2Z8fmP1HSYECQYdGW7V7h3iZD7XmHDNlwNXI7LQ2XEtJYi5VjNknKaf qVsKmooOY4SDnuK2dQqU= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Tue, 08 Aug 2017 20:16:08 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 2844165408.9.270892; Tue, 08 Aug 2017 20:16:07 -0400 Message-ID: <598A545E.3080708@isdg.net> Date: Tue, 08 Aug 2017 20:16:30 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502165454.4116080.1066378520.2314FE46@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> In-Reply-To: <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre 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, 09 Aug 2017 00:16:40 -0000 On 8/8/2017 9:59 AM, Bron Gondwana wrote: > On Tue, 8 Aug 2017, at 23:36, Kurt Andersen (b) wrote: >> >> Is your concern that the last hop (or any other) can essentially do >> a wholesale replacement of the message contents and that there is no >> way to distinguish that from a semantically meaningless footer tweak? >> >> I'm not sure that I understand your assertion that you can forge an >> AS any more than you could forge a DKIM signature. > > The whole point of verifying the chain of AS all the way back to i=1 > is that you can tell that the message went through those servers, in > that order. > > But it's bogus, because AS doesn't sign anything except itself and > some AMS and AAR. Once AMS doesn't validate any more (any change at > all) then you can't really tell that the message passed through there, > just the _a_ message passed through there. > > So I could take an existing message that had passed through Google and > create a brand new message and pass it off as if it had passed through > Google before passing through my server on its way to you. > > In which case - the AS is meaningless. It claims something which is > only true if everyone plays by the rules. But if everyone plays by > the rules, then it's excessive. You could just check the previous AAR > and know that the previous site had validated the hop before it, and > so on. It's crypto that doesn't add anything of value. > > It's not actively damaging (other than the advice to do excessive DNS > lookups), but it's also not doing anything meaningful, and it's adding > something forgeable that looks like it means something. > I think we are falling back a Policy Model where we need to know what the all important originating Author domain desires. What is the expected here for mail processing by the domain? I thought the main reason, purpose, the "PayOff" for ARC, was to help deal with indirect mail breakage when a DMARC p=reject policy is set and more importantly, SMTP receivers with embedded DMARC support have begun honoring with hard 55x rejects or ACCEPT/DISCARD/SPAM local policy logic. It is the same problem ADSP had, but it wasn't fully realized, only a proof of concept (demo) was shown (here in the list, by me). Receivers had yet to implement or turn on the ADSP DISCARD switch but we envisioned the indirect mail issue would begin when they did. So it was foreseeable Mailing List members would begin to get unsubscribed due to perpetual erroneous receiver rejections. DMARC proved it when the idea was implemented and honored and the screaming began. ARC is trying to automate something without the help of the originating domain. If ARC is suppose to help save the "message" and the author domain from using a p=reject on a mailing list or indirect mail travel, then it leverage the DNS lookup it is already doing. I think we have made this all too complex by resisting a policy concept that helps with all this main processing. ADSP and DMARC had to same issue, so when was ADSP abandoned and replaced with the "Super ADSP" version called DMARC, the only difference was the reporting stuff, which is really not helping. Anyway, food for thought, a DMARC Tag Extension called ArcSeal. I'm just winging it, so the ARC cogs can consider, or not: ArcSeal=All ; All ARC seals must be valid start to finish. ArcSeal=Last ; Only the last sender/ARC signer is necessary (because of the chain of trust). I suppose there is a "Hops" count concept in there, but the ArcSeal tag does not exist, the the message is in an indeterminate state. If it exist, thats added value to the Domain declaring to the world what it expects and allows, including desirable hard rejection. The main thing is the automation. It help with an incentive to encourage implementors sitting on the fence. It can help by relaxing the rejection of the DMARC p=reject policy using ARC. Isn't that a big help? Personally, I really don't want to waste any more years working on this ARC complex proposal and really, this DKIM project since the early 2000s. Folks, we are approaching 15 years on this stuff!!!! It has been a battle of the Trust Model vs Policy Model. We almost had it VBR for TRUST and for Policy with ADSP (proposed standard) plus ATPS (experimental) as a possible solution to the indirect mail problem. But abandoned and replaced with DMARC (Informational) which has the same problem ADSP was abandoned far. Sorry for repeating the same thing, but DMARC is the same problem and whey we are here, no? So if DMARC is it, can we please fix it and have it work with ARC to help resolve the indirect mail problem? If not, than other than marketing bullshit, is there any "mail" benefit and convincing reason why ARC should be implemented? Thanks. -- HLS From nobody Wed Aug 9 15:26:09 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D710C132021 for ; Wed, 9 Aug 2017 15:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=aoKTth03; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BLdcA+Fw Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iq_2PBIH9Mny for ; Wed, 9 Aug 2017 15:26:05 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B77E7131F21 for ; Wed, 9 Aug 2017 15:26:05 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 1DD7C21EF3 for ; Wed, 9 Aug 2017 18:26:05 -0400 (EDT) Received: from web1 ([10.202.2.211]) by compute6.internal (MEProxy); Wed, 09 Aug 2017 18:26:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=nt72PH+D1hJyZcphL F9aDd6aCC90rrZbiuKmLyYVKGM=; b=aoKTth03eo3eSpsS+IataQBCIbl7Fk2P1 gR/KvsDUZ71PKEKevcsFb4ywe3zhyU63Z9oujM/FZLwfMjyJwC/6EQQ0++08PscS lwKWSmTC2y/+Rvdn3rI8r0j3/ePnxudBFuVrSfS7MlVeZmwqh9xLpJYrqLjH3aU5 +L4DLaHRSMhHPC4QPtytTe7hnPjJbBxqrtEMDkgDnZF8wYzxURMAd889S2nJKNCb iZhxNJB9dGEw7zWsL1gjPAEB/ZQi4pHxntB5+pbb/b1bhKUwaU/b6YlTPcyk58cI W3Cuej00Gzvcyk2LwF+KshXhbc6JmH+mdj9szuVC8+DFhRCGI06fA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=nt72PH +D1hJyZcphLF9aDd6aCC90rrZbiuKmLyYVKGM=; b=BLdcA+FwbDwujFCQX1xo8R igY9OlDhfk5HMVGXqUkzTrpSpCP65VEfXmBMIgGI2HqEP+jWVCdOMcYUV5OKO0G3 bDrvy8ZL/F8jrbG7Iv2228prS15hY922jn4BB5F9n8gIDrMr4kc3tXj9HnoetqEK /Ocj2F8Mi7oHtqfMQ3q9QCu8UA3RjCTf8ih2h5ZKr9OZGLGVqxvlETigWDzZ/++8 th7TKyoFuqHWgmv93el56UYIWvc/p/0vgaUMexR+Abf5NYyEB06Nd2lXmeIgMuTP ajvmmHWzsd8EOQYoWOKYMHoYSe2efx6ID/eWrAZyb9DE8Vv57CBbXCsEkHEr+Ayw == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id D5FAE95713; Wed, 9 Aug 2017 18:26:04 -0400 (EDT) Message-Id: <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> From: Bron Gondwana To: dmarc@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150231756419353790" X-Mailer: MessagingEngine.com Webmail Interface - ajax-b56c1ff4 References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> In-Reply-To: <2720431.u3G7bbkkxK@kitterma-e6430> Date: Thu, 10 Aug 2017 08:26:04 +1000 Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre 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, 09 Aug 2017 22:26:08 -0000 This is a multi-part message in MIME format. --_----------=_150231756419353790 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Wed, 9 Aug 2017, at 00:28, Scott Kitterman wrote: > I think the "Once AMS doesn't validate anymore ..." argument is an > suggestion that it's fragile, not that it's pointless. I have > concerns myself about the robustness of this design, but I think > that's best addressed through deployment and experimentation. It's not fragility, the older AMS is supposed to not validate any more, because it's a signature over a bunch of headers and the body - any change in those will break it. That's fine so long as the chain of custody exists. My problem is that ARC-Seal only actually shows the chain of custody back to the first bad actor. That's also fine, because any bad actor means the whole message is tainted and should be discarded. The thing is - ARC-Seal and verifying every Seal only gives more integrity than checking the previous AMS and signing your own AAR unless this is true: * There exists a site which correctly checks ARC-Seal and adds new ARC- Seals, but does not generate an accurate AAR. I do feel like nobody understands what the hell I'm trying to say here based on the responses I've seen so far, so maybe I do actually need to find an existing ARC-Sealed email and forge a change to it. Seth asked to have a phone chat about this, and I'm happy to have a phone chat with anybody if it will help explain my point. I'm not saying that the underlying concept of ARC are wrong - the idea of chain of custody is sound. The problem is that ARC-Seal makes claims it just doesn't deliver on - it's not adding value, and it is adding cost and fragility (the need to successfully do DNS fetches for every seal in the chain at every point, plus the cost of checking that crypto) - and yet any one site can still falsify all the earlier items in the chain. Sadly I only have a few message in my entire mailbox that have ARC-Seals on them. They're from a Mozilla Thunderbird list of all things, and they have some Google ARC headers on them. I'd prefer to impersonate someone from this list if I'm going to make a proof of concept to show what I mean, but nobody appears to be sending messages with ARC headers on them here! Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_150231756419353790 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Wed, 9 Aug 2017, at 00:28, Scott Kitterman wrote:
I think the "Once AMS doesn't validate anymore ..." argument is an suggestion that it's fragile, not that it's pointless.  I have concerns myself about the robustness of this design, but I think that's best addressed through deployment and experimentation.

It's not fragility, the older AMS is supposed to not validate any more, because it's a signature over a bunch of headers and the body - any change in those will break it.  That's fine so long as the chain of custody exists.

My problem is that ARC-Seal only actually shows the chain of custody back to the first bad actor.  That's also fine, because any bad actor means the whole message is tainted and should be discarded.

The thing is - ARC-Seal and verifying every Seal only gives more integrity than checking the previous AMS and signing your own AAR unless this is true:

* There exists a site which correctly checks ARC-Seal and adds new ARC-Seals, but does not generate an accurate AAR.

I do feel like nobody understands what the hell I'm trying to say here based on the responses I've seen so far, so maybe I do actually need to find an existing ARC-Sealed email and forge a change to it.  Seth asked to have a phone chat about this, and I'm happy to have a phone chat with anybody if it will help explain my point.

I'm not saying that the underlying concept of ARC are wrong - the idea of chain of custody is sound.

The problem is that ARC-Seal makes claims it just doesn't deliver on - it's not adding value, and it is adding cost and fragility (the need to successfully do DNS fetches for every seal in the chain at every point, plus the cost of checking that crypto) - and yet any one site can still falsify all the earlier items in the chain.

Sadly I only have a few message in my entire mailbox that have ARC-Seals on them.  They're from a Mozilla Thunderbird list of all things, and they have some Google ARC headers on them.  I'd prefer to impersonate someone from this list if I'm going to make a proof of concept to show what I mean, but nobody appears to be sending messages with ARC headers on them here!

Bron.

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


--_----------=_150231756419353790-- From nobody Wed Aug 9 17:41:45 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A52131CB2 for ; Wed, 9 Aug 2017 17:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pm4RUVEKmalR for ; Wed, 9 Aug 2017 17:41:40 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A79E4132139 for ; Wed, 9 Aug 2017 17:41:32 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id x3so76936648oia.1 for ; Wed, 09 Aug 2017 17:41:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zY6dOeP3lL/8mCwUAq9ZEU6EaMfRrz9eisb5jFNCkAw=; b=G3CJSNOCG9sLfnnGmry0JAs11TRpAqafvhh7jPGhl+Vh2PqGTzuc7w6pRvLydgHU7E Crumod4uxR3LDMKVuksWKAzDbhnzGNSha0voxk4EyTCWmput8UBYQX+lYIdsWfcCaaR4 yPViPP1RsIhjAEFflgRbnyLvivSzIkJ6PbEsUH0NlIJdfxUII1Rplohat4u9UHyhQ7bC 8MWNxjvFZa47Fj9vDOae8onvR8BzDWDOSrzQb2F/lvspb9OL8v1pgZwnszdBlgRoqc4D IKEKKFim6BzVWeUdtU69+/cwEPfudPdhwf+AyEAT2kXROYQeTDRQyK0zxIfXYMmA7hN4 z/dA== 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=zY6dOeP3lL/8mCwUAq9ZEU6EaMfRrz9eisb5jFNCkAw=; b=NUiP9mR6CylbOKPuf6hyl8VDOSbC241nz0Vc+Zz6wpnuY5SpDEm8auNROojMEYxc8N rzOw8TL915nb9Ai9ZzaYIdO3g1iLJJ/+O8PUZ3I+JT1CbWbWNswV98GGMpNdpOv3r/j5 RlKTKutPQS1JhDQw19M/7sDT1xkO1Er0m9IONy8jiCI2K/yFCBVtJHXEeilzRcEvLEXQ xxlXGa7e6ByhbtgJBKNP9u4lEKzPZblWGVX0CoOCoDQ6I0oL0AYgI7abwDQicPv0DQP/ w25f8KVqq2AaZXYsbKqI5J7piT2jadf5FnNPVKktX8a5bBId60Lr8YkicaXssL0u9Bu+ COcA== X-Gm-Message-State: AHYfb5hHX08BqdEEc2QeFh0yUVkhMKUOD2yCTm4jY40TVLXDxXKOorCO Pk7K16I6bz29h9sSDWSs6ZueE3oMDLICm8o= X-Received: by 10.202.184.8 with SMTP id i8mr11298846oif.266.1502325691539; Wed, 09 Aug 2017 17:41:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.154.51 with HTTP; Wed, 9 Aug 2017 17:41:29 -0700 (PDT) Received: by 10.74.154.51 with HTTP; Wed, 9 Aug 2017 17:41:29 -0700 (PDT) In-Reply-To: <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> From: Brandon Long Date: Wed, 9 Aug 2017 17:41:29 -0700 Message-ID: To: Bron Gondwana Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="001a113ce0ba2eef4905565b756a" Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 00:41:43 -0000 --001a113ce0ba2eef4905565b756a Content-Type: text/plain; charset="UTF-8" We discussed this exact situation extensively during several M3AAWG meetings, so I don't think we're missing something... but maybe. With AS I can trust the chain and use the older hops AAR. And whether to use a given hops AAR is based on my trust level for that hop. As long as the AMS passes, you can ignore hops you don't trust and keep walking. Once you reach a hop where the AMS doesn't verify, you can only walk back to hops you trust, and untrusted hop ends your walk back. So, you can copy and entire chain on to whatever message you want, but that only works if I trust you. If you do this a lot, we won't trust you any more. This doesn't mean that some messages can't abuse the trust relationship and make it through, and we specifically say that standard spam/phishing/abuse analysis should still be done. With your proposed AAR signed by the AMS, I can only trust your AAR, and whatever you choose to put in it, not anyone in front of you. With XOAR, we have experience with that type of single hop working system, and it's not complete enough, we see too many complicated routing policies which go through many hops, and the last hop data isn't always enough. We work around it with from header rewrites and signing as the intermediary domain, but then we need to make decisions on when to do so since dkim means something different than ams does. Also, you wouldn't expect to see arc signed messages from this list until it starts doing them itself, unless people are posting to it though another intermediary or you receive it through a separate intermediary. Brandon On Aug 9, 2017 6:26 PM, "Bron Gondwana" wrote: > On Wed, 9 Aug 2017, at 00:28, Scott Kitterman wrote: > > I think the "Once AMS doesn't validate anymore ..." argument is an > suggestion that it's fragile, not that it's pointless. I have concerns > myself about the robustness of this design, but I think that's best > addressed through deployment and experimentation. > > > It's not fragility, the older AMS is supposed to not validate any more, > because it's a signature over a bunch of headers and the body - any change > in those will break it. That's fine so long as the chain of custody exists. > > My problem is that ARC-Seal only actually shows the chain of custody back > to the first bad actor. That's also fine, because any bad actor means the > whole message is tainted and should be discarded. > > The thing is - ARC-Seal and verifying every Seal only gives more integrity > than checking the previous AMS and signing your own AAR unless this is true: > > * There exists a site which correctly checks ARC-Seal and adds new > ARC-Seals, but does not generate an accurate AAR. > > I do feel like nobody understands what the hell I'm trying to say here > based on the responses I've seen so far, so maybe I do actually need to > find an existing ARC-Sealed email and forge a change to it. Seth asked to > have a phone chat about this, and I'm happy to have a phone chat with > anybody if it will help explain my point. > > I'm not saying that the underlying concept of ARC are wrong - the idea of > chain of custody is sound. > > The problem is that ARC-Seal makes claims it just doesn't deliver on - > it's not adding value, and it is adding cost and fragility (the need to > successfully do DNS fetches for every seal in the chain at every point, > plus the cost of checking that crypto) - and yet any one site can still > falsify all the earlier items in the chain. > > Sadly I only have a few message in my entire mailbox that have ARC-Seals > on them. They're from a Mozilla Thunderbird list of all things, and they > have some Google ARC headers on them. I'd prefer to impersonate someone > from this list if I'm going to make a proof of concept to show what I mean, > but nobody appears to be sending messages with ARC headers on them here! > > Bron. > > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --001a113ce0ba2eef4905565b756a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We discussed this exact situation exten= sively during several M3AAWG meetings, so I don't think we're missi= ng something... but maybe.

With AS I can t= rust the chain and use the older hops AAR.=C2=A0 And whether to use a given= hops AAR is based on my trust level for that hop.

As long as the AMS passes, you can ignore hops you don= 't trust and keep walking.

Once you reach a hop where the AMS doesn't verify, you can only wa= lk back to hops you trust, and untrusted hop ends your walk back.
=

So, you can copy and entire c= hain on to whatever message you want, but that only works if I trust you.= =C2=A0 If you do this a lot, we won't trust you any more.

This doesn't mean that some messa= ges can't abuse the trust relationship and make it through, and we spec= ifically say that standard spam/phishing/abuse analysis should still be don= e.

Wit= h your proposed AAR signed by the AMS, I can only trust your AAR, and whate= ver you choose to put in it, not anyone in front of you. =C2=A0

With XOAR, we have experience with = that type of single hop working system, and it's not complete enough, w= e see too many complicated routing policies which go through many hops, and= the last hop data isn't always enough.=C2=A0 We work around it with fr= om header rewrites and signing as the intermediary domain, but then we need= to make decisions on when to do so since dkim means something different th= an ams does.

Also, you w= ouldn't expect to see arc signed messages from this list until it start= s doing them itself, unless people are posting to it though another interme= diary or you receive it through a separate intermediary.

Brandon

On Aug 9, 2017 6:26 PM, &qu= ot;Bron Gondwana" <brong@= fastmailteam.com> wrote:
On Wed, 9 Aug 2017, at 00:28, Scott K= itterman wrote:
I think the "Once AMS doesn't valid= ate anymore ..." argument is an suggestion that it's fragile, not = that it's pointless.=C2=A0 I have concerns myself about the robustness = of this design, but I think that's best addressed through deployment an= d experimentation.

It's not fragility, the older AMS is s= upposed to not validate any more, because it's a signature over a bunch= of headers and the body - any change in those will break it.=C2=A0 That= 9;s fine so long as the chain of custody exists.

My problem is that ARC-Seal only actually = shows the chain of custody back to the first bad actor.=C2=A0 That's al= so fine, because any bad actor means the whole message is tainted and shoul= d be discarded.

The thing is - ARC-Seal and verifying ever= y Seal only gives more integrity than checking the previous AMS and signing= your own AAR unless this is true:

* There exists a site which correctly chec= ks ARC-Seal and adds new ARC-Seals, but does not generate an accurate AAR.<= br>

I do feel like nobody understands what the= hell I'm trying to say here based on the responses I've seen so fa= r, so maybe I do actually need to find an existing ARC-Sealed email and for= ge a change to it.=C2=A0 Seth asked to have a phone chat about this, and I&= #39;m happy to have a phone chat with anybody if it will help explain my p= oint.

I'm not saying that the underlying con= cept of ARC are wrong - the idea of chain of custody is sound.

The problem is that ARC-Seal makes claims = it just doesn't deliver on - it's not adding value, and it is addin= g cost and fragility (the need to successfully do DNS fetches for every sea= l in the chain at every point, plus the cost of checking that crypto) - and= yet any one site can still falsify all the earlier items in the chain.
=

Sadly I only have a few message in my enti= re mailbox that have ARC-Seals on them.=C2=A0 They're from a Mozilla Th= underbird list of all things, and they have some Google ARC headers on them= .=C2=A0 I'd prefer to impersonate someone from this list if I'm goi= ng to make a proof of concept to show what I mean, but nobody appears to be= sending messages with ARC headers on them here!

Bron.

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



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

--001a113ce0ba2eef4905565b756a-- From nobody Wed Aug 9 17:42:26 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCEFC1324E2 for ; Wed, 9 Aug 2017 17:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, 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=fiction.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 f_GgXqOlX2Pd for ; Wed, 9 Aug 2017 17:42:10 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAF17131CB2 for ; Wed, 9 Aug 2017 17:42:10 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id e124so77091227oig.2 for ; Wed, 09 Aug 2017 17:42:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fiction.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=13KqUpzwyg35xHZ+nJsoFYAC63bZFUInamhUNUzAFwA=; b=IOhlC4EEt5gM2dubbRJQX3jMiHTx+Qde3aIGH/iWJHp1+xv6YktFSHCh6kxy5LRrjG CXksDZXZ7NQf46WYWz0qiVavJqxvMNANfiNKPLxwCN/k6RZJFoLDnIvHNZd7yc8GzBxG hn63YICnnI4khXvMnkbYUUXbCAPj4ST5mowsWb8N+JMuqOC9U0Guq1jbp45j2uX4J5bH oMAgCWPoRZqH0Z8rWXz2oVLfLgC7IC3VrjEG7I2Fzqulycll6SrMZJgj2yJwDV40BP8K qhHxK2vD2awR4X1EZgyl4lZU5C6vMdR6TTnyGMAmb51eUwnuq6lhdNjpm9C5oA5+UpGI AwIA== 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=13KqUpzwyg35xHZ+nJsoFYAC63bZFUInamhUNUzAFwA=; b=ba6l5W5Bdrp65yHxt3fufnQzwasGhg06GCvFIkuvSU2t9EFpWXBhorwK1ehMbhcocB /vljXb9ZEa21qp0ev0t8heRS5Zz2NwcfAyPTdgCGXjEPuY2NQoKt86ALoL91GRiN9XKs wLf4NQXtIdSju/lyuR37caKXnx89mX1MkMaM73zSLHJ596wx6WMAiJ4hFm7BTv+W0WqA n3OYchHS3snQ5pVOAy8G2kK03rSrNCSDG6hCnfDn0oABF7dsKyMOjDC4i79/ypZIRZSK VSw+P8I1QBdtZiful+t1/qrnpb8p5Oi4DPnaj1ixQGEhfOuBB0Ikv+0DRfxAMKe+I6wj b1zw== X-Gm-Message-State: AHYfb5h1cmpgc2BvH049NTqyFW3bIUr/Iy2MS3bCGvWNqg86gcAiSjm8 88pyHZhlYNbR0SQwnz0= X-Received: by 10.202.213.216 with SMTP id m207mr12790429oig.17.1502325729998; Wed, 09 Aug 2017 17:42:09 -0700 (PDT) Received: from mail-oi0-f51.google.com (mail-oi0-f51.google.com. [209.85.218.51]) by smtp.gmail.com with ESMTPSA id l191sm5002346oih.26.2017.08.09.17.42.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Aug 2017 17:42:09 -0700 (PDT) Received: by mail-oi0-f51.google.com with SMTP id x3so76944946oia.1 for ; Wed, 09 Aug 2017 17:42:09 -0700 (PDT) X-Received: by 10.202.104.6 with SMTP id d6mr10262103oic.95.1502325728623; Wed, 09 Aug 2017 17:42:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.154.51 with HTTP; Wed, 9 Aug 2017 17:42:07 -0700 (PDT) Received: by 10.74.154.51 with HTTP; Wed, 9 Aug 2017 17:42:07 -0700 (PDT) In-Reply-To: References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> From: Brandon Long Date: Wed, 9 Aug 2017 17:42:07 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Bron Gondwana Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="001a1140f9c264fb4e05565b77d4" Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 00:42:15 -0000 --001a1140f9c264fb4e05565b77d4 Content-Type: text/plain; charset="UTF-8" Sorry, posted from the wrong address, trying again. On Aug 9, 2017 8:41 PM, "Brandon Long" wrote: > We discussed this exact situation extensively during several M3AAWG > meetings, so I don't think we're missing something... but maybe. > > With AS I can trust the chain and use the older hops AAR. And whether to > use a given hops AAR is based on my trust level for that hop. > > As long as the AMS passes, you can ignore hops you don't trust and keep > walking. > > Once you reach a hop where the AMS doesn't verify, you can only walk back > to hops you trust, and untrusted hop ends your walk back. > > So, you can copy and entire chain on to whatever message you want, but > that only works if I trust you. If you do this a lot, we won't trust you > any more. > > This doesn't mean that some messages can't abuse the trust relationship > and make it through, and we specifically say that standard > spam/phishing/abuse analysis should still be done. > > With your proposed AAR signed by the AMS, I can only trust your AAR, and > whatever you choose to put in it, not anyone in front of you. > > With XOAR, we have experience with that type of single hop working system, > and it's not complete enough, we see too many complicated routing policies > which go through many hops, and the last hop data isn't always enough. We > work around it with from header rewrites and signing as the intermediary > domain, but then we need to make decisions on when to do so since dkim > means something different than ams does. > > Also, you wouldn't expect to see arc signed messages from this list until > it starts doing them itself, unless people are posting to it though another > intermediary or you receive it through a separate intermediary. > > Brandon > > On Aug 9, 2017 6:26 PM, "Bron Gondwana" wrote: > >> On Wed, 9 Aug 2017, at 00:28, Scott Kitterman wrote: >> >> I think the "Once AMS doesn't validate anymore ..." argument is an >> suggestion that it's fragile, not that it's pointless. I have concerns >> myself about the robustness of this design, but I think that's best >> addressed through deployment and experimentation. >> >> >> It's not fragility, the older AMS is supposed to not validate any more, >> because it's a signature over a bunch of headers and the body - any change >> in those will break it. That's fine so long as the chain of custody exists. >> >> My problem is that ARC-Seal only actually shows the chain of custody back >> to the first bad actor. That's also fine, because any bad actor means the >> whole message is tainted and should be discarded. >> >> The thing is - ARC-Seal and verifying every Seal only gives more >> integrity than checking the previous AMS and signing your own AAR unless >> this is true: >> >> * There exists a site which correctly checks ARC-Seal and adds new >> ARC-Seals, but does not generate an accurate AAR. >> >> I do feel like nobody understands what the hell I'm trying to say here >> based on the responses I've seen so far, so maybe I do actually need to >> find an existing ARC-Sealed email and forge a change to it. Seth asked to >> have a phone chat about this, and I'm happy to have a phone chat with >> anybody if it will help explain my point. >> >> I'm not saying that the underlying concept of ARC are wrong - the idea of >> chain of custody is sound. >> >> The problem is that ARC-Seal makes claims it just doesn't deliver on - >> it's not adding value, and it is adding cost and fragility (the need to >> successfully do DNS fetches for every seal in the chain at every point, >> plus the cost of checking that crypto) - and yet any one site can still >> falsify all the earlier items in the chain. >> >> Sadly I only have a few message in my entire mailbox that have ARC-Seals >> on them. They're from a Mozilla Thunderbird list of all things, and they >> have some Google ARC headers on them. I'd prefer to impersonate someone >> from this list if I'm going to make a proof of concept to show what I mean, >> but nobody appears to be sending messages with ARC headers on them here! >> >> Bron. >> >> -- >> Bron Gondwana, CEO, FastMail Pty Ltd >> brong@fastmailteam.com >> >> >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> >> --001a1140f9c264fb4e05565b77d4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry, posted from the wrong address, trying again.
=

On Aug 9, 2017 8:= 41 PM, "Brandon Long" <blo= ng@google.com> wrote:
We discussed this exact situat= ion extensively during several M3AAWG meetings, so I don't think we'= ;re missing something... but maybe.

With A= S I can trust the chain and use the older hops AAR.=C2=A0 And whether to us= e a given hops AAR is based on my trust level for that hop.

As long as the AMS passes, you can ignore hop= s you don't trust and keep walking.

Once you reach a hop where the AMS doesn't verify, you ca= n only walk back to hops you trust, and untrusted hop ends your walk back.<= br>

So, you can copy and= entire chain on to whatever message you want, but that only works if I tru= st you.=C2=A0 If you do this a lot, we won't trust you any more.
<= div dir=3D"auto">
This doesn't mean that som= e messages can't abuse the trust relationship and make it through, and = we specifically say that standard spam/phishing/abuse analysis should still= be done.

With your proposed AAR signed by the AMS, I can only trust your AAR, an= d whatever you choose to put in it, not anyone in front of you. =C2=A0

With XOAR, we have experienc= e with that type of single hop working system, and it's not complete en= ough, we see too many complicated routing policies which go through many ho= ps, and the last hop data isn't always enough.=C2=A0 We work around it = with from header rewrites and signing as the intermediary domain, but then = we need to make decisions on when to do so since dkim means something diffe= rent than ams does.

Also= , you wouldn't expect to see arc signed messages from this list until i= t starts doing them itself, unless people are posting to it though another = intermediary or you receive it through a separate intermediary.

Brandon

On Aug 9, 2017 6:26 P= M, "Bron Gondwana" <brong@fastmailteam.com> wrote:
On Wed, 9 Aug 2017, at 00:28, Scott K= itterman wrote:
I think the "Once AMS doesn't valid= ate anymore ..." argument is an suggestion that it's fragile, not = that it's pointless.=C2=A0 I have concerns myself about the robustness = of this design, but I think that's best addressed through deployment an= d experimentation.

It's not fragility, the older AMS is s= upposed to not validate any more, because it's a signature over a bunch= of headers and the body - any change in those will break it.=C2=A0 That= 9;s fine so long as the chain of custody exists.

My problem is that ARC-Seal only actually = shows the chain of custody back to the first bad actor.=C2=A0 That's al= so fine, because any bad actor means the whole message is tainted and shoul= d be discarded.

The thing is - ARC-Seal and verifying ever= y Seal only gives more integrity than checking the previous AMS and signing= your own AAR unless this is true:

* There exists a site which correctly chec= ks ARC-Seal and adds new ARC-Seals, but does not generate an accurate AAR.<= br>

I do feel like nobody understands what the= hell I'm trying to say here based on the responses I've seen so fa= r, so maybe I do actually need to find an existing ARC-Sealed email and for= ge a change to it.=C2=A0 Seth asked to have a phone chat about this, and I&= #39;m happy to have a phone chat with anybody if it will help explain my p= oint.

I'm not saying that the underlying con= cept of ARC are wrong - the idea of chain of custody is sound.

The problem is that ARC-Seal makes claims = it just doesn't deliver on - it's not adding value, and it is addin= g cost and fragility (the need to successfully do DNS fetches for every sea= l in the chain at every point, plus the cost of checking that crypto) - and= yet any one site can still falsify all the earlier items in the chain.
=

Sadly I only have a few message in my enti= re mailbox that have ARC-Seals on them.=C2=A0 They're from a Mozilla Th= underbird list of all things, and they have some Google ARC headers on them= .=C2=A0 I'd prefer to impersonate someone from this list if I'm goi= ng to make a proof of concept to show what I mean, but nobody appears to be= sending messages with ARC headers on them here!

Bron.

--
=C2=A0 Bron Gondw= ana, CEO, FastMail Pty Ltd
=C2=A0 <= a href=3D"mailto:brong@fastmailteam.com" target=3D"_blank">brong@fastmailte= am.com



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

--001a1140f9c264fb4e05565b77d4-- From nobody Wed Aug 9 22:54:45 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96B6A132550 for ; Wed, 9 Aug 2017 22:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=pU4TASax; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QElkfSYx Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRGtm4EZ32Hh for ; Wed, 9 Aug 2017 22:54:41 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68078132554 for ; Wed, 9 Aug 2017 22:54:41 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id C46E421947 for ; Thu, 10 Aug 2017 01:54:40 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Thu, 10 Aug 2017 01:54:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=W5ZwLJR1eqTdJGN4i WWr6qiDbscYdB/N3h2FC/35CBY=; b=pU4TASaxIDJ2gLUwQfQvyL/O0jctLpBE2 bCMvfXylmsEuzSQLOSYuXtHc/27URtOkZw1QT/dekxs4ZKqa4z34/rpfMD+PPMwT yXmyAcpx7Eb4GMeykQRQWx813xtOOryJ841YHaPiLheyrUxJdy3M7MdeezR/wTHh HzjlnvkbP5CPVnGBrBMIYE/6yxtTG+oT0fl70x2qWChzS2793hBrsKxRjjkG9O25 o+6KSX6MlnZdWJeYQxt2VfNmIvTk00s0Kufbh7OKHBfrSM9E23qeuAnIZa8gsqil uUQ3G2YIEyIp9GMoln3xN8Sz3iZMs7wnllzF+hl2cvH0AkpW+8iHQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=W5ZwLJ R1eqTdJGN4iWWr6qiDbscYdB/N3h2FC/35CBY=; b=QElkfSYx4r4mGiSI0dC1it UZVJ/yne+UiihxUH2dIZbYzjJT7cFRegib7s4RQ4aSwjL7oHf9I32DwhS+oh99SI a0kmAfEdWXu7DBXEJuFlU+P95hhwA69PM7lxbSfLyN6pPP9meoMfy3yB5v6TAyPa Tbp4bQZX7Tgf6IAZdSdmIPZLkkKO1BsYP+tU/KQ6sRTQMLvqGPkyEx18FClrO6/p Ly4TRwCQ5F0vLcbYDlSdztd6UNqhaANAfEGIbLLzjHQPH0QJTTqfq24jAYP3/MBO 8s4Z9eUhFa5s+eH5lWKYGkIZ4rNDkfNvDh8etvpeq6zEikzTpck0neJ8Wb3y9h0g == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 97DC59E28E; Thu, 10 Aug 2017 01:54:40 -0400 (EDT) Message-Id: <1502344480.3621518.1068879272.5CA6811B@webmail.messagingengine.com> From: Bron Gondwana To: dmarc@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150234448036215180" X-Mailer: MessagingEngine.com Webmail Interface - ajax-b56c1ff4 In-Reply-To: References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> Date: Thu, 10 Aug 2017 15:54:40 +1000 Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 05:54:44 -0000 This is a multi-part message in MIME format. --_----------=_150234448036215180 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Thu, 10 Aug 2017, at 10:41, Brandon Long wrote: > We discussed this exact situation extensively during several M3AAWG > meetings, so I don't think we're missing something... but maybe.> > With AS I can trust the chain and use the older hops AAR. And whether > to use a given hops AAR is based on my trust level for that hop.> > As long as the AMS passes, you can ignore hops you don't trust and > keep walking. I would argue that if the AMS passes, the intermediate hop SHOULD NOT add another ARC-Seal... > Once you reach a hop where the AMS doesn't verify, you can only walk > back to hops you trust, and untrusted hop ends your walk back. Which is precisely my point above. Consider this case A => B => C => D Where C is untrusted and you are D, but the AMS is A(fail) => B(pass) => C(pass) => D So you know that C didn't modify the message, and you can trust the message because you trust B. Now suppose D modifies the message and sends it on. A => B => C => D => E With AMS status: A(fail) => B(fail) => C(fail) => D(pass) => E If you (E) trust A, B and D but don't trust C, the fact that C added an ARC-Seal has confused a message that was perfectly trustworthy, because you can no longer validate the fact that C didn't change the message. That's why I say: don't ARC-Seal unless you're changing the message. > So, you can copy and entire chain on to whatever message you want, but > that only works if I trust you. If you do this a lot, we won't trust > you any more. That's fine if you have the resources of Google to know who's intermediating a lot. If you are B in that chain above and you can get C to forward your messages, you could easily destroy C or D's reputation at E, even though D knew that C wasn't modifying your messages. > This doesn't mean that some messages can't abuse the trust > relationship and make it through, and we specifically say that > standard spam/phishing/abuse analysis should still be done.> > With your proposed AAR signed by the AMS, I can only trust your AAR, > and whatever you choose to put in it, not anyone in front of you. This comes down to how standard the AAR is. If my AAR includes machine parseable information to say that I could validate the previous AMS and it passed, then you can walk back through the chain just as easily, without even needing to validate the previous signatures, because I already did that for the previous one, and they already did it for the one before. There are only two cases that the full ARC-Seal helps with. You spelt out one above: the earlier AMSes still validate, so you know the message hasn't changed. That's bogus to me in two ways:* the one I just spelled out (it muddies things after the next modification), so don't do it in the first place* if you can still validate the earlier AMS then you don't even need the follow the ARC-Seals - just validate each AMS from highest i= down until you find one that doesn't pass. All the passing AMS must be trustworthy regardless of the later ARC-Seals, because they are signed by the domain and correctly describe the current message. So ARC-Seal buys you nothing for the hops where AMS is passing (because you're checking AMS anyway), and it buys you nothing for the earlier hops, because you have to stop at the first hop you don't trust. I will give you this - if you believe that it's likely that implementations will exist that can successfully validate an AS chain, and can successfully validate the previous AMS, but can NOT reliably generate an AAR header, then ARC-Seal would have a point. Otherwise we're trusting sites to do all the crypto right, but not trusting them to report the results of said validation correctly, which is really a weird security stance IMHO. > With XOAR, we have experience with that type of single hop working > system, and it's not complete enough, we see too many complicated > routing policies which go through many hops, and the last hop data > isn't always enough. We work around it with from header rewrites and > signing as the intermediary domain, but then we need to make decisions > on when to do so since dkim means something different than ams does. I believe the logic for "should I add an AMS" should be: 1) there is existing DKIM, but I'm about to break it by changing the message2) there is an existing AMS, but I'm about to break it by changing the message3) there is no DKIM or AMS, but I trusted the message for some other reason which the next hop will be unable to verify (e.g. SPF passed) In all other cases, adding a signature is bad. Complex routing should not break the signature, so only the process making the modifications should be adding a new signature. In the case of Google, that would mean adding an AMS on incoming MX only for messages which have no DKIM, then adding an AMS for messages which are modified (e.g. by Groups) > Also, you wouldn't expect to see arc signed messages from this list > until it starts doing them itself, unless people are posting to it > though another intermediary or you receive it through a separate > intermediary. It wasn't so much this list, it was everything else in my entire mail repository! Not much with ARC on it yet. Bron. > Brandon > > On Aug 9, 2017 6:26 PM, "Bron Gondwana" > wrote:>> __ >> On Wed, 9 Aug 2017, at 00:28, Scott Kitterman wrote: >>> I think the "Once AMS doesn't validate anymore ..." argument is an >>> suggestion that it's fragile, not that it's pointless. I have >>> concerns myself about the robustness of this design, but I think >>> that's best addressed through deployment and experimentation.>> >> It's not fragility, the older AMS is supposed to not validate any >> more, because it's a signature over a bunch of headers and the body - >> any change in those will break it. That's fine so long as the chain >> of custody exists.>> >> My problem is that ARC-Seal only actually shows the chain of custody >> back to the first bad actor. That's also fine, because any bad actor >> means the whole message is tainted and should be discarded.>> >> The thing is - ARC-Seal and verifying every Seal only gives more >> integrity than checking the previous AMS and signing your own AAR >> unless this is true:>> >> * There exists a site which correctly checks ARC-Seal and adds new >> ARC-Seals, but does not generate an accurate AAR.>> >> I do feel like nobody understands what the hell I'm trying to say >> here based on the responses I've seen so far, so maybe I do actually >> need to find an existing ARC-Sealed email and forge a change to it. >> Seth asked to have a phone chat about this, and I'm happy to have a >> phone chat with anybody if it will help explain my point.>> >> I'm not saying that the underlying concept of ARC are wrong - the >> idea of chain of custody is sound.>> >> The problem is that ARC-Seal makes claims it just doesn't deliver on >> - it's not adding value, and it is adding cost and fragility (the >> need to successfully do DNS fetches for every seal in the chain at >> every point, plus the cost of checking that crypto) - and yet any one >> site can still falsify all the earlier items in the chain.>> >> Sadly I only have a few message in my entire mailbox that have ARC- >> Seals on them. They're from a Mozilla Thunderbird list of all >> things, and they have some Google ARC headers on them. I'd prefer to >> impersonate someone from this list if I'm going to make a proof of >> concept to show what I mean, but nobody appears to be sending >> messages with ARC headers on them here!>> >> Bron. >> >> -- >> Bron Gondwana, CEO, FastMail Pty Ltd >> brong@fastmailteam.com >> >> >> >> _______________________________________________ >> 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 -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_150234448036215180 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Thu, 10 Aug 2017, at 10:41, Brandon Long wrote:
We discussed this exact situation extensively during several M3AAWG meetings, so I don't think we're missing something... but maybe.

With AS I can trust the chain and use the older hops AAR.  And whether to use a given hops AAR is based on my trust level for that hop.

As long as the AMS passes, you can ignore hops you don't trust and keep walking.

I would argue that if the AMS passes, the intermediate hop SHOULD NOT add another ARC-Seal...

Once you reach a hop where the AMS doesn't verify, you can only walk back to hops you trust, and untrusted hop ends your walk back.

Which is precisely my point above.  Consider this case

A => B => C => D

Where C is untrusted and you are D, but the AMS is

A(fail) => B(pass) => C(pass) => D

So you know that C didn't modify the message, and you can trust the message because you trust B.

Now suppose D modifies the message and sends it on.

A => B => C => D => E

With AMS status:

A(fail) => B(fail) => C(fail) => D(pass) => E

If you (E) trust A, B and D but don't trust C, the fact that C added an ARC-Seal has confused a message that was perfectly trustworthy, because you can no longer validate the fact that C didn't change the message.

That's why I say: don't ARC-Seal unless you're changing the message.

So, you can copy and entire chain on to whatever message you want, but that only works if I trust you.  If you do this a lot, we won't trust you any more.

That's fine if you have the resources of Google to know who's intermediating a lot. 

If you are B in that chain above and you can get C to forward your messages, you could easily destroy C or D's reputation at E, even though D knew that C wasn't modifying your messages.

This doesn't mean that some messages can't abuse the trust relationship and make it through, and we specifically say that standard spam/phishing/abuse analysis should still be done.

With your proposed AAR signed by the AMS, I can only trust your AAR, and whatever you choose to put in it, not anyone in front of you.  

This comes down to how standard the AAR is.  If my AAR includes machine parseable information to say that I could validate the previous AMS and it passed, then you can walk back through the chain just as easily, without even needing to validate the previous signatures, because I already did that for the previous one, and they already did it for the one before.

There are only two cases that the full ARC-Seal helps with.  You spelt out one above: the earlier AMSes still validate, so you know the message hasn't changed.  That's bogus to me in two ways:
* the one I just spelled out (it muddies things after the next modification), so don't do it in the first place
* if you can still validate the earlier AMS then you don't even need the follow the ARC-Seals - just validate each AMS from highest i= down until you find one that doesn't pass.  All the passing AMS must be trustworthy regardless of the later ARC-Seals, because they are signed by the domain and correctly describe the current message.

So ARC-Seal buys you nothing for the hops where AMS is passing (because you're checking AMS anyway), and it buys you nothing for the earlier hops, because you have to stop at the first hop you don't trust.

I will give you this - if you believe that it's likely that implementations will exist that can successfully validate an AS chain, and can successfully validate the previous AMS, but can NOT reliably generate an AAR header, then ARC-Seal would have a point.  Otherwise we're trusting sites to do all the crypto right, but not trusting them to report the results of said validation correctly, which is really a weird security stance IMHO.

With XOAR, we have experience with that type of single hop working system, and it's not complete enough, we see too many complicated routing policies which go through many hops, and the last hop data isn't always enough.  We work around it with from header rewrites and signing as the intermediary domain, but then we need to make decisions on when to do so since dkim means something different than ams does.

I believe the logic for "should I add an AMS" should be:
1) there is existing DKIM, but I'm about to break it by changing the message
2) there is an existing AMS, but I'm about to break it by changing the message
3) there is no DKIM or AMS, but I trusted the message for some other reason which the next hop will be unable to verify (e.g. SPF passed)

In all other cases, adding a signature is bad.  Complex routing should not break the signature, so only the process making the modifications should be adding a new signature.

In the case of Google, that would mean adding an AMS on incoming MX only for messages which have no DKIM, then adding an AMS for messages which are modified (e.g. by Groups)

Also, you wouldn't expect to see arc signed messages from this list until it starts doing them itself, unless people are posting to it though another intermediary or you receive it through a separate intermediary.

It wasn't so much this list, it was everything else in my entire mail repository!  Not much with ARC on it yet.

Bron.

Brandon

On Aug 9, 2017 6:26 PM, "Bron Gondwana" <brong@fastmailteam.com> wrote:

On Wed, 9 Aug 2017, at 00:28, Scott Kitterman wrote:
I think the "Once AMS doesn't validate anymore ..." argument is an suggestion that it's fragile, not that it's pointless.  I have concerns myself about the robustness of this design, but I think that's best addressed through deployment and experimentation.

It's not fragility, the older AMS is supposed to not validate any more, because it's a signature over a bunch of headers and the body - any change in those will break it.  That's fine so long as the chain of custody exists.

My problem is that ARC-Seal only actually shows the chain of custody back to the first bad actor.  That's also fine, because any bad actor means the whole message is tainted and should be discarded.

The thing is - ARC-Seal and verifying every Seal only gives more integrity than checking the previous AMS and signing your own AAR unless this is true:

* There exists a site which correctly checks ARC-Seal and adds new ARC-Seals, but does not generate an accurate AAR.

I do feel like nobody understands what the hell I'm trying to say here based on the responses I've seen so far, so maybe I do actually need to find an existing ARC-Sealed email and forge a change to it.  Seth asked to have a phone chat about this, and I'm happy to have a phone chat with anybody if it will help explain my point.

I'm not saying that the underlying concept of ARC are wrong - the idea of chain of custody is sound.

The problem is that ARC-Seal makes claims it just doesn't deliver on - it's not adding value, and it is adding cost and fragility (the need to successfully do DNS fetches for every seal in the chain at every point, plus the cost of checking that crypto) - and yet any one site can still falsify all the earlier items in the chain.

Sadly I only have a few message in my entire mailbox that have ARC-Seals on them.  They're from a Mozilla Thunderbird list of all things, and they have some Google ARC headers on them.  I'd prefer to impersonate someone from this list if I'm going to make a proof of concept to show what I mean, but nobody appears to be sending messages with ARC headers on them here!

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd



_______________________________________________
dmarc mailing list

_______________________________________________
dmarc mailing list

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


--_----------=_150234448036215180-- From nobody Fri Aug 11 08:28:12 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B96331320B5 for ; Fri, 11 Aug 2017 08:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BahvvFFQ1QlO for ; Fri, 11 Aug 2017 08:28:07 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4C1C13219E for ; Fri, 11 Aug 2017 08:28:07 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id f11so36365616oic.0 for ; Fri, 11 Aug 2017 08:28:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=Veq6J2E16yBQ1nfsdhjVbYw5069i5GQ3s1R9+z4KUpI=; b=uP81Lo/eRkYj5M+Y1MvpqqEcm3rvR5raEYfYEKFDG/pImTg4vejaHC6zEfwlxIWdWz eNMmlkdvJDn/OFNoRKtH4sw1LMjOXnmFpf21QYhLxjsXGKlp2QTU1VSo4tzF0aDZIJco 2npWXI0cdzMBBVSIMpNXz3TzYzvSH5WVy1PHezaIOt8VTefnAvzLIOHHOleG3GubxTMZ UIVssQ6KvQd47vtjaCcV8IrEXN+oDtj4RUX4BYFO0RWa98lhmzqkYGUW1AOpQFoERhOo hlg57hGaTMyQr6RumlMRbZPmlLIG9xT0VkrV93mI9dioFwnWVPcLubT6c+DsjKVvHkOz vQnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Veq6J2E16yBQ1nfsdhjVbYw5069i5GQ3s1R9+z4KUpI=; b=ijpuW8XWEJ4QqqxphwurVT2Ng7GXnU+DAjDSdrN1zWmbEX+nvt/5BCxjNAvL+t6v0P vJRfuV4YKsXhOjbjHxpg7I529a4biCkbMeEYool09vYEql0lD9jerfAVenoUCuNW0Z6p 49knLUxW5Bp1NwJXRvqB48OZ2vCrpQuA3nx0Z2ru5acNvS0IlaLWn2IaV+gzDKqEvcii XytfYuiuOVZXSWJ79h4d3vUjFhYxshpGTjmNaxCtQr8dzcHdCzlhVS9HJiniJYr8XbIk Jc4ZX1NpEi7kMc14i1F+DXtU/HM6j7wGLb6RNeWPRV+4a5spjyhUzU7SGp9ilFjPG3zf LnlQ== X-Gm-Message-State: AHYfb5hiRxkagwXWCrzeBiMil/3MG/IU/cskpPFrNmC3PohNfio9G0cv +H6h6OUQisZCb1LtVGc= X-Received: by 10.202.172.75 with SMTP id v72mr17922934oie.1.1502465286454; Fri, 11 Aug 2017 08:28:06 -0700 (PDT) Received: from ?IPv6:2602:304:cda0:8800:d17e:7fe3:9cb7:7c98? ([2602:304:cda0:8800:d17e:7fe3:9cb7:7c98]) by smtp.gmail.com with ESMTPSA id w127sm904583oia.22.2017.08.11.08.28.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Aug 2017 08:28:05 -0700 (PDT) To: "dmarc@ietf.org" References: From: Dave Crocker Message-ID: <77ae9638-7a10-1165-f2fd-ce8e53fee3d4@gmail.com> Date: Fri, 11 Aug 2017 08:28:04 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Review of: draft-ietf-dmarc-arc-protocol-08 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, 11 Aug 2017 15:28:11 -0000 Folks, I posted my review 2 weeks ago and haven't seen any responses. From some offlist exchanges, I think some believe the review responses are merely editorial. They aren't. While some of the review does point to (merely) editorial issues that are best resolved by the document editor, some others need to have wg discussion and develop wg consensus (IMO). In case the length of the review has made it problematic for wg participants to identify such points, here's a listing of some items I think obviously need that discussion: On 7/27/2017 6:19 PM, Dave Crocker wrote: > Sometimes the document contains language purporting to be normative but > lacking technical detail. Typically, these really are mild advisories > and should be altered to softer language or even removed. The basic > question that needs to be asked repeatedly throughout the text is: how > will a new implementer be able to use this text to produce reliably > interoperable software? > > The document seems to mix protocol specification with development > guidance and operations guidance. It needs to separate these much > better and distinguish them more carefully. The above two might seem only editorial but, really, they require more wg clarity about what the document is actually specifying, normatively. > I thought an essential motivation for ARC was to create a signature that > would be more survivable than a simple DKIM signature. Perhaps that's > no longer the case and that, rather, the goal is simply to create a > /replacement/ (set of) signature(s), after breaking the original. The > intro to the spec should make a clear, direct, simple statement about this. This is a basic goal question. > There are some portions of the document that seems to be modifying DKIM > or SMTP, such as specifying SMTP response behavior. While I know that > DKIM did this about SMTP, too, I suggest refraining from it here: > Specify and ARC engine and an overall ARC service that has inputs, > processing and output. Don't specify how those outputs are used. This is a basic scope question. > Detailed Comments: > The summary should provide a careful, constrained statement of the > narrow functionality that ARC provides. I suggest something along the > lines of what I offer, below, as "Replace An Authenticated with:". I think this goes to the basic concerns that Bron has expressed. That makes it a wg question, not editor task. >> the message content that was "covered" by the signature has not been >> altered since the signature was applied. The signatures themselves >> are generally independent of one another. > > That last sentence is true, of course, but I think I don't know what it > actually means or, more importantly, what it intends to imply. wg. > Hmmm. DKIM does it's signing with only a single field. ARC requires > -Seal and -Message-Signature. It isn't clear why two different > signature fields are required. Might be only an editorial issue, but given questions such as Bron has raised, I suspect there is a broader need to formulate wg clarity about it. >> At any delivery stage, it is an error if any ARC set is invalid >> (i.e., does not contain exactly one of the three header fields > > This sentence is out of place and it's import is unclear. It refers to > the set rather than to i=; so it shouldn't be in this section. And > there's no basis, yet, for knowing what 'an error' means in terms of > processing ARC. The essential point here is simply that a valid set > MUST contain all three header fields. Could be merely editorial, but again, I suspect there is a lack of wg clarity. >> 4.1. Valid Range for Instance Tags >> >> The 'i' tag value can range from 1-1024 (inclusive). > > Why 1024? > > >> ARC implementations MUST support at least ten (10) intermediary >> steps. > > I think this is meant to say 'ten (10) ARC sets.' > > >> More than fifty (50) intermediaries is considered extremely unlikely >> so ARC chains with more than fifty intermediaries may be marked with >> "cv=fail". > > may -> MAY > > Still, this is odd language for a specification, since its > non-determinimism ensures inconsistent behavior across implementation. > That always produces non-interoperability. > > Define a firm limit. Enforce it. > > Or... > > Absent the ability to agree on that limit, indicate that the operational > limit, if any, will be developed through field experience and documented > separately. Or somesuch. wg, not just editorial. >> 5.2. ARC-Message-Signature (AMS) >> >> The ARC-Message-Signature header field is defined. It is >> syntactically and semantically identical to a DKIM-Signature header > > The ARC-Message-Signature header field is defined. It is > -> > The ARC-Message-Signature header field is > >> >> >> Andersen, et al. Expires January 22, 2018 [Page 7] >> >> Internet-Draft ARC-Protocol July 2017 >> >> >> field [RFC6376], as is the mechanism by which it is constructed, with >> the following exceptions: > > [as is the mechanism by which it is constructed,] delete > > >> o There is an "i" tag, as described in Section 4. >> >> o There is no "v" tag. >> >> ARC-Seal header fields MUST never be included in the content covered >> by the signature in this header field. > > MUST never -> MUST NOT > > >> The AMS SHOULD include any DKIM-Signature header fields already >> present on the message in the header fields covered by this >> signature. >> >> The AMS header field MAY inclue (sign) the AAR header field(s). > > inclue -> include > > >> Authentication-Results header fields SHOULD NOT be included since >> they are likely to be deleted by downstream ADMDs (per Section XXX of >> [RFC7601]), thereby breaking the AMS signature. >> >> As with a DKIM-Signature, the purpose of this header field is to >> allow the ADMD generating it to take some responsibility for handling >> this message as it progresses toward delivery. > > What is the logic for the various MUST, SHOULD and MAY directives about > inclusion? What are the downsides of not following the SHOULD or MAY? wg. >> 5.3.2. Selected Header Fields >> >> The ARC-Seal signature is an encryption of the hash of the >> concatenation of the canonicalized form of the ARC sets present on >> the message at the time of sealing, in increasing instance order, >> starting at 1, including the one being added at the time of sealing >> the message. > > The above paragraph appears to be the only actual 'detailed' > specification of what an ARC signature is, and it is both obscure and > too dense. It needs to be re-formed into an algorithm specification. I > suspect it also needs to be moved to the section on signing. This could be merely editorial, but, again, the example of Bron's concerns suggests that the remedy needs to be a wg process. >> >> Within a set, the header fields are presented in the following order: > > presented -> listed > > >> 1. ARC-Authentication-Results >> >> 2. ARC-Message-Signature >> >> 3. ARC-Seal >> >> Where the ARC-Seal is the one being generated, it is presented 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. > > presented -> added (or input) > > >> Note that the signing scope for the ARC-Seal is modified in the >> situation where a chain has failed validation (see Section 9.3). >> >> 6. Verifier Actions >> >> The verifier takes the following steps to determine the current state >> of the ARC on the message: > > state of the ARC? perhaps ARC /chain/ or ARC signature chain? > > >> >> >> >> Andersen, et al. Expires January 22, 2018 [Page 9] >> >> Internet-Draft ARC-Protocol July 2017 >> >> >> 1. Collect all ARC sets currently on the message. If there were >> none, the ARC state is "none" and the algorithm stops here. >> >> 2. If any ARC set is invalid (e.g., does not contain exactly one of >> each of the three ARC-specific header fields), then the chain >> state is "fail" and the algorithm stops here. > > If any ARC set -> If the form of any ARC set > > This step is not doing computational validation; that's steps 3 & 4. So > I assume this step is for basic, structural validation. Essentially a > kind of syntax check. Maybe editorial, but I suspect wg clarity is needed. >> >> 1. To bypass all cryto and DNS operations, the cv value for all >> ARC-Seal(s) MAY be checked at this point. If any of the >> values are "fail", then the overall state of the chain is >> "fail" and the algorithm stops here. > > cryto -> crypto > > The 'bypass' sentence confused me a bit. I think what is intended is > something like: > > To avoid the overhead of unnecessary computation and delay, the cv= > value for all existing ARC-Seals MAY be checked at this point. If ... > > >> 3. Conduct verification of the ARC-Message-Signature header field >> bearing the highest instance number. If this verification fails, >> then the chain state is "fail" and the algorithm stops here. >> >> 4. For each ARC-Seal from the "N"th instance to the first, apply the >> following logic: ditto. >> 2. In Boolean nomenclature: if ((i == 1 && cv != "none") or (cv >> == "none" && i != 1)) then the chain state is "fail" and the >> algorithm stops here. > > Why is the i/cv ordering swapped for the two tests? editorial? > >> 3. Prepare a hash function corresponding to the "a" tag of the >> ARC-Seal. > > Where are the technical details for producing the hash formally > supplied? Cite them here. And what does the 'corresponding to the "a" > tag of the ARC-Seal' mean? > > >> 4. Compute the canonicalized form of the ARC header fields, in >> the order described in Section 5.3.2, using the "relaxed" >> header canonicalization defined in Section 3.4.2 of >> [RFC6376]. Pass them to the hash function. > > "Pass them to the hash function."? This appears to be specifying input > to a function that was performed (and presumably finished) in the > preceding step. editorial? > >> 5. Retrieve the final digest from the hash function. > > So I'm guessing that steps 4.3 - 4.5 are meant as a sub-function, but > nothing makes that explicit. At the least, 4.3 should say 'Start' > rather than 'Prepare" and possibly the substeps should have sub-numbering. editorial? > >> 6. Retrieve the public key identified by the "s" and "d" tags in >> the ARC-Seal, as described in Section 8. >> >> 7. Determine whether the signature portion ("b" tag) of the ARC- >> Seal and the digest computed above are valid according to the >> public key. > > How is this to be determined? Basic enough to need wg clarity. >> 7. Signer Actions > > This section appears to be the very broad strokes of implementation > guidance, rather than the details of a protocol specification. It's not > clear what benefit this is supposed to provide, but it doesn't seem to > have much to do with the semantics or interoperability of ARC. > > >> This section includes a walk-through of the actions an ARC signing >> implementation takes when presented with a message. > > walk-through -> specification > > Except that this doesn't really read like a formal specification, yet > one is needed. wg > > signing implementation -> signer > > >> The signing agent should undertake the following steps: > > should ->? SHOULD > > but why not MUST? wg. > >> 1. Do any authentication steps that the ADMD normally does: > > huh? /any/? What does this mean? Why is it relevant to this > specification? How is it used? > > >> 1. If a message is traveling within the same trust boundary, >> this would include any internal trust conveyed with the >> message; > > ; -> . > > >> 2. If a message is coming from outside the same trust boundary, >> this would include any SPF / DKIM / DMARC / other >> authentication evaluation steps. > > This document is not a specification or BCP for ADMD authentication. So > 1.1 and 1.2 really are out of scope (as well as providing inadequate > technical detail to be useful.) Doc scope. Wg, not just editorial. >> 3. Generate and optionally attach to the message an Authentication- >> Results header field using the ADMD's authserv-id (see >> Section 2.5 of [RFC7601]) indicating whatever authentication >> might have been done by the MTA, or possibly indicate that none >> was done. > > optionally? I suspect it's not optional, if they are participating in > ARC (and especially not if it's been generated. What benefit is there > in generating it if it is not then attached?) > > same concern for 'possibly'. This text needs to be cast into normative > specification language appropriate to a participant in ARC. wg. >> 9. Usage of ARC and Chain Validity >> >> 9.1. Relationship between DKIM-Signature and AMS signing scopes >> >> DKIM-Signatures SHOULD never sign any ARC header fields. > > Oh boy. That normative statements constitutes a formal modification to > the DKIM specification. While I understand the desire, I recommend > against pursuing it this way. > > Besides, I do not see the actual need for such a normative > specification. What is the harm in having a DKIM signature cover any > ARC header fields? wg? >> >> 9.4. Handling DNS Problems While Validating ARC >> >> DNS failures to resolve or return data which is needed for ARC >> validation SHOULD result in a 421 tempfail during the SMTP >> conversation with the sending system. Temporary or intermittent DNS >> problems will generally not be sufficiently transitory to allow a >> mediator to obtain a different result during the ordinary transit >> duration so it is better to have the source system queue the >> problematic message(s) than to generate (potential) backscatter. >> >> Operators of systems which mediate mail should be aware that broken >> DNS records (or malfunctioning name servers) will result in >> undeliverable mail to any downstream ARC-verifying ADMDs. >> >> DNS-based failures to verify a chain are treated no differently than >> any other ARC violation. They result in a "cv=fail" verdict. > > Hmmm. This section seems to be inviting two kinds of problems: > directing SMTP behavior and directing interpretation of DNS behaviors. > > I suggest, instead that the ARC protocol engine be defined in terms of > temporary failures and permanent failures and then specify what causes > each. How the containing email system should handle those two types of > failures should be out of scope for this specification. > > (I'm suggesting something different and more constrained than the DKIM > spec does.) wg. > >> >> 9.5. Responding to ARC Validity Violations >> >> 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. >> >> 9.6. Recording the Results of ARC Evaluation >> >> Receivers MAY add an "arc=[pass|fail|policy]" method annotation into >> a locally-affixed Authentication-Results [RFC7601] header field along >> with any salient comment(s). > > This seems to be augmenting RFC7601? wg. >> 9.6.2. Reporting ARC Effects for DMARC Local Policy - Interim > > I strongly urge moving all discussion of ARC use for DMARC into an > independent document. Keep the basic ARC specification a basic ARC > specification. Make DMARC policy discussion separate. definitely wg. >> 10. Supporting Alternate Signing Algorithms >> >> [[ Note: Some additional development of this section is needed. ]] >> >> In the following branch diagrams, each algorithm is represented by an >> 'A' or 'B' at each hop to depict the ARC chain that develops over a >> five hop scenario. 'x' represents a hop that does not support that >> algorithm. >> >> Note that during a transitional period where multiple algorithms are >> allowed, all of the statements in this spec which refer to "exactly >> one set of ARC headers per instance" need to be understood as "at >> >> >> >> >> Andersen, et al. Expires January 22, 2018 [Page 14] >> >> Internet-Draft ARC-Protocol July 2017 >> >> >> least one set per instance and no more than one instance-set per >> algorithm". > > This is an essential restriction/capability and need to be moved to be > part of the original specification. There are a few different ways to > phrase this and I'm not sure which would work best. wg! >> 10.1. Introductory Period >> >> Intermediaries MUST be able to validate ARC chains build with either >> algorithm but MAY create ARC sets with either (or both) algorithm. > > build -> built > > >> The introductory period should be at least six (6) months. > > This has no context nor justification. I assume the section is > attempting to talk about the introduction of new signing algorithms and > the need to support overlapping use of old and new and the fact that > transitions on the Internet take a long time and a signer using a new > algorithm needs to assume it might take awhile for all of their > receivers to also support it and... wg. > >> 10.2. Co-Existence Period >> >> Intermediaries MUST be able to validate ARC chains build with either >> algorithm and MUST create ARC sets with both algorithms. Chains >> ending with either algorithm may be used for the result. > > Take this out of normative mode, since it's impractical. The whole > reason that an extended transition period is needed is because a > requirement like the above won't happen (and in fact can't.) wg. >> 10.3. Deprecation Period >> >> ARC sets built with algorithms that are being deprecated MAY be >> considered valid within an ARC chain, however, intermediaries MUST >> NOT create additional sets with the deprecated algorithm. > > Where are the specifications for the procedures to register and > deprecate algorithms? Why aren't they cited here? > > >> The deprecation period should be at least two (2) years. > > I fear that this section is mostly gratuitous, since it doesn't have > much import. If someone thinks otherwise, would they please explain > what effect any of this will have on developers or operators? wg d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Aug 11 09:24:12 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1D6813201E for ; Fri, 11 Aug 2017 09:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHBvXsS_j77D for ; Fri, 11 Aug 2017 09:24:08 -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 D4390127201 for ; Fri, 11 Aug 2017 09:24:07 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id t201so45442248wmt.1 for ; Fri, 11 Aug 2017 09:24:07 -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=mb3bVyWJaG0Ed56FyeJuyU7+dcvPSoLv63DkgzhcGeQ=; b=QAb5GDuJqbDvnHZgdN5pC1IqK+J92Dyu+5Ed0pWtd2HZejGr33OgGXP4HU2SGjUns6 wifcuvvkm+1nLFPnbLiSIGQx9aU6OirqYlPlMoaPxcTzBPytU1zP7FEsC9lW9HXevEZ+ 12kkm3J6L77wK05KF1SiXNE8z9yALeLuoDCkk= 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=mb3bVyWJaG0Ed56FyeJuyU7+dcvPSoLv63DkgzhcGeQ=; b=dASZNycU1qbK/roaJwUwsah6dzwSLYwL06vjzHSrmAiD0e1Wmu9XqE4jGjCQDBWDdL AFOU00cWPyDK3RyoX/f6qBQmpolSEJPxf1oKPj8rveUWbzw8Z03tlmBqZoOqaYnNtm8x K3dXTJS+edn7jraETG9RKlMVeERuOUK7wHa/XG2aEaBJrapoXe7dADo1lNoZS9ZSSG95 uKiAeHAFweOFV8YcdanPuULmPK/1ImSNQQQgSuSfMaEUiGwEeAz+lKvRpIBp1Hb5tx/H 1xmsPlI3+5WiYp9qC5swT42csZqohU1J2dCbrODO8cXDMdl13d8Ej53NWORgnKmIpepw sXJQ== X-Gm-Message-State: AHYfb5hIkFBFH1laKPj3Qo95A6lcdPGRjhEpx/qp815bEpBGMy/AmHA7 CmPiIMMfO9GKcjgKzkCpPfBdXHxiDCB/ X-Received: by 10.80.170.213 with SMTP id r21mr16557519edc.208.1502468646138; Fri, 11 Aug 2017 09:24:06 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.80.178.229 with HTTP; Fri, 11 Aug 2017 09:24:05 -0700 (PDT) In-Reply-To: <77ae9638-7a10-1165-f2fd-ce8e53fee3d4@gmail.com> References: <77ae9638-7a10-1165-f2fd-ce8e53fee3d4@gmail.com> From: "Kurt Andersen (b)" Date: Fri, 11 Aug 2017 09:24:05 -0700 X-Google-Sender-Auth: BjRcGz-llwUrU6KrzAOQ3D74iyk Message-ID: To: Dave Crocker Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c19a464f089c405567cbd1a" Archived-At: Subject: Re: [dmarc-ietf] Review of: draft-ietf-dmarc-arc-protocol-08 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, 11 Aug 2017 16:24:10 -0000 --94eb2c19a464f089c405567cbd1a Content-Type: text/plain; charset="UTF-8" On Fri, Aug 11, 2017 at 8:28 AM, Dave Crocker wrote: > Folks, > > I posted my review 2 weeks ago and haven't seen any responses. > > From some offlist exchanges, I think some believe the review responses are > merely editorial. They aren't. I did see your post, but have not yet had enough time to engage effectively with it. I've also started working through the feedback from Alexsy but jury duty this week and $dayjob responsibilities have slowed my progress on that as well. --Kurt --94eb2c19a464f089c405567cbd1a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Aug 11, 2017 at 8:28 AM, Dave Crocker <dcrocker@gmail.com> wrote:
Folks,

I posted my review 2 weeks ago and haven't seen any responses.

>From some offlist exchanges, I think some believe the review responses are = merely editorial.=C2=A0 They aren't.

I = did see your post, but have not yet had enough time to engage effectively w= ith it. I've also started working through the feedback from Alexsy but = jury duty this week and $dayjob responsibilities have slowed my progress on= that as well.

--Kurt=C2=A0

<= /div> --94eb2c19a464f089c405567cbd1a-- From nobody Fri Aug 11 09:27:09 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEE19132376 for ; Fri, 11 Aug 2017 09:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZQsh3S21RVB for ; Fri, 11 Aug 2017 09:27:04 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A46F91321A1 for ; Fri, 11 Aug 2017 09:27:04 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id f11so37855539oic.0 for ; Fri, 11 Aug 2017 09:27:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=9VKkxUrrMSa/lOKfV83QU3Z2gPEp/hkRfXBjMQ0/cZw=; b=YRdh6PDSlA1ElGINtBTzHTsBHGkmLQy8hbTzT7l0LJxIcqNsLBQ7UYVfsnhnXBC0i1 DlLULj+yqPizHJ+FTMC9Rc0S+UIC3mHo/SnocnSPo3g4utuOKYSwcljV4xniCtZ1uWxa XlGnm260bYa7yTMk/J68Z1Rnu9t9i7Sk+9wF3k+0jMNHCWegoCHdaeOJMD8Z1DQUg+oI YJXK+8WiiSopLVLwKjkGv+aKefhiUyenjOaOI4udIuFwDxi9+YzCiHuON+VJnbHAScNh m9mSDKqWZLknOyKqpYLGIJa1B7cYAJw0NJwguQ6PDuC+xPNN3p4GBwRDP7UUs/QvRwof V7Hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=9VKkxUrrMSa/lOKfV83QU3Z2gPEp/hkRfXBjMQ0/cZw=; b=XdUt7ik7TEtQyJiLyDysSz//Yf5I19A+c4Giiwh+yEnLB+WZU47A2WV+G8gUTEI3iv qlzxQ+s2Y7fIkrj8JnUd9iz5JjBxFzyqrvbP2ACIKvPsAT2fS3qGei7071pzgjx9Zy6x klCLuPNd9pOKyD00TqnCWoOhhn9PlUJY8lqoFyl9wIWsS9oWfpE3O6jTnI59/pOygrPG WBK8A3D6fq3PHYEfDeLqMX1WJthtZkGjNq2nyI2ZC6TDGLioIWTL+8SgoveQut1q9lyz E4KSqYOOeDYb5ZG44r9tTENAAzSDi4AeTTkBjtiIvdMOJ8DwAx8EfLZoPrEGzwOP7WlR 7jzQ== X-Gm-Message-State: AHYfb5gZQSMH/ttswkeE0DNE5XLRD45IXCUjQq+RpQox8FKlZcV/6CfC Xd6F11Qzxd36ZdlmXdY= X-Received: by 10.202.198.23 with SMTP id w23mr17068210oif.168.1502468823633; Fri, 11 Aug 2017 09:27:03 -0700 (PDT) Received: from ?IPv6:2602:304:cda0:8800:d17e:7fe3:9cb7:7c98? ([2602:304:cda0:8800:d17e:7fe3:9cb7:7c98]) by smtp.gmail.com with ESMTPSA id x23sm1043037oix.51.2017.08.11.09.27.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Aug 2017 09:27:02 -0700 (PDT) To: dmarc@ietf.org References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> From: Dave Crocker Message-ID: <89f1a978-0cc6-f7f3-5d3d-0ccd67341369@gmail.com> Date: Fri, 11 Aug 2017 09:27:01 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre 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, 11 Aug 2017 16:27:07 -0000 On 8/9/2017 3:26 PM, Bron Gondwana wrote: > I do feel like nobody understands what the hell I'm trying to say here > based on the responses I've seen so far, so maybe I do actually need to > find an existing ARC-Sealed email and forge a change to it. Seth asked > to have a phone chat about this, and I'm happy to have a phone chat with > anybody if it will help explain my point. I've been mulling over this thread for some days. A challenge in writing an IETF spec is to make sure the text is adequately understandable to folk who weren't part of the original specification effort, yet still can produce interoperable systems. And will know why they should and what benefit will accrue if they do. I think the current document does not provide enough information for this. I wanted to try to generate some candidate text that would respond to the concerns that Bron has raised, but find that I'm not (yet) clear enough about underlying details of ARC. I don't mean technical details, I mean conceptual basis. (And this is in spite of my having been a participant in ARC development from the start!) So I'm now going to ask for a discussion that produces at least bits of text. When there is convergence on those bits, I'm glad to offer to assemble them into some sort of "Concepts and Facilities" summary of ARC. Here's the task I see: * Talk about ARC in non-technical terms, describing not just its abstract goal but the nature of how it achieves those goals, in terms of threats it is responding to, capabilities that it is responding to, and limitations to those capabilities. This discussion needs to look for leaps of faith and other points of confusion or implicit assumption, and it needs to resolve them. * This needs to include reference to the concept of 'trust' as an operational attribute. * There also needs to be statements about the operational history upon which ARC builds -- that is, what is it doing that is well-founded -- and what it is doing that is new. * For the parts that are 'new', there needs to be statements the provide explain why it is reasonable to be optimistic that deployment and use will be safe and useful. Thoughts? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Aug 11 09:29:25 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D41181321C0 for ; Fri, 11 Aug 2017 09:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B39IhONEoiRZ for ; Fri, 11 Aug 2017 09:29:22 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D54321321D0 for ; Fri, 11 Aug 2017 09:29:21 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id e124so38057459oig.2 for ; Fri, 11 Aug 2017 09:29:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=d+B+PEqQ6Y9ubR1VwR+BvJYdMQNIV3Gb2W2qpD/if5w=; b=ofnCXgU9Utp5n1wt5HRQbZKxLhpEQpc8m23mFw9S0tFvJw0jVnfGT7UwXxNzvXijvG 5TeoH45A30nqLeB4KlG7av6cr4DGkHhU6Lv6Uibn/ensDkX11u0e8iPOE5JWHcRh2iOz 2buqzHKr07OgOylYZKwW7FmLsHsSh0B3OLcVWl97k6UkETrSfUYFUmPw3fKsZW7gQeMh DKGD2cJhLWuUhaSLFX/pVt7tyeHiTYPwrou7leNNRsYIWmLi5BiixvL1lllc/z3S9K8R H/l3S735zYCn/FJ7J6hh/mgrCyX04yS5N4brGEvvaH2Ph0J1atjD04nT5R9K9GmbEyi2 YRpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=d+B+PEqQ6Y9ubR1VwR+BvJYdMQNIV3Gb2W2qpD/if5w=; b=og2ttovhIFLSBez9oemJ+wzYSJ3tewfAX2jA1Zbsiv10/5lAypU0GtkxgOoiUQPeI5 pS3j0aBPC5VWwSLYQxfBCI8k8z2gaXmSgjrapqTpbewQO9XVw7BN+qPJTnHIhYJd/YYN TLvriBih7xx7N4JymB3ukRGGidZ0WzjDaDWoU2YMYJ7hTJ4ppNMbo550XRJRk1zOnJQe ClLHyWhJIheoy+V2ipzvkczK42EfA55KAf14LgOiihPirBJR6IlLUf8YNj7pbxHPmHW2 N8hBw7ktjJWZejQk8Y3nReFrEqRVDNEzrNsa9S++pjxTPcd/rKBeunhhHG0pg5xixv42 FomA== X-Gm-Message-State: AHYfb5h5NywMLY7GHTbegrzVtOvwwDsF5Ll5KH+CMW04WRzBpzIXCc63 kZKdP6r3/EYSuEAY8QA= X-Received: by 10.202.93.215 with SMTP id r206mr17401536oib.139.1502468961000; Fri, 11 Aug 2017 09:29:21 -0700 (PDT) Received: from ?IPv6:2602:304:cda0:8800:d17e:7fe3:9cb7:7c98? ([2602:304:cda0:8800:d17e:7fe3:9cb7:7c98]) by smtp.gmail.com with ESMTPSA id s68sm1146533oie.16.2017.08.11.09.29.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Aug 2017 09:29:20 -0700 (PDT) To: "Kurt Andersen (b)" Cc: "dmarc@ietf.org" References: <77ae9638-7a10-1165-f2fd-ce8e53fee3d4@gmail.com> From: Dave Crocker Message-ID: Date: Fri, 11 Aug 2017 09:29:18 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Review of: draft-ietf-dmarc-arc-protocol-08 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, 11 Aug 2017 16:29:24 -0000 On 8/11/2017 9:24 AM, Kurt Andersen (b) wrote: > I did see your post, but have not yet had enough time to engage > effectively with it. I've also started working through the feedback from > Alexsy but jury duty this week and $dayjob responsibilities have slowed > my progress on that as well. Such messed up priorities. Tsk. But ack and tnx. But since my understanding is that you are doing primary editing, also note that, really, this morning's note was meant as a prod to others, not you... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Aug 11 09:34:31 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C888713257A for ; Fri, 11 Aug 2017 09:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFK-aJ6fL0XW for ; Fri, 11 Aug 2017 09:34:26 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E654813264B for ; Fri, 11 Aug 2017 09:34:24 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id t201so45626864wmt.1 for ; Fri, 11 Aug 2017 09:34:24 -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=gtu7YLsm1ja9AFl4yoZgnaYo0SyWhvjRoMmJJjGHCuI=; b=K+/5vFZhV1agDKPzLc4IN9Kl6ldFPWfjr7MLunKimALdIbyYo3U70sbitV4OmUu7Qv BBv5p4YbU3T15Pf8SFrGX2efRldpFMxzDiYHYhmZi9X2B2E5EUepR2RmiAgE0Z92ws1q HAJeEU0pSzCSzY85h9bQJDJHEDJN4XAoWTVA8= 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=gtu7YLsm1ja9AFl4yoZgnaYo0SyWhvjRoMmJJjGHCuI=; b=eONVJqEW3LoBAK8gFObhfNU7Uu9X7xALuuUSMGVM56CosP/vsxjKPTuMlAkNjQ7LbY X0fvpHDaCqc1pdTsdc2uYUfdQrpOysJh8sUcDxhEkWEMYgUqGvjL2UFQJXPsr/mUye7Y m6Ye+Aaov2sW8pDOyMNg9COvSGex+cFRcRcJT1wQ+LA6kVeHG8XZf4oOaMRioJuKmcUi KHvtUFVJBnRw/6hgT9DV/lEAAZFemIr7KuLhGmJ596VRBWY1X3UQLhVNwkahl8ZcnaQb jNKMuszufnyiJMaOTzkNe0vmOoh6rp5j4oMI4vezliVzb6hj3qw60USPbDa3Jrd94kUO ObwQ== X-Gm-Message-State: AHYfb5ip18ByBJI5E0/4YEaACIBn8A6g8hrgGKAPHKx9oXBzIcm1rUln XKkei6OAFM4gESr8lkQJmK51W67jEjqh X-Received: by 10.80.166.133 with SMTP id e5mr16078805edc.71.1502469263416; Fri, 11 Aug 2017 09:34:23 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.80.178.229 with HTTP; Fri, 11 Aug 2017 09:34:22 -0700 (PDT) In-Reply-To: <89f1a978-0cc6-f7f3-5d3d-0ccd67341369@gmail.com> References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> <89f1a978-0cc6-f7f3-5d3d-0ccd67341369@gmail.com> From: "Kurt Andersen (b)" Date: Fri, 11 Aug 2017 09:34:22 -0700 X-Google-Sender-Auth: j8hdSUtjDnYKBz68jKwHLYJ9GTU Message-ID: To: Dave Crocker Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0dd11ebb75f205567ce227" Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre 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, 11 Aug 2017 16:34:28 -0000 --94eb2c0dd11ebb75f205567ce227 Content-Type: text/plain; charset="UTF-8" On Fri, Aug 11, 2017 at 9:27 AM, Dave Crocker wrote: > > I wanted to try to generate some candidate text that would respond to the > concerns that Bron has raised, but find that I'm not (yet) clear enough > about underlying details of ARC. I don't mean technical details, I mean > conceptual basis. (And this is in spite of my having been a participant in > ARC development from the start!) > > So I'm now going to ask for a discussion that produces at least bits of > text. When there is convergence on those bits, I'm glad to offer to > assemble them into some sort of "Concepts and Facilities" summary of ARC. I think that we have that sort of information scattered around in various non-spec presentations that have happened regarding ARC. Do you consider this to be something that should be tackled before or after the "intent"-related notes in your earlier review notes from the end of July? --Kurt --94eb2c0dd11ebb75f205567ce227 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Aug 11, 2017 at 9:27 AM, Dave Crocker <dcrocker@gmail.com> wrote:

I wanted to try to generate some candidate text that would respond to the c= oncerns that Bron has raised, but find that I'm not (yet) clear enough = about underlying details of ARC.=C2=A0 I don't mean technical details, = I mean conceptual basis.=C2=A0 (And this is in spite of my having been a pa= rticipant in ARC development from the start!)

So I'm now going to ask for a discussion that produces at least bits of= text.=C2=A0 When there is convergence on those bits, I'm glad to offer= to assemble them into some sort of "Concepts and Facilities" sum= mary of ARC.

I think that we have that sort= of information scattered around in various non-spec presentations that hav= e happened regarding ARC. Do you consider this to be something that should = be tackled before or after the "intent"-related notes in your ear= lier review notes from the end of July?

--Kurt=C2= =A0

--94eb2c0dd11ebb75f205567ce227-- From nobody Fri Aug 11 10:19:35 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7E2E13232C for ; Fri, 11 Aug 2017 10:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIZOVnzoQbBV for ; Fri, 11 Aug 2017 10:19:32 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA2061321F5 for ; Fri, 11 Aug 2017 10:19:31 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id x3so39236815oia.1 for ; Fri, 11 Aug 2017 10:19:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=0jk/igQVPM5D/CsX7Cek0kWxTrZrEtWOVyXt9m98U/0=; b=X/CFOrLtGGy2PMBBbCIVybaatnv4t5w+2irB9vLQk28YxAuCvoUTvsi8p9U1MYemdj 7Vqw749O2Q7QEaZ7N1HcXupHXgLjJDbNyiyJ/bNdJO0Iy+q9bJqr9nmdqhN0IOUW110Q 8XJ6GbawzKoeY9KeQhMX1UhJlKP0BRru0y8Die35Nu0dxtC5FGQpg1mzJ6186iUvZJU7 z4yvY6pS8Miqo3upNoSnJvPZ0rWJSf/c/nmXvH2YtkLYHZIi9w8FsPqHe1gqAhyIDQj8 KYtBvu1Wn6dS/CM+gQdNPvWVVJ6I2lMuYHdrZrIptIqnQxQjbPW4igIKL7wHZAMpMW90 g6xA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=0jk/igQVPM5D/CsX7Cek0kWxTrZrEtWOVyXt9m98U/0=; b=bTBUp4Ovatg4c3bg2yidTmlM7xlr/1K9KpRGfAaIjIS0j11/4hmNK0yIx9I4P89QWO bVGjx39hW1cG4J+BFBhRiVQ/1f+muaYWZ8vFYoJszEODscR73AFH3Ah4wwETOucpG6wN LHNYQ1etUvZo1vq1QpcHUzP2c1yrp4j0QuRl6SwFWykBc6/QIJlFYViG2pPaCi7ImIHM Hw4D0tSCyF+ud0kKqQAwOVPeFhoByJKNhMLIVi8cBCUdnTj334T5jgV17K0pGTskOXbK jAqWVKyBEqABAXSOz7RijEur5ovYtfSNNk+imN2qEzrUgMQcYHcrBThCss4dK9U0wuR1 PEiw== X-Gm-Message-State: AHYfb5i++slLnTxqZUefbMBBPTtlY9TL95/P4nWM8a0UmDZt8ZV5kx4G GLU5+XyMS/Jy2CgJOCc= X-Received: by 10.202.53.131 with SMTP id c125mr19505764oia.89.1502471970796; Fri, 11 Aug 2017 10:19:30 -0700 (PDT) Received: from ?IPv6:2602:304:cda0:8800:d17e:7fe3:9cb7:7c98? ([2602:304:cda0:8800:d17e:7fe3:9cb7:7c98]) by smtp.gmail.com with ESMTPSA id 64sm1053298oif.42.2017.08.11.10.19.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Aug 2017 10:19:29 -0700 (PDT) To: "Kurt Andersen (b)" Cc: "dmarc@ietf.org" References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> <89f1a978-0cc6-f7f3-5d3d-0ccd67341369@gmail.com> From: Dave Crocker Message-ID: <4a8d9564-ba0c-9c9b-7a23-ab6340fd2400@gmail.com> Date: Fri, 11 Aug 2017 10:19:28 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre 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, 11 Aug 2017 17:19:34 -0000 On 8/11/2017 9:34 AM, Kurt Andersen (b) wrote: > I think that we have that sort of information scattered around in > various non-spec presentations that have happened regarding ARC. Do you > consider this to be something that should be tackled before or after the > "intent"-related notes in your earlier review notes from the end of July? I think it's compatible with some of the concerns I raise and so should be pursued at the same time. I'm hoping that the exercise will produce much better clarity and coherence and widespread understanding of what ARC will and will not do. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Aug 11 10:23:04 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE23124234 for ; Fri, 11 Aug 2017 10:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmnCYULgsjIs for ; Fri, 11 Aug 2017 10:23:01 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9EF2132192 for ; Fri, 11 Aug 2017 10:23:01 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id e124so39338952oig.2 for ; Fri, 11 Aug 2017 10:23:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=ScjwJNLr0f5fb9sWE/Gh/hJNOiktiNPbKPIZRyuw9fI=; b=ukxNMOOj9uNCbNNU7rM1JUFEpzNPi51I1WL4ZbISZlNM8nokKfWf2FDQ04Gp3zWdvv q70xfl75HVY6ntfWiYpNfaiupadGH5z8CsQ3YcMXa+L+RggEE1v8OpUXaGOLNAwiNlw8 yM9GfiKJNHZ5fy1Wc+G9Abn9IFF/zcd473Lkoes4QQcWeVnDkwcpTGQ4KzqYO5WzFvhm io0hCbVaKdeYctrkA5OeYOAGVWHMUUrjq7pHZW6VsHSdgXwKK/DhYJ7Tk26mwwnLyXb8 BNjPddCBhb5PUrLoa13LkL05ZFqCT30lAiEvaK7z0QwtsVIWqhah/FEqhY0/qnOOMoM+ KCPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ScjwJNLr0f5fb9sWE/Gh/hJNOiktiNPbKPIZRyuw9fI=; b=PdTHKZ4uULWxAA64bO5cwFcoyMBEqoE8TX3UKX6IT0IYOobX0UK5ktKx5BZSLa5I9f mn76Z1+c7b09vImVjzKqtCCePV5HxKe7SFDrQlRgEh2LwVell8DCn/zDeIEsSh2u4Bej YZXOoXFDvIpXfttes8F/SPo15nMNcwr7wmdnGaxjvtuikNVNRyMgG5D3IdRVdNDf45y0 MI1gOLyPQcbn+Db/IVaoukv2Rk3LcolIGzqdG7+nEyV59yWgeehd6g9Y8eBJTcrXKR/T 8SsVPtfFv2AoUb96jYLNdillWgsdaSZj52cK2+l9cckjqLbadRfnFPzyNouS2HxE2jvI nRXA== X-Gm-Message-State: AHYfb5hNCsqElJNtgODb0U7GQQLLBltqm1nJLbgYJR4v4RSpS6XBFq35 m+JTvRtvhCiwV3Q97zY= X-Received: by 10.202.242.2 with SMTP id q2mr15800508oih.71.1502472180781; Fri, 11 Aug 2017 10:23:00 -0700 (PDT) Received: from ?IPv6:2602:304:cda0:8800:d17e:7fe3:9cb7:7c98? ([2602:304:cda0:8800:d17e:7fe3:9cb7:7c98]) by smtp.gmail.com with ESMTPSA id x23sm1184983oix.51.2017.08.11.10.22.59 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Aug 2017 10:22:59 -0700 (PDT) From: Dave Crocker To: dmarc@ietf.org References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> Message-ID: Date: Fri, 11 Aug 2017 10:22:58 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre 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, 11 Aug 2017 17:23:03 -0000 On 8/11/2017 9:26 AM, Dave Crocker wrote: > Here's the task I see: > > * Talk about ARC in non-technical terms, describing not just its > abstract goal but the nature of how it achieves those goals, in terms > of threats it is responding to, capabilities that it is responding > to, and limitations to those capabilities. > > * This needs to include reference to the concept of 'trust' as an > operational attribute. > > * There also needs to be statements about the operational history > upon which ARC builds -- that is, what is it doing that is > well-founded -- and what it is doing that is new. > > * For the parts that are 'new', there needs to be statements the > provide explain why it is reasonable to be optimistic that deployment > and use will be safe and useful. Possibly-useful examples that already showed up in this thread: On 8/7/2017 4:22 PM, Seth Blank wrote: > ARC is about maintaining a chain of custody so that a final receiver > can be certain of which domains modified a message in transit. Like > DMARC, DKIM, and SPF, we're trying to ascertain if the message was > handled by the domain it said it was handled by - we're not passing > judgement on the contents of the messages itself. On 8/7/2017 4:22 PM, Seth Blank wrote: > When validating an ARC signed message, one verifies the latest AMS > (which must validate), and *the entire chain* of ARC Seals, not only > the latest. This guarantees you a list of all message signatories - > the chain of custody we're talking about. > > When evaluating the chain for final receipt, there are two states to > worry about as a matter of local policy: 1) you trust all the > signatories on the chain 2) there is an untrusted signatory on the > chain > > In state #1, you're done - if you trust the signatories then you > trust they're not playing games with the AMS and AAR contents or > manipulating the message in malicious ways. Now you can make a > delivery decision as local policy dictates. > > In state #2, you're also done - if you don't trust all the > signatories, then there are a multitude of routes for the message to > be garbage, including but not limited to everything you've outlined > above. > > The critical thing about the ARC Seal is that it guarantees this > behavior in state #1 - if you trust all the d= values in the ARC > Seals, they all validate, and you have cv=pass, then you know for > certain everyone who has manipulated the message (and maybe some who > handled but did not modify). > > Without the ARC Seal this determination is not possible and there is > no way to evaluate the ARC chain for delivery as a final receiver. On 8/7/2017 7:41 PM, John Levine wrote: > Since it only makes sense to look at the ARC chain on mail that > comes from senders that are generally reliable, I've asked why you > don't just whitelist those senders and be done with it. > > The answer, at least at very large mail systems, is that a mailing > list sends nice clean mail, but then it starts forwarding lots of > spam. I've seen this on some of the ICANN lists where someone got > his address book stolen that had both the lists and individuals' > addresses, so we're now getting mail through the lists with faked > addresses of a frequent participant. ARC passes along info from > previous hops so the recipient can retroactively do filtering that > the mailing list didn't. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Aug 11 16:54:13 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBFC6132350 for ; Fri, 11 Aug 2017 16:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=KzLBn7GW; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VzF9yK/Q Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTMq8A3qHPOz for ; Fri, 11 Aug 2017 16:54:07 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DEB6132335 for ; Fri, 11 Aug 2017 16:54:07 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id F056620C01 for ; Fri, 11 Aug 2017 19:54:06 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Fri, 11 Aug 2017 19:54:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=QseEUcgjP9SwUAfIO rKEp+JAirvv4+PfLSjjLR+HJk4=; b=KzLBn7GWCiyQ45UOUhgL9XJxfhYI9Uzp3 OOleTFxB/BhXm6YDHm4FHfhzQfjN12CwiOvVG1TyekCUOpdDfxOSjyBXzsv6p6+0 r+qgPXGCgUAFz25FHu5JmBwQ7rrczopjWeERY1y0iZjHE94H7tqF3OmyC7HYAmNY t6mKUG/SkTI4PjpORNJ7nJ7qGW5Xgc1E5+XHrHnMf2R6jFM9lECmMmxS1bOte26R fd3n2AogJdPRousuAnl5gDpWKI6TGihLHsX+A4auyEpL8zm9yygAnN+s1L1Qn1G0 BApr2GOjxP4IPKlZz6qfh38gDs56UdXU5xjvl0dk4zs0KSLH7LfxA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=QseEUc gjP9SwUAfIOrKEp+JAirvv4+PfLSjjLR+HJk4=; b=VzF9yK/QVGDwAY/YzX3qwe xWUFUdGpkWTSQOKBb9nfxsNO49Xazpak2GE3VGSDcz+5WOLdIVtAQPFJCZXWjPeb yYyr5Te55MJS9MH8HNGY8LJkHrQ1B90+aZ2FNeuZ4tJ6dDaslxqNhvIN2Bn/IhVm 0mp5PFF/4/lelDgFX6Hfmf/m6a2wBjwvPJLIZpApZWIMVPR8LdqOLXR4LYwDYaP9 xvpRiLuTTyEK0a1jCoydAkosRGqVGiB0JlDS2WPrw5tqCCaD+y+JNqYjwSPKGLFk pttq1bWGLJj7DncAv7F/Ial+apF0mbm4H0zeuNCB69QCojAtBkRHnVIMzcupST2g == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id B5D60BAB71; Fri, 11 Aug 2017 19:54:06 -0400 (EDT) Message-Id: <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> From: Bron Gondwana To: dmarc@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/mixed; boundary="_----------=_150249564640991763" X-Mailer: MessagingEngine.com Webmail Interface - ajax-33d44821 References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> Date: Sat, 12 Aug 2017 09:54:06 +1000 In-Reply-To: Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre 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, 11 Aug 2017 23:54:12 -0000 This is a multi-part message in MIME format. --_----------=_150249564640991763 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150249564640991762" This is a multi-part message in MIME format. --_----------=_150249564640991762 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Sat, 12 Aug 2017, at 03:22, Dave Crocker wrote: I'm just picking out the key quote here: > On 8/7/2017 4:22 PM, Seth Blank wrote: >> When validating an ARC signed message, one verifies the latest AMS >> (which must validate), and *the entire chain* of ARC Seals, not only>> the latest. This guarantees you a list of all message signatories - >> the chain of custody we're talking about. Yes, I follow this bit, but then... >> When evaluating the chain for final receipt, there are two states to>> worry about as a matter of local policy: 1) you trust all the >> signatories on the chain 2) there is an untrusted signatory on the >> chain Which is why it's a bad idea to sign if you're not modifying, because then everybody has to trust you or their chain breaks, even though you didn't do anything which required signing. >> In state #1, you're done - if you trust the signatories then you >> trust they're not playing games with the AMS and AAR contents or >> manipulating the message in malicious ways. Now you can make a >> delivery decision as local policy dictates. Agree. >> In state #2, you're also done - if you don't trust all the >> signatories, then there are a multitude of routes for the message to>> be garbage, including but not limited to everything you've outlined >> above. Agree. >> The critical thing about the ARC Seal is that it guarantees this >> behavior in state #1 - if you trust all the d= values in the ARC >> Seals, they all validate, and you have cv=pass, then you know for >> certain everyone who has manipulated the message (and maybe some who>> handled but did not modify). In state #1, you don't need a chain of ARC Seal. You just need each site to sign their own AAR and each AAR to include "arc=pass" for the previous AMS. You trust the sites, so you trust them to verify the ARC status on ingress. So ARC Seal isn't adding anything other than complexity. I'm not saying "ARC Seal doesn't work in case #1" - I'm saying "ARC Seal is security theater in state #1". It's overly complex and adding no value. >> Without the ARC Seal this determination is not possible and there is>> no way to evaluate the ARC chain for delivery as a final receiver. And this is the crux of our disagreement. Seth thinks it's necessary to do more than signing a statement that you believed the message was authenticated when you got it, in a way that the next hop can verify your signature over your own Authentication Results plus the content of the message. I disagree. I'm proposing exactly the same stragety DKIM uses, just with series of signed "chain of custody" statements rather than the DKIM signature having to align with the sender domain. What has no value is a chain of ARC-Seal that has to stretch right back to the start, because all that is doing is signing its own crypto and some headers that can be trivially transplanted from another message. If this list allows messages with attachments, you'll see a copy of "signedforgery.txt" which has me pretending to be Kurt with the complex test message he gave me in Prague. I've forged the Subject and Body, and then Sealed it as brong.net. brong@zula:~/src/mail-dkim$ perl arc.pl < signedforgery.txt pass ARC-Seal: v=7 pass ARC-Message-Signature: v=7 pass ARC-Seal: v=6 pass ARC-Message-Signature: v=6 fail (message has been altered) ARC-Seal: v=5 pass ARC-Message-Signature: v=5 fail (message has been altered) ARC-Seal: v=4 pass ARC-Message-Signature: v=4 fail (message has been altered) ARC-Seal: v=3 pass ARC-Message-Signature: v=3 fail (message has been altered) ARC-Seal: v=2 pass ARC-Message-Signature: v=2 fail (message has been altered) ARC-Seal: v=1 pass ARC-Message-Signature: v=1 fail (message has been altered) The fact that there is an intact chain of ARC-Seal is pointless here. And as I have (hopefully successfully) argued above, if all the sites are trusted and they each successfully cryptographically authenticate the previous sender (or SPF at the first hop), you need is the AMS. ARC- Seal does nothing. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_150249564640991762 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Sat, 12 Aug 2017, at 03:22, Dave Crocker wrote:

I'm just picking out the key quote here:

On 8/7/2017 4:22 PM, Seth Blank wrote:
When validating an ARC signed message, one verifies the latest AMS
(which must validate), and *the entire chain* of ARC Seals, not only
the latest. This guarantees you a list of all message signatories -
the chain of custody we're talking about.

Yes, I follow this bit, but then...

When evaluating the chain for final receipt, there are two states to
worry about as a matter of local policy: 1) you trust all the
signatories on the chain 2) there is an untrusted signatory on the
chain

Which is why it's a bad idea to sign if you're not modifying, because then everybody has to trust you or their chain breaks, even though you didn't do anything which required signing.

In state #1, you're done - if you trust the signatories then you
trust they're not playing games with the AMS and AAR contents or
manipulating the message in malicious ways. Now you can make a
delivery decision as local policy dictates.

Agree.

In state #2, you're also done - if you don't trust all the
signatories, then there are a multitude of routes for the message to
be garbage, including but not limited to everything you've outlined
above.

Agree.

The critical thing about the ARC Seal is that it guarantees this
behavior in state #1 - if you trust all the d= values in the ARC
Seals, they all validate, and you have cv=pass, then you know for
certain everyone who has manipulated the message (and maybe some who
handled but did not modify).

In state #1, you don't need a chain of ARC Seal.  You just need each site to sign their own AAR and each AAR to include "arc=pass" for the previous AMS.  You trust the sites, so you trust them to verify the ARC status on ingress.

So ARC Seal isn't adding anything other than complexity.  I'm not saying "ARC Seal doesn't work in case #1" - I'm saying "ARC Seal is security theater in state #1".  It's overly complex and adding no value.

Without the ARC Seal this determination is not possible and there is
no way to evaluate the ARC chain for delivery as a final receiver.

And this is the crux of our disagreement.  Seth thinks it's necessary to do more than signing a statement that you believed the message was authenticated when you got it, in a way that the next hop can verify your signature over your own Authentication Results plus the content of the message.  I disagree.

I'm proposing exactly the same stragety DKIM uses, just with series of signed "chain of custody" statements rather than the DKIM signature having to align with the sender domain.

What has no value is a chain of ARC-Seal that has to stretch right back to the start, because all that is doing is signing its own crypto and some headers that can be trivially transplanted from another message.

If this list allows messages with attachments, you'll see a copy of "signedforgery.txt" which has me pretending to be Kurt with the complex test message he gave me in Prague.  I've forged the Subject and Body, and then Sealed it as brong.net.

brong@zula:~/src/mail-dkim$ perl arc.pl < signedforgery.txt
pass
ARC-Seal: v=7 pass
ARC-Message-Signature: v=7 pass
ARC-Seal: v=6 pass
ARC-Message-Signature: v=6 fail (message has been altered)
ARC-Seal: v=5 pass
ARC-Message-Signature: v=5 fail (message has been altered)
ARC-Seal: v=4 pass
ARC-Message-Signature: v=4 fail (message has been altered)
ARC-Seal: v=3 pass
ARC-Message-Signature: v=3 fail (message has been altered)
ARC-Seal: v=2 pass
ARC-Message-Signature: v=2 fail (message has been altered)
ARC-Seal: v=1 pass
ARC-Message-Signature: v=1 fail (message has been altered)

The fact that there is an intact chain of ARC-Seal is pointless here.  And as I have (hopefully successfully) argued above, if all the sites are trusted and they each successfully cryptographically authenticate the previous sender (or SPF at the first hop), you need is the AMS.  ARC-Seal does nothing.

Bron.

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


--_----------=_150249564640991762-- --_----------=_150249564640991763 Content-Disposition: attachment; filename="signedforgery.txt" Content-Id: <1502495331.4096933.d52fc5d40ffdf9126ae3cec7f8af2f6eb2671486.7AE7A7F8@content.messagingengine.com> Content-Transfer-Encoding: base64 Content-Type: text/plain; name="signedforgery.txt" QVJDLVNlYWw6IGk9NzsgYT1yc2Etc2hhMjU2OyBjdj1wYXNzOyBkPWJyb25n Lm5ldDsgcz1mbTE7IGJoPTQ3REVRcGo4SEJTDQoJYSsvVEltVys1SkNldVFl UmttNU5NcEpXWkczaFN1RlU9OyBiPWFYQmRwR2xkOVpGK0F2blVLYmxVdzF6 ZTk0Mg0KCUFsTGErMk9reWExdjQyUUJUekhXb3ZNQ2s3dHJzeWRaWHQ3OUcx VEdlUzgwNFFkWU4rVTF4M2dUdEM1WDRPQVUNCglUVGlMVm56WjJ1UGJ6WDBB dnZlT0o3RmNMaWhXU0wydWRJWXJVYVNsbnRpSGxNaU9Ybk5mNTlKWVZkdjRl Skp4DQoJWWp3TDhKaXFMaU12d3lEeHcra29OQmFCZTY4WVl6ajRZc0pHbjdR dE03aGdtT3lNbnVjdk5mZ094bjBVeFZucA0KCVdqSEp4a0lmY0IyL0hGWDFy OWlqNVRMTDJTeHpjVVpZY2JXLy9DdXNwSW5JTnhkQzk0Mm8wSEtJMWlXWmtj WmwNCglMcGsrWHFXazZEVFh0N1hON3lhVS9ZUzl4eDg0V0VOa1o5azBBUWJZ VXoxUy9iNmY5K01DTUF4d2xUUT09DQpBUkMtTWVzc2FnZS1TaWduYXR1cmU6 IGk9NzsgYT1yc2Etc2hhMjU2OyBkPWJyb25nLm5ldDsgaD1tZXNzYWdlLWlk OmRhdGUNCgk6dG86ZnJvbTpzdWJqZWN0OyBzPWZtMTsgYmg9N1c4cU93cmor MzA5S1JlTEdXQ04wMkx4RG1Db2k5ZzRqQzViDQoJdE16RkRYND07IGI9R1pF c0xEcUdCc3l5QXl5ZCtoTkJtd2pVQlBjU2wxYjlkaERta0Z5a2pxMFdKMTJG dTMxUw0KCUhXalJqMUNxMDVMeTQ2eDVQWnhNbXFYT3pteGx5d2c3MmcxcmhW OEFUNDZEcHV1bFNqSnljUEozMEIxdDd6TEoNCglsTmtsbVhOSk5FTm05cFJi UHVMY09nUzRCZm1oQjhLeXM1b3lCWEdVaXZXZjdyYXMyZVJEYUFxRnpmdXc0 ZTc1DQoJbHR3V0hiTVhkeUJOd2NVQUJhVFNVNVVzcUNTTmlCdElhNjVYcUk0 bW43QVVVSTNhZERuUkZxYmRXaVpid0U2Rw0KCVdFSzhmSEN3c1hxYXpNVFlk WXZFYXlhUHhwZ2lqZmpwV25EeVVabnBGeEtIaExKUWdROGd2Y3R2elJkNzNj d1gNCglzL3ZYakNtUDJhNzhYTjBCSXcvZVl5dVRHWHN5dE5qc2p3PT0NCkFS Qy1BdXRoZW50aWNhdGlvbi1SZXN1bHRzOiBpPTc7IG14Lmdvb2dsZS5jb207 DQogICAgICAgZGtpbT1wYXNzIGhlYWRlci5pPUBicm9uZy5uZXQgaGVhZGVy LmI9SGs2Q1RKL2g7DQogICAgICAgZGtpbT1wYXNzIGhlYWRlci5pPUBtZXNz YWdpbmdlbmdpbmUuY29tIGhlYWRlci5iPVFKWW11RzRWOw0KICAgICAgIHNw Zj1wYXNzIChnb29nbGUuY29tOiBkb21haW4gb2YgYnJvbmdAYnJvbmcubmV0 IGRlc2lnbmF0ZXMgNjYuMTExLjQuMjUgYXMgcGVybWl0dGVkIHNlbmRlcikg c210cC5tYWlsZnJvbT1icm9uZ0Bicm9uZy5uZXQNCkF1dGhlbnRpY2F0aW9u LVJlc3VsdHM6IG14Lmdvb2dsZS5jb207DQogICAgICAgZGtpbT1wYXNzIGhl YWRlci5pPUBicm9uZy5uZXQgaGVhZGVyLmI9SGs2Q1RKL2g7DQogICAgICAg ZGtpbT1wYXNzIGhlYWRlci5pPUBtZXNzYWdpbmdlbmdpbmUuY29tIGhlYWRl ci5iPVFKWW11RzRWOw0KICAgICAgIHNwZj1wYXNzIChnb29nbGUuY29tOiBk b21haW4gb2YgYnJvbmdAYnJvbmcubmV0IGRlc2lnbmF0ZXMgNjYuMTExLjQu MjUgYXMgcGVybWl0dGVkIHNlbmRlcikgc210cC5tYWlsZnJvbT1icm9uZ0Bi cm9uZy5uZXQNCkRlbGl2ZXJlZC1Ubzoga3VydGErYXJjMDctMDcxNS0zLjFh QGRya3VydC5jb20NClJlY2VpdmVkOiBieSAxMC4xNTkuNTguODQgd2l0aCBT TVRQIGlkIHIyMGNzcDIwMjI3MjF1YWc7DQogICAgICAgIFNhdCwgMTUgSnVs IDIwMTcgMDE6NDk6MzAgLTA3MDAgKFBEVCkNClgtUmVjZWl2ZWQ6IGJ5IDEw Ljg0LjE0Mi4xMjkgd2l0aCBTTVRQIGlkIDFtcjIwODg0MDAycGx4LjEwLjE1 MDAxMDg1Njk5ODA7DQogICAgICAgIFNhdCwgMTUgSnVsIDIwMTcgMDE6NDk6 MjkgLTA3MDAgKFBEVCkNCkFSQy1TZWFsOiBpPTY7IGE9cnNhLXNoYTI1Njsg dD0xNTAwMTA4NTY5OyBjdj1wYXNzOw0KICAgICAgICBkPWdvb2dsZS5jb207 IHM9YXJjLTIwMTYwODE2Ow0KICAgICAgICBiPUU4c1N0dTYrakFpSWM5L1ZD UHNNWjg4K3ZDZmUzemxsaHFCSGlOdWFES2R5YW90U0ZNR05tSFZjZkFZWkVR S2x3UA0KICAgICAgICAgbzJyMmt3QUpERkZHUUZ2bCtFQVNXeEloK3JlanpZ eFhCcUtMM2RxL0VqdisrR2tZRnNvd3ZIU280bE9kUnQ2M3h4eG0NCiAgICAg ICAgIGdSa1g1L0dua2FtODIzTGZNVGVWNC8vSlNvc29GdWROeDJPNWppVjN6 c2JBVTJmbjdXekh4NjgySUx1bzA3UHlWU2F5DQogICAgICAgICBRNDI1dGZ1 dGZQV1Uxd2NMcmxwUm9nNzBUUWM0TGNHRCtXdzFGSDJyT0g3a3FJTWsvSnBw Yi90d2p4QVZiTTR2VWk1aw0KICAgICAgICAgUkZjQWlaWk1BMlkySlNDbWh5 RWlVTzRXaFJKa1RLQUpOc3JBYlI4eFRLTzVoTmN5d3hsdk9pYUhLTjltLzN0 UmNIMWwNCiAgICAgICAgIGFKV0E9PQ0KQVJDLU1lc3NhZ2UtU2lnbmF0dXJl OiBpPTY7IGE9cnNhLXNoYTI1NjsgYz1yZWxheGVkL3JlbGF4ZWQ7IGQ9Z29v Z2xlLmNvbTsgcz1hcmMtMjAxNjA4MTY7DQogICAgICAgIGg9YXV0by1zdWJt aXR0ZWQ6c3ViamVjdDpmcm9tOnRvOmRhdGU6bWVzc2FnZS1pZA0KICAgICAg ICAgOmFyYy1hdXRoZW50aWNhdGlvbi1yZXN1bHRzOmFyYy1tZXNzYWdlLXNp Z25hdHVyZQ0KICAgICAgICAgOmFyYy1hdXRoZW50aWNhdGlvbi1yZXN1bHRz OmFyYy1tZXNzYWdlLXNpZ25hdHVyZQ0KICAgICAgICAgOmFyYy1hdXRoZW50 aWNhdGlvbi1yZXN1bHRzOmFyYy1tZXNzYWdlLXNpZ25hdHVyZTpkZWxpdmVy ZWQtdG8NCiAgICAgICAgIDphcmMtYXV0aGVudGljYXRpb24tcmVzdWx0czph cmMtbWVzc2FnZS1zaWduYXR1cmUNCiAgICAgICAgIDphcmMtYXV0aGVudGlj YXRpb24tcmVzdWx0czphcmMtbWVzc2FnZS1zaWduYXR1cmUNCiAgICAgICAg IDphcmMtYXV0aGVudGljYXRpb24tcmVzdWx0czsNCiAgICAgICAgYmg9ZWNH V2dXQ0plV3hKRmVNMHVyT1ZXUCtLT2xxcXZzUVlLT3BZVVA4bms3ST07DQog ICAgICAgIGI9QXF4UWhvd2FYWGFqcWd3S1FUeXhXd3RDMk1laFlOZXozWE40 UGdoQ1RyTmpVSmJoZWtERjg2UGg3SmZSZWhobUNWDQogICAgICAgICBma3NV RFdKR2tKd2xyY0k3UmJCRURxQWtxMkFqY3hYL0l2TFlkQktqMng3TXJuUElk SmQ0YmRaVGMwbHNPMCtZM2xQbQ0KICAgICAgICAgVzhmc1ErNHFBNnBLMWtE dit4VHJ0WmtOM3hLNHFmUWI1RDhXam9jM0d0d2tMSERFTGV5bHlDSVJEMTZU ZjQ5ZUF6bGcNCiAgICAgICAgIHR2aHhSeTM0ZmFoV2tyVlp0RHNIbnNqQzFK Z2J1SFQ1TVd4T0NCUmZUa2UyTUlYYm5IV2c1R3FEOFpZV3g0dlQra3Z4DQog ICAgICAgICA4dnlWQzlFcnZ4Z1h4R042bzArK1BRMGtVanNMOHd2a3Rrb0Jy K0c1bDZPeHR2eFUxQzA4dzdWUU1VYzdMWnI1cVN2YQ0KICAgICAgICAgYUU1 QT09DQpBUkMtQXV0aGVudGljYXRpb24tUmVzdWx0czogaT02OyBteC5nb29n bGUuY29tOw0KICAgICAgIGFyYz1wYXNzIChpPTUgc3BmPXBhc3Mgc3BmZG9t YWluPWRya3VydC5jb20gZG1hcmM9cGFzcyBmcm9tZG9tYWluPWRya3VydC5j b20pOw0KICAgICAgIHNwZj1wYXNzIChnb29nbGUuY29tOiBkb21haW4gb2Yg YXJjLW1vZC1zdWJqZWN0QG5lb3RvbmljLmNvbSBkZXNpZ25hdGVzIDIwOS44 NS4xOTIuMTk3IGFzIHBlcm1pdHRlZCBzZW5kZXIpIHNtdHAubWFpbGZyb209 YXJjLW1vZC1zdWJqZWN0QG5lb3RvbmljLmNvbTsNCiAgICAgICBkbWFyYz1m YWlsIChwPU5PTkUgc3A9Tk9ORSBkaXM9Tk9ORSkgaGVhZGVyLmZyb209ZHJr dXJ0LmNvbQ0KUmV0dXJuLVBhdGg6IDxhcmMtbW9kLXN1YmplY3RAbmVvdG9u aWMuY29tPg0KUmVjZWl2ZWQ6IGZyb20gbWFpbC1wZjAtZjE5Ny5nb29nbGUu Y29tIChtYWlsLXBmMC1mMTk3Lmdvb2dsZS5jb20uIFsyMDkuODUuMTkyLjE5 N10pDQogICAgICAgIGJ5IG14Lmdvb2dsZS5jb20gd2l0aCBFU01UUFMgaWQg ZTE4N3NpODI2NTEwOHBmYS40MS4yMDE3LjA3LjE1LjAxLjQ5LjI3DQogICAg ICAgIGZvciA8a3VydGErYXJjMDctMDcxNS0zLjFhQGRya3VydC5jb20+DQog ICAgICAgICh2ZXJzaW9uPVRMUzFfMiBjaXBoZXI9RUNESEUtUlNBLUFFUzEy OC1HQ00tU0hBMjU2IGJpdHM9MTI4LzEyOCk7DQogICAgICAgIFNhdCwgMTUg SnVsIDIwMTcgMDE6NDk6MjcgLTA3MDAgKFBEVCkNClJlY2VpdmVkLVNQRjog cGFzcyAoZ29vZ2xlLmNvbTogZG9tYWluIG9mIGFyYy1tb2Qtc3ViamVjdEBu ZW90b25pYy5jb20gZGVzaWduYXRlcyAyMDkuODUuMTkyLjE5NyBhcyBwZXJt aXR0ZWQgc2VuZGVyKSBjbGllbnQtaXA9MjA5Ljg1LjE5Mi4xOTc7DQpBdXRo ZW50aWNhdGlvbi1SZXN1bHRzOiBteC5nb29nbGUuY29tOw0KICAgICAgIGFy Yz1wYXNzIChpPTUgc3BmPXBhc3Mgc3BmZG9tYWluPWRya3VydC5jb20gZG1h cmM9cGFzcyBmcm9tZG9tYWluPWRya3VydC5jb20pOw0KICAgICAgIHNwZj1w YXNzIChnb29nbGUuY29tOiBkb21haW4gb2YgYXJjLW1vZC1zdWJqZWN0QG5l b3RvbmljLmNvbSBkZXNpZ25hdGVzIDIwOS44NS4xOTIuMTk3IGFzIHBlcm1p dHRlZCBzZW5kZXIpIHNtdHAubWFpbGZyb209YXJjLW1vZC1zdWJqZWN0QG5l b3RvbmljLmNvbTsNCiAgICAgICBkbWFyYz1mYWlsIChwPU5PTkUgc3A9Tk9O RSBkaXM9Tk9ORSkgaGVhZGVyLmZyb209ZHJrdXJ0LmNvbQ0KUmVjZWl2ZWQ6 IGJ5IG1haWwtcGYwLWYxOTcuZ29vZ2xlLmNvbSB3aXRoIFNNVFAgaWQgcTg3 c28xMTAyMTk0OTVwZmsuMTUNCiAgICAgICAgZm9yIDxrdXJ0YSthcmMwNy0w NzE1LTMuMWFAZHJrdXJ0LmNvbT47IFNhdCwgMTUgSnVsIDIwMTcgMDE6NDk6 MjcgLTA3MDAgKFBEVCkNClgtR20tTWVzc2FnZS1TdGF0ZTogQUlWdzExM3lt cXVOYjYvMVlpN1Y0WU1kRjYzRGRXK2daVEY0TjJ3TmpjRGIreWFIMHdzNGpa c0Mgdmd3S3UwQ2V1Wmw0RndoR3J1TGoNClgtUmVjZWl2ZWQ6IGJ5IDEwLjEw MS44OC4xNDIgd2l0aCBTTVRQIGlkIGQxNG1yMTIxMTQyODNwZ3UuMTQxLjE1 MDAxMDg1Njc1Nzk7DQogICAgICAgIFNhdCwgMTUgSnVsIDIwMTcgMDE6NDk6 MjcgLTA3MDAgKFBEVCkNCkFSQy1TZWFsOiBpPTU7IGE9cnNhLXNoYTI1Njsg dD0xNTAwMTA4NTY3OyBjdj1wYXNzOw0KICAgICAgICBkPW5lb3RvbmljLmNv bTsgcz1hcmN0ZXN0Ow0KICAgICAgICBiPWZGRHFZaVhqQnBKTzZRVVJuajg0 OStiUnZpM3BxMGw2bXJHSTVaTkhvTFc5eDFIb0V6emMxd1NZOTViY0phZWtX SA0KICAgICAgICAgaVFmUHFYSzJCcmJWZThuclVPVlNlYnBYbk1mYk1sSTkw b1pLcmdoT2o4U2xZSGR0SnhiQitxZnV3SHJudG1ZMlJ1elENCiAgICAgICAg IExwY2dZKzRSTGVaOVNKejJaTjFtL21qODR1Sk5DMlVGWGtpSDR2dk10aDlr ck9YSnlUZzVIOVlCWTdnRjBaZzFpMGpPDQogICAgICAgICBINGhIdXhjQU1U OFBHdGltWXEwZ0VSTWordlZNM0RFSkpMcVYzU2xUKzdZdVduaXNnbVh6MTZT SVJqWGZMdm1ETWUwVA0KICAgICAgICAgcnh2cUM4UElWY3NVaGlyMXZpYWtz MU1SRy9kLzl0eWt2NWViWmQ3d05zQUd0bUdvYURwbjJQdDRmLzBsaDI4aHVL UDQNCiAgICAgICAgIHZLb3c9PQ0KQVJDLU1lc3NhZ2UtU2lnbmF0dXJlOiBp PTU7IGE9cnNhLXNoYTI1NjsgYz1yZWxheGVkL3JlbGF4ZWQ7IGQ9bmVvdG9u aWMuY29tOyBzPWFyY3Rlc3Q7DQogICAgICAgIGg9YXV0by1zdWJtaXR0ZWQ6 c3ViamVjdDpmcm9tOnRvOmRhdGU6bWVzc2FnZS1pZA0KICAgICAgICAgOmFy Yy1hdXRoZW50aWNhdGlvbi1yZXN1bHRzOmFyYy1tZXNzYWdlLXNpZ25hdHVy ZQ0KICAgICAgICAgOmFyYy1hdXRoZW50aWNhdGlvbi1yZXN1bHRzOmFyYy1t ZXNzYWdlLXNpZ25hdHVyZQ0KICAgICAgICAgOmFyYy1hdXRoZW50aWNhdGlv bi1yZXN1bHRzOmFyYy1tZXNzYWdlLXNpZ25hdHVyZTpkZWxpdmVyZWQtdG8N CiAgICAgICAgIDphcmMtYXV0aGVudGljYXRpb24tcmVzdWx0czphcmMtbWVz c2FnZS1zaWduYXR1cmUNCiAgICAgICAgIDphcmMtYXV0aGVudGljYXRpb24t cmVzdWx0czsNCiAgICAgICAgYmg9ZWNHV2dXQ0plV3hKRmVNMHVyT1ZXUCtL T2xxcXZzUVlLT3BZVVA4bms3ST07DQogICAgICAgIGI9MFI3NjZERnl3UW0x MEZmUlBlalYyTnQ2eXNCY2NYd09saXM5ZFdFRHdKSy80cnUyTGN6cS9WaEF2 NkM5dlRQdjVvDQogICAgICAgICBVOFhLaUVxQlBLOVFmR1ZqZDhxL0t4ZHNG b0J3S2wxT2ozVVlzY3hQUWtMME9BNEpnb0hUQ0JFQkxVdGRxZFlxL2xXMQ0K ICAgICAgICAgSWJZUk1ud2pJSFVQemt6UlM0aUg2eDg4WFFXZTFFSnFxNmUv cG14NjNJMTRPdGV5NkkrYWJCTTE0elJ1enh5bVQzcHANCiAgICAgICAgIEpy VUlveTVLTTdhUGRSOGIwYnl3dHlvaUwxd2tHTFpNdUQzb3QvUU1FQ3E2RTBs VktTTnh3OFIvR1dEd2duQjUybmF3DQogICAgICAgICBadGZEQlZRZ2ovQXN0 R01zQyt6OFU4VVh6VnhzMmZZZ1pDU0lFQVZKMlIxdDA5WU1CNEowUGcvU1Bw cjh4YkVkQVQwVg0KICAgICAgICAgT0NsZz09DQpBUkMtQXV0aGVudGljYXRp b24tUmVzdWx0czogaT01OyBteC5nb29nbGUuY29tOw0KICAgICAgIGFyYz1w YXNzIChpPTMgc3BmPXBhc3Mgc3BmZG9tYWluPW5lb3RvbmljLmNvbSk7DQog ICAgICAgc3BmPXBhc3MgKGdvb2dsZS5jb206IGRvbWFpbiBvZiBrdXJ0YSth cmMwNy0wNzE1LTMuMWFAZHJrdXJ0LmNvbSBkZXNpZ25hdGVzIDJhMDE6NGY4 OmQxMjoxZDgyOjoyIGFzIHBlcm1pdHRlZCBzZW5kZXIpIHNtdHAubWFpbGZy b209a3VydGErYXJjMDctMDcxNS0zLjFhQGRya3VydC5jb207DQogICAgICAg ZG1hcmM9cGFzcyAocD1OT05FIHNwPU5PTkUgZGlzPU5PTkUpIGhlYWRlci5m cm9tPWRya3VydC5jb207DQogICAgICAgYXJjPXBhc3MNClgtUmVjZWl2ZWQ6 IGJ5IDEwLjM2LjE3Mi43NyB3aXRoIFNNVFAgaWQgbTEzbXI0MTQzNjBpdGku NTkuMTUwMDEwODU2NjkwMDsNCiAgICAgICAgU2F0LCAxNSBKdWwgMjAxNyAw MTo0OToyNiAtMDcwMCAoUERUKQ0KQVJDLVNlYWw6IGk9NDsgYT1yc2Etc2hh MjU2OyB0PTE1MDAxMDg1NjY7IGN2PXBhc3M7DQogICAgICAgIGQ9Z29vZ2xl LmNvbTsgcz1hcmMtMjAxNjA4MTY7DQogICAgICAgIGI9cmZCTkQxS2RkUTBL blNvbmdQaDZKeVdxNkxyakYxQXBBVnV2M2x0NWRMTHNMT0FLYlc0eHdQUjVi VGFVSWVPcGhFDQogICAgICAgICBOZmFqMHIycmNQT2xsN1pvUjlYRWwyS0dB U1JJMkVxdkZkNXFOc3JJM0RoNjhlNWZUUTE1NVY4NlF0MHdPdENEaWtUbA0K ICAgICAgICAgdkE1RzdBN2phcEZCQ3dBOE1zaXFWejc2cWM4MzFoOHBTclFP OW9TT0NWUzk4T2duUGNJZTF2aW9ZbWpEWjBNWTV5ZTANCiAgICAgICAgICsr bGo0ZTBLNjJzVks1clFGTzExOHQ4MTNaUlEyTG1FMkM4T05DKzRWTVNvajBi MVovYlFJK0EzOXRPZVB0TWJ5K01WDQogICAgICAgICB6YisyTGpzeGN4cGx5 b2wweEl4NzJmcDlEVDVCS3NkTlhVeWlKZ1NNVzR3Sk1Hc1RHTmNBODh2Y1hL RU00emlyYXkyNQ0KICAgICAgICAgdENOZz09DQpBUkMtTWVzc2FnZS1TaWdu YXR1cmU6IGk9NDsgYT1yc2Etc2hhMjU2OyBjPXJlbGF4ZWQvcmVsYXhlZDsg ZD1nb29nbGUuY29tOyBzPWFyYy0yMDE2MDgxNjsNCiAgICAgICAgaD1hdXRv LXN1Ym1pdHRlZDpzdWJqZWN0OmZyb206dG86ZGF0ZTptZXNzYWdlLWlkDQog ICAgICAgICA6YXJjLWF1dGhlbnRpY2F0aW9uLXJlc3VsdHM6YXJjLW1lc3Nh Z2Utc2lnbmF0dXJlDQogICAgICAgICA6YXJjLWF1dGhlbnRpY2F0aW9uLXJl c3VsdHM6YXJjLW1lc3NhZ2Utc2lnbmF0dXJlDQogICAgICAgICA6YXJjLWF1 dGhlbnRpY2F0aW9uLXJlc3VsdHM6YXJjLW1lc3NhZ2Utc2lnbmF0dXJlOmRl bGl2ZXJlZC10bw0KICAgICAgICAgOmFyYy1hdXRoZW50aWNhdGlvbi1yZXN1 bHRzOw0KICAgICAgICBiaD1lY0dXZ1dDSmVXeEpGZU0wdXJPVldQK0tPbHFx dnNRWUtPcFlVUDhuazdJPTsNCiAgICAgICAgYj1YaXYxSVRvUmVob3JBaEE2 U055c2VkaDdxYk9oQit4eEQ1ZWVUMXJvMU5UdzZYTnRUK2lHTTFuSXpLa3Y4 SGh6RkUNCiAgICAgICAgIEFEcEdWckFTWFM2cGtMSkxzQmsyNlY1dzRRRzda MEkvSWE1WE5KaVpJamdubmJDV1UzdlBmRGluYVJudEQ4NW9PaVNaDQogICAg ICAgICBLZzM2dC9xTVN6WnArMlp2TTJ4dnZTTzY0eW55ZDFKTFZGMDBBQ3Zy Ui81T1czOS9saldaNEpMb0ovMXdyR2xHb2J4bQ0KICAgICAgICAgS0MvVWRo c1RVaWMrZ1k5WVY1eGdDcDJRSk1Pdm9JRTY1ak5sVmpLYURocUJVRnhkbFE1 a20vME00QkVYSE52eEozVXMNCiAgICAgICAgIEZ1alJ3ZktrWFRxR1RidllD ZThRR0tqSnRqM3R6LzNTQ1FvS0IxWSttT1VBcm83QWRYbTZDZk1pN01seG9K Vk03RW5XDQogICAgICAgICBaZXZRPT0NCkFSQy1BdXRoZW50aWNhdGlvbi1S ZXN1bHRzOiBpPTQ7IG14Lmdvb2dsZS5jb207DQogICAgICAgYXJjPXBhc3Mg KGk9MyBzcGY9cGFzcyBzcGZkb21haW49bmVvdG9uaWMuY29tKTsNCiAgICAg ICBzcGY9cGFzcyAoZ29vZ2xlLmNvbTogZG9tYWluIG9mIGt1cnRhK2FyYzA3 LTA3MTUtMy4xYUBkcmt1cnQuY29tIGRlc2lnbmF0ZXMgMmEwMTo0Zjg6ZDEy OjFkODI6OjIgYXMgcGVybWl0dGVkIHNlbmRlcikgc210cC5tYWlsZnJvbT1r dXJ0YSthcmMwNy0wNzE1LTMuMWFAZHJrdXJ0LmNvbTsNCiAgICAgICBkbWFy Yz1wYXNzIChwPU5PTkUgc3A9Tk9ORSBkaXM9Tk9ORSkgaGVhZGVyLmZyb209 ZHJrdXJ0LmNvbQ0KUmV0dXJuLVBhdGg6IDxrdXJ0YSthcmMwNy0wNzE1LTMu MWFAZHJrdXJ0LmNvbT4NClJlY2VpdmVkOiBmcm9tIG1hbmdvLnBlYWNoeW1h bmdvLm9yZyAobWFuZ28ucGVhY2h5bWFuZ28ub3JnLiBbMmEwMTo0Zjg6ZDEy OjFkODI6OjJdKQ0KICAgICAgICBieSBteC5nb29nbGUuY29tIHdpdGggRVNN VFAgaWQgNDFzaTExNTIxOTk0aW9qLjI4NC4yMDE3LjA3LjE1LjAxLjQ5LjI1 DQogICAgICAgIGZvciA8YXJjLW1vZC1zdWJqZWN0QG5lb3RvbmljLmNvbT47 DQogICAgICAgIFNhdCwgMTUgSnVsIDIwMTcgMDE6NDk6MjUgLTA3MDAgKFBE VCkNClJlY2VpdmVkLVNQRjogcGFzcyAoZ29vZ2xlLmNvbTogZG9tYWluIG9m IGt1cnRhK2FyYzA3LTA3MTUtMy4xYUBkcmt1cnQuY29tIGRlc2lnbmF0ZXMg MmEwMTo0Zjg6ZDEyOjFkODI6OjIgYXMgcGVybWl0dGVkIHNlbmRlcikgY2xp ZW50LWlwPTJhMDE6NGY4OmQxMjoxZDgyOjoyOw0KRGVsaXZlcmVkLVRvOiBr dXJ0YSthcmMwNy0wNzE1LTEuMWFAZHJrdXJ0LmNvbQ0KUmVjZWl2ZWQ6IGJ5 IDEwLjE1OS41OC44NCB3aXRoIFNNVFAgaWQgcjIwY3NwMjAxMDYyMXVhZzsN CiAgICAgICAgU2F0LCAxNSBKdWwgMjAxNyAwMTozMjowMyAtMDcwMCAoUERU KQ0KWC1SZWNlaXZlZDogYnkgMTAuMzcuMTk1LjE5NiB3aXRoIFNNVFAgaWQg dDE4N21yOTkxMzE2MXliZi4yMDMuMTUwMDEwNzUyMzM2OTsNCiAgICAgICAg U2F0LCAxNSBKdWwgMjAxNyAwMTozMjowMyAtMDcwMCAoUERUKQ0KQVJDLVNl YWw6IGk9MzsgYT1yc2Etc2hhMjU2OyB0PTE1MDAxMDc1MjM7IGN2PXBhc3M7 DQogICAgICAgIGQ9Z29vZ2xlLmNvbTsgcz1hcmMtMjAxNjA4MTY7DQogICAg ICAgIGI9T0VwU1Yxc1VJNFluTGVYaVJQYVpSeDVadmJSaGQvWEEwU3BESVBu K1ROV0trV1VXSXBqWmlsalF2SHZRVHhNZGxGDQogICAgICAgICBRaVFhbzhN L3pCWFFITjZPSG5FWjU1Z0N3Wm81TkMvWkxkSUwyM09FRlRESEsycnNDR3FE ODhYM0lzU3BYS1BDS1NuRg0KICAgICAgICAgZ2RCemFyc0RiOVJEZFVGSGtj aUJwZWZWZSswb0Jnc3hhWWZLS0x3bVZwbk1OeHJkKzhHVGhwWjdzZXZGa0NI eG1DY0kNCiAgICAgICAgIHNuNkhOQnhpZ3UvR2JFZ2dpanVTazA0dmJFWmdS RDJCSWVXNWd4emhabEVhZ0loank2Ly9VczJURC8reFVlV1lzVzN1DQogICAg ICAgICBISHoxUmtYd1U1NXpYYWJQbzYycDBhSWFPWU9STnU4blBRRVBPNzZE bXMvVldLWDRlL1pPWW8yUnBnT041K0Z1ZWMwYQ0KICAgICAgICAgS2xyUT09 DQpBUkMtTWVzc2FnZS1TaWduYXR1cmU6IGk9MzsgYT1yc2Etc2hhMjU2OyBj PXJlbGF4ZWQvcmVsYXhlZDsgZD1nb29nbGUuY29tOyBzPWFyYy0yMDE2MDgx NjsNCiAgICAgICAgaD1hdXRvLXN1Ym1pdHRlZDpzdWJqZWN0OmZyb206dG86 ZGF0ZTptZXNzYWdlLWlkDQogICAgICAgICA6YXJjLWF1dGhlbnRpY2F0aW9u LXJlc3VsdHM6YXJjLW1lc3NhZ2Utc2lnbmF0dXJlDQogICAgICAgICA6YXJj LWF1dGhlbnRpY2F0aW9uLXJlc3VsdHM6YXJjLW1lc3NhZ2Utc2lnbmF0dXJl DQogICAgICAgICA6YXJjLWF1dGhlbnRpY2F0aW9uLXJlc3VsdHM7DQogICAg ICAgIGJoPWVjR1dnV0NKZVd4SkZlTTB1ck9WV1ArS09scXF2c1FZS09wWVVQ OG5rN0k9Ow0KICAgICAgICBiPUpCclBmeUxES3VWN2xkR1kzenVvbGRlVjZl bzE1eWdJRFljbWVPUWhiMGtDNjYyZVhGVzFCR2h2V2prL29kK0QyTg0KICAg ICAgICAgWDJId2R0dm1VMThrdk1MUmJEbWlvUkZMSER2QThXT3Y5T1dwVjZ4 SWJBeE9Sby9CN1BOWjBUUkJsSmtodVBNUzhzU2ENCiAgICAgICAgIG03cjlv UVFKTjFTajJSRE9lRVA5dEhyeE1BbzIvbHJOa0FxQmQ0K0grbDVTUlpFOXBy eFp0VWNPSGpVUVd3bnhHMHN5DQogICAgICAgICBOeUFCVlBLczkwampCVmtQ QUl4aHNaM2ljQ2VGU3JTKzBOYzQwQmNzMmNKY3ZUaFVXSndaQ0dmVEZpMldt UWdSVGZNNQ0KICAgICAgICAgRGhxbGtVclc0SHZJeEt5akFVRnZHT3VvMWJV UnN3K3dmZy9QWFA5dVZiOHJvTTMraEFxcnhnaDIwc2RjZ0tCamRLcG4NCiAg ICAgICAgIFRadXc9PQ0KQVJDLUF1dGhlbnRpY2F0aW9uLVJlc3VsdHM6IGk9 MzsgbXguZ29vZ2xlLmNvbTsNCiAgICAgICBhcmM9cGFzcyAoaT0yIHNwZj1w YXNzIHNwZmRvbWFpbj1kcmt1cnQuY29tIGRtYXJjPXBhc3MgZnJvbWRvbWFp bj1kcmt1cnQuY29tKTsNCiAgICAgICBzcGY9cGFzcyAoZ29vZ2xlLmNvbTog ZG9tYWluIG9mIGFyYy1tb2Qtc3ViamVjdEBuZW90b25pYy5jb20gZGVzaWdu YXRlcyAyMDkuODUuMjEzLjE5OCBhcyBwZXJtaXR0ZWQgc2VuZGVyKSBzbXRw Lm1haWxmcm9tPWFyYy1tb2Qtc3ViamVjdEBuZW90b25pYy5jb207DQogICAg ICAgZG1hcmM9ZmFpbCAocD1OT05FIHNwPU5PTkUgZGlzPU5PTkUpIGhlYWRl ci5mcm9tPWRya3VydC5jb20NClJldHVybi1QYXRoOiA8YXJjLW1vZC1zdWJq ZWN0QG5lb3RvbmljLmNvbT4NClJlY2VpdmVkOiBmcm9tIG1haWwteWIwLWYx OTguZ29vZ2xlLmNvbSAobWFpbC15YjAtZjE5OC5nb29nbGUuY29tLiBbMjA5 Ljg1LjIxMy4xOThdKQ0KICAgICAgICBieSBteC5nb29nbGUuY29tIHdpdGgg RVNNVFBTIGlkIDJzaTI3MzQ1MzJ5d2IuMTQyLjIwMTcuMDcuMTUuMDEuMzIu MDINCiAgICAgICAgZm9yIDxrdXJ0YSthcmMwNy0wNzE1LTEuMWFAZHJrdXJ0 LmNvbT4NCiAgICAgICAgKHZlcnNpb249VExTMV8yIGNpcGhlcj1FQ0RIRS1S U0EtQUVTMTI4LUdDTS1TSEEyNTYgYml0cz0xMjgvMTI4KTsNCiAgICAgICAg U2F0LCAxNSBKdWwgMjAxNyAwMTozMjowMiAtMDcwMCAoUERUKQ0KUmVjZWl2 ZWQtU1BGOiBwYXNzIChnb29nbGUuY29tOiBkb21haW4gb2YgYXJjLW1vZC1z dWJqZWN0QG5lb3RvbmljLmNvbSBkZXNpZ25hdGVzIDIwOS44NS4yMTMuMTk4 IGFzIHBlcm1pdHRlZCBzZW5kZXIpIGNsaWVudC1pcD0yMDkuODUuMjEzLjE5 ODsNClJlY2VpdmVkOiBieSBtYWlsLXliMC1mMTk4Lmdvb2dsZS5jb20gd2l0 aCBTTVRQIGlkIHozN3NvMTA1ODE0NTUyeWJoLjE1DQogICAgICAgIGZvciA8 a3VydGErYXJjMDctMDcxNS0xLjFhQGRya3VydC5jb20+OyBTYXQsIDE1IEp1 bCAyMDE3IDAxOjMyOjAyIC0wNzAwIChQRFQpDQpYLVJlY2VpdmVkOiBieSAx MC4xMy4yNDcuMyB3aXRoIFNNVFAgaWQgaDNtcjc5MjY4NzZ5d2YuMTQwLjE1 MDAxMDc1MjIxMTI7DQogICAgICAgIFNhdCwgMTUgSnVsIDIwMTcgMDE6MzI6 MDIgLTA3MDAgKFBEVCkNCkFSQy1TZWFsOiBpPTI7IGE9cnNhLXNoYTI1Njsg dD0xNTAwMTA3NTIyOyBjdj1wYXNzOw0KICAgICAgICBkPW5lb3RvbmljLmNv bTsgcz1hcmN0ZXN0Ow0KICAgICAgICBiPUhMUWNuc3V0QmdVY2l1aENsck4z bC8wWVByZHRRWWNrNFI0Y1hqVElJdkhXeTNKL2krY1JXMUpZK1d6bjRNVUtR WA0KICAgICAgICAgR1NLVFNRNEdOYlB1UE9IN3QxN21EZEF0TDVZUndRVHMz L2ExWXdCOFVSQ0hKRVlXUSt6WVRwejZQaDhkSmplQ2tURVYNCiAgICAgICAg IE1maXpMbkkxYjJlYURoK1pTVHY1MGxtQ3hpTG9FWkpXdGhUVEhZOTFVSUtX aWVpTXY5Q3NIYlBkZEdRRWpwWTM0UWdQDQogICAgICAgICAvVVJaSk0rOVBs cWFUeTZyc2pyemx6dFZRZVh2Vm1rU0JLcXJMYVdQTGtiM1ViekczQkN1R0JW ektENCtxa1VBNkl6dw0KICAgICAgICAgcWZlUktUVU5nMGJqSjcvUnRNSWti WjROQUgrNlF0TWVramRWNGp4UjIrS1hXNGJHRlJVekdGSUxzVDhRemJPRm9E cHoNCiAgICAgICAgIGxNZkE9PQ0KQVJDLU1lc3NhZ2UtU2lnbmF0dXJlOiBp PTI7IGE9cnNhLXNoYTI1NjsgYz1yZWxheGVkL3JlbGF4ZWQ7IGQ9bmVvdG9u aWMuY29tOyBzPWFyY3Rlc3Q7DQogICAgICAgIGg9YXV0by1zdWJtaXR0ZWQ6 c3ViamVjdDpmcm9tOnRvOmRhdGU6bWVzc2FnZS1pZA0KICAgICAgICAgOmFy Yy1hdXRoZW50aWNhdGlvbi1yZXN1bHRzOmFyYy1tZXNzYWdlLXNpZ25hdHVy ZQ0KICAgICAgICAgOmFyYy1hdXRoZW50aWNhdGlvbi1yZXN1bHRzOw0KICAg ICAgICBiaD1lY0dXZ1dDSmVXeEpGZU0wdXJPVldQK0tPbHFxdnNRWUtPcFlV UDhuazdJPTsNCiAgICAgICAgYj1OKzZZd3ZEOUxKQWk5d1dSNWlSc3R3akti RDY4bmxkem42V2ZCaDY4Sjh4Q1RIajVjOTBCYkRPZHlPMG1KT3pJYWENCiAg ICAgICAgIERFNEFmbGRjYjBXRkZOZGxEZWhJc1FrZS90M3VHdk8yY3lORWQx eUxzL0xPRmM1MjhZS1pvRE5XYXZTdmZiQktzZWFjDQogICAgICAgICBTOGU4 MXlETlFLNmFtVlhySDRzbXcxNnRPNExLUlhjNHNxc24yY2gwd0RhWURMd2Ni VDJYV1dYNEw5dURNa09YSnRKaw0KICAgICAgICAgbkRaeDZjM0lYMzRibEFh dUxtMXdSRENTTDBWTG03V2JOWFdUbHlPZkUzVExSK0doU1NCUkRhRFYwZ3gz NGhLYU0yMHANCiAgICAgICAgICtiQWMralpiQ0oyWGFDVnZzUnlXUTIrMFY3 ak8ramF0ZTBFSjB0N21qalNPbGZzRkNrcEZLNjR1SVJtR2FuSzkzMFRzDQog ICAgICAgICBVU1dBPT0NCkFSQy1BdXRoZW50aWNhdGlvbi1SZXN1bHRzOiBp PTI7IG14Lmdvb2dsZS5jb207DQogICAgICAgc3BmPXBhc3MgKGdvb2dsZS5j b206IGRvbWFpbiBvZiBrdXJ0YSthcmMwNy0wNzE1LTEuMWFAZHJrdXJ0LmNv bSBkZXNpZ25hdGVzIDJhMDE6NGY4OmQxMjoxZDgyOjoyIGFzIHBlcm1pdHRl ZCBzZW5kZXIpIHNtdHAubWFpbGZyb209a3VydGErYXJjMDctMDcxNS0xLjFh QGRya3VydC5jb207DQogICAgICAgZG1hcmM9cGFzcyAocD1OT05FIHNwPU5P TkUgZGlzPU5PTkUpIGhlYWRlci5mcm9tPWRya3VydC5jb207DQogICAgICAg YXJjPXBhc3MNClgtUmVjZWl2ZWQ6IGJ5IDEwLjEwNy42LjY4IHdpdGggU01U UCBpZCA2NW1yODE4MjczMmlvZy41Ni4xNTAwMTA3NTIxNzgwOw0KICAgICAg ICBTYXQsIDE1IEp1bCAyMDE3IDAxOjMyOjAxIC0wNzAwIChQRFQpDQpBUkMt U2VhbDogaT0xOyBhPXJzYS1zaGEyNTY7IHQ9MTUwMDEwNzUyMTsgY3Y9bm9u ZTsNCiAgICAgICAgZD1nb29nbGUuY29tOyBzPWFyYy0yMDE2MDgxNjsNCiAg ICAgICAgYj1FVGh3WkhZZHFOYzY0TGVHUmZlR2hRWVlKbkVuVGhXcStMVyts Rm1YaUhnT0dVSERtckFOVnBzRW94UGdpdWFodWQNCiAgICAgICAgIDZlUzM5 THZSZksvNlhtd01RMEo3TWtLREw2M04wK21kckJ5QjVOWlltWlNNS05GVVIy L2lPc0JBQ0xOWGxKSDlTM0h3DQogICAgICAgICBETVM4b2tMM29OaXkwYkZ0 K005eC9ESGd1djNkb2ttMEdXQ2lrMERoMS9aYzlvMHdvbDlDRVYwZm9lRlFv Tlp4MkZuWA0KICAgICAgICAgaVpiSEl0djRJWmQ4L2F2SFp4OGVSYnZiSzAx Q3IzQS9uM3dwSE1scmM3UnN3VFh0bytyRmptcUpxOUpyN1BjeUpmWUUNCiAg ICAgICAgIFhGc3gzdE8ya3NOVDQ4enFGNG96WUNQTk9qWGUxTnZuTzhSYU05 R25RRmkwb2NNaWN4eFhYUTBRU0l4c1RXVGNGNUtvDQogICAgICAgICBXbFZB PT0NCkFSQy1NZXNzYWdlLVNpZ25hdHVyZTogaT0xOyBhPXJzYS1zaGEyNTY7 IGM9cmVsYXhlZC9yZWxheGVkOyBkPWdvb2dsZS5jb207IHM9YXJjLTIwMTYw ODE2Ow0KICAgICAgICBoPXN1YmplY3Q6ZnJvbTp0bzpkYXRlOm1lc3NhZ2Ut aWQ6YXJjLWF1dGhlbnRpY2F0aW9uLXJlc3VsdHM7DQogICAgICAgIGJoPWVj R1dnV0NKZVd4SkZlTTB1ck9WV1ArS09scXF2c1FZS09wWVVQOG5rN0k9Ow0K ICAgICAgICBiPWp0UjZvMlErM0hEejBSdFZVUXovRGdxcnFhR3FldUw5MHJQ SHAwK3J1ZDZwQUd0eFhKSnZrM1ZranN0d2JnTVU3ZQ0KICAgICAgICAgbHQv MEExOElnQi96QzlKOVJ4K3JFTytraE53YktsOENZTzlFRXF1Z0xURXZSOU43 cTRhQnErZjRPR0JmQ1ozSmVkaEkNCiAgICAgICAgIFlYTzVPYWx3MlIwM3ZV azNZTFZwd0cxVU0xdHVEdWNkZ1JRK003QXF1a21aNUd3TmVNZ3NBanFPSGMr VW0wUWJGU1k3DQogICAgICAgICBZOUlyWnFMSERXakpjSHdQWHBLWklncmxJ WFNlNVJ2WWtPOW5Zd1JhemNzdXdNelZGam4zZm5EZjc2azdDNDZtSUJvNw0K ICAgICAgICAgVGluNWZUMlp4TnFPMUFGU0l6eWFuYVU0bUI0bDNQNy81K0Iv RzlFSDJVK1R0RWc1dVZyRktYOFAvVmpVcFFIU2lWN1UNCiAgICAgICAgIEFh blE9PQ0KQVJDLUF1dGhlbnRpY2F0aW9uLVJlc3VsdHM6IGk9MTsgbXguZ29v Z2xlLmNvbTsNCiAgICAgICBzcGY9cGFzcyAoZ29vZ2xlLmNvbTogZG9tYWlu IG9mIGt1cnRhK2FyYzA3LTA3MTUtMS4xYUBkcmt1cnQuY29tIGRlc2lnbmF0 ZXMgMmEwMTo0Zjg6ZDEyOjFkODI6OjIgYXMgcGVybWl0dGVkIHNlbmRlcikg c210cC5tYWlsZnJvbT1rdXJ0YSthcmMwNy0wNzE1LTEuMWFAZHJrdXJ0LmNv bTsNCiAgICAgICBkbWFyYz1wYXNzIChwPU5PTkUgc3A9Tk9ORSBkaXM9Tk9O RSkgaGVhZGVyLmZyb209ZHJrdXJ0LmNvbQ0KUmV0dXJuLVBhdGg6IDxrdXJ0 YSthcmMwNy0wNzE1LTEuMWFAZHJrdXJ0LmNvbT4NClJlY2VpdmVkOiBmcm9t IG1hbmdvLnBlYWNoeW1hbmdvLm9yZyAobWFuZ28ucGVhY2h5bWFuZ28ub3Jn LiBbMmEwMTo0Zjg6ZDEyOjFkODI6OjJdKQ0KICAgICAgICBieSBteC5nb29n bGUuY29tIHdpdGggRVNNVFAgaWQgbzIzc2k0MzI0NzQwaXRhLjE0Ny4yMDE3 LjA3LjE1LjAxLjMyLjAxDQogICAgICAgIGZvciA8YXJjLW1vZC1zdWJqZWN0 QG5lb3RvbmljLmNvbT47DQogICAgICAgIFNhdCwgMTUgSnVsIDIwMTcgMDE6 MzI6MDEgLTA3MDAgKFBEVCkNClJlY2VpdmVkLVNQRjogcGFzcyAoZ29vZ2xl LmNvbTogZG9tYWluIG9mIGt1cnRhK2FyYzA3LTA3MTUtMS4xYUBkcmt1cnQu Y29tIGRlc2lnbmF0ZXMgMmEwMTo0Zjg6ZDEyOjFkODI6OjIgYXMgcGVybWl0 dGVkIHNlbmRlcikgY2xpZW50LWlwPTJhMDE6NGY4OmQxMjoxZDgyOjoyOw0K TWVzc2FnZS1JZDogPDU5NjlkMzAxLjE3NDQyNDBhLjlkMDdlLjJjN2RTTVRQ SU5fQURERURfTUlTU0lOR0BteC5nb29nbGUuY29tPg0KRGF0ZTogU2F0LCAx NSBKdWwgMjAxNyAxMDozMjowMCArMDIwMA0KVG86IGRtYXJjQGlldGYub3Jn DQpGcm9tOiBLdXJ0IEFuZGVyc2VuIDxrYm90aEBkcmt1cnQuY29tPg0KU3Vi amVjdDogQnJvbiBpcyByaWdodCwgb2xkIEFSQyBzZWFscyBkb24ndCBkbyBh bnl0aGluZw0KWC1NYWlsZXI6IHN3YWtzIHYyMDEzMDIwOS4wIGpldG1vcmUu b3JnL2pvaG4vY29kZS9zd2Frcy8NCkF1dG8tU3VibWl0dGVkOiBhdXRvLXJl cGxpZWQNCg0KSXQgbG9va3MgbGlrZSB5b3UgY2FuIGZvcmdlIGFuZCByZXVz ZSBBUkMtU2VhbCwgd2hvIGtuZXcuDQo= --_----------=_150249564640991763-- From nobody Fri Aug 11 17:04:52 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC5BC132459 for ; Fri, 11 Aug 2017 17:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9qYpc-bVDho for ; Fri, 11 Aug 2017 17:04:49 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F252C132465 for ; Fri, 11 Aug 2017 17:04:48 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id x3so46657364oia.1 for ; Fri, 11 Aug 2017 17:04:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=5M9TP1u5DoKasCttRoDxtEkUR1b052f6f5j1dCT5aPA=; b=f7ElNO0qnQJxhLmx+Ar3x3Xw1c+/AWfFSqUqNPFEEHjbMXRGcm3eQKxM/yKCAsx2fq fAnBgXt0qsnZbtLfJkUd6nMHLdShi5YQ7bNYbJ/I/9EcOWq5Hg9OqTMH327onndsZasu xFAqOb0v9Pf4zeUxc1zBahxq7LFkE9GJaSqtRJEpLkp8Zy1+w7QAww217oQZuZAyrB4Q +cBQLTHlXn8HLp4bpGNBRnk4UmomTdPcRU6O5EIZrnR6VYF7LMY48MA/wxYcN4D1faaA ahRzGGxcPBJ9phl0y5ew+KpuwDjwzEoRt3ERRLgg4ZKJB6fn8iay/tqZ+bDxvoRt3NJk tPEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=5M9TP1u5DoKasCttRoDxtEkUR1b052f6f5j1dCT5aPA=; b=DK3azv5UO+2hi/md/dEG/SrQY24xi1tqsX/cUDJwbITapYmP3GEjr+sz4WC8e3N8NZ VCZenHpkgmSs/PiPtpjBHnTrg8WS3rPT4WRb1pocuT1fuGA9woDnHPxYpckzt1qBmP47 a6D6UBwkVaHtkj9WnNGIhJsWIiqx4WBFd3Dr8ObArcMgFnfKLdB1x/f3Oym/KTGzOVdd o/12AsoHrHZM0329XJDlllilSoK5HLg3ab3LEy9NUKQHdpEb9nlfFKgvgFhbYwyn4Frn nuuaJ9SEFNkmaACoVnRLCRnb+EncPN16lkYagy9rASR0k8FK/F9KQeVVg3tZLnGtUeEb FsOQ== X-Gm-Message-State: AHYfb5jj9nnInXwm7hzNoWgZUkLI/REFhUYMrf1jVQNxOiHMXHXcwoP+ PU+gHfWnRAeOgR//0c8= X-Received: by 10.202.74.22 with SMTP id x22mr18157861oia.254.1502496288064; Fri, 11 Aug 2017 17:04:48 -0700 (PDT) Received: from ?IPv6:2602:304:cda0:8800:d17e:7fe3:9cb7:7c98? ([2602:304:cda0:8800:d17e:7fe3:9cb7:7c98]) by smtp.gmail.com with ESMTPSA id a6sm2579919oic.10.2017.08.11.17.04.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Aug 2017 17:04:47 -0700 (PDT) To: Bron Gondwana , dmarc@ietf.org References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> From: Dave Crocker Message-ID: <166070f0-4ba1-70da-1f73-885b4a7f7640@gmail.com> Date: Fri, 11 Aug 2017 17:04:45 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Aug 2017 00:04:51 -0000 On 8/11/2017 4:54 PM, Bron Gondwana wrote: > On Sat, 12 Aug 2017, at 03:22, Dave Crocker wrote: > > I'm just picking out the key quote here: > >> On 8/7/2017 4:22 PM, Seth Blank wrote: >> >> When validating an ARC signed message, one verifies the latest AMS >> (which must validate), and *the entire chain* of ARC Seals, not only >> the latest. This guarantees you a list of all message signatories - >> the chain of custody we're talking about. > > Yes, I follow this bit, but then... > >> When evaluating the chain for final receipt, there are two states to >> worry about as a matter of local policy: 1) you trust all the >> signatories on the chain 2) there is an untrusted signatory on the >> chain > > Which is why it's a bad idea to sign if you're not modifying, because > then everybody has to trust you or their chain breaks, even though you > didn't do anything which required signing. I don't have an opinion about whether this conclusion is correct, but I'm quite certain it a type of consideration that needs to be fundamental, to recommendations about usage. Who should do what, and why? What are the upsides of their doing or not? Downsides? >> Without the ARC Seal this determination is not possible and there is >> no way to evaluate the ARC chain for delivery as a final receiver. > > And this is the crux of our disagreement. Seth thinks it's necessary to > do more than signing a statement that you believed the message was > authenticated when you got it, in a way that the next hop can verify > your signature over your own Authentication Results plus the content of > the message. I disagree. > > I'm proposing exactly the same stragety DKIM uses, just with series of > signed "chain of custody" statements rather than the DKIM signature > having to align with the sender domain. by 'strategy DKIM uses' what do you mean exactly? I'm guessing you mean having the signature cover more of the header and all of the body, but please confirm or clarify. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Aug 11 17:16:31 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2AB71324A2 for ; Fri, 11 Aug 2017 17:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6LRwuRHR_Pr7 for ; Fri, 11 Aug 2017 17:16:27 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12EE91324A7 for ; Fri, 11 Aug 2017 17:16:27 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id m85so2749406wma.0 for ; Fri, 11 Aug 2017 17:16:26 -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=6lhE17tElZ4vjUzweXnCID5W7f3Q7THlUpoEZ4J/bYM=; b=c9cTr80T4fMhnjyoA/te4jwls5gQXREEbqKCrPzqPtGHhKD1vS70eQfgVyknEuTadp +Ij4g4y0cQcGq1Osbv3RJ27QkammeJ0YBy9aZgKVjVkhWpAtIgaNIQ7kPtJNuV3iV88b HkOx051WNH76EHaNlX2gVS2n0nvNVch9ZIIQg= 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=6lhE17tElZ4vjUzweXnCID5W7f3Q7THlUpoEZ4J/bYM=; b=Cx0sci9BUrkzs9w0B5C9+5lzA2zKVI+CxoBABVDyX/+a8m+WJess82p1rW5wzzlOSF LeB+kG24wBLTme6/BoxmeVSzvfVLa1Cm0iYlzHbs+zrCoSKJFvu23HzLooeXjwhSe2Ob TrhpwuC/HiSwHywEtWJSHhqq+7PmrcT+V3X11xKcEuXk4FTXziqHmpeYJt+O5DyUZISe b0v47DyxNhUwSZKe4YQiiy+TOB1uZo3dAYiM6TDt/XHGRJtxpLFSybx5jIv2sJdiSbVU lWg2qYxYS9P1sNAW28yZJjgGzLiz1XuOiXofHJpnFJNdhXDY7zRZCHk+zf0dNnAyMUZa 7Cvw== X-Gm-Message-State: AHYfb5jiINiH2gDhZG7iZea5SClFIHUTETArUCikQgjc6UDNW8mkBVgW NgplmCA8dDTCJWnhIhz5tLoiAn+Z5ZHmc7ALGQ== X-Received: by 10.80.166.133 with SMTP id e5mr17046481edc.71.1502496985523; Fri, 11 Aug 2017 17:16:25 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.80.178.229 with HTTP; Fri, 11 Aug 2017 17:16:24 -0700 (PDT) In-Reply-To: <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> From: "Kurt Andersen (b)" Date: Fri, 11 Aug 2017 17:16:24 -0700 X-Google-Sender-Auth: 5kApih6ovpD4CUJpA9ohh792FGc Message-ID: To: Bron Gondwana Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0dd11e193afd05568357ea" Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Aug 2017 00:16:29 -0000 --94eb2c0dd11e193afd05568357ea Content-Type: text/plain; charset="UTF-8" On Fri, Aug 11, 2017 at 4:54 PM, Bron Gondwana wrote: > . . . it's a bad idea to sign if you're not modifying, because then > everybody has to trust you or their chain breaks, even though you didn't do > anything which required signing. > > > In state #1, you don't need a chain of ARC Seal. You just need each site > to sign their own AAR and each AAR to include "arc=pass" for the previous > AMS. You trust the sites, so you trust them to verify the ARC status on > ingress. > In the current layout, "signing [the] AAR" is done via the AS. We wanted to keep the AAR as close to the A-R header as we could to maximize leverage of previous definitions rather than inventing an entirely new one. Initially, we had intended the AMS to sign over the AAR, but people objected to signing the AAR within both the AMS and AS scopes. > > And this is the crux of our disagreement. Seth thinks it's necessary to > do more than signing a statement that you believed the message was > authenticated when you got it, in a way that the next hop can verify your > signature over your own Authentication Results plus the content of the > message. I disagree. > One could replace the AMS with an "egress DKIM" signature, but then you would still have to decide what to do about alignment on this new DKIM signature. That's why we built the AMS - to avoid the question of alignment and have the ARCset as a self-contained "package". I see the point that you are driving at regarding the claim of "forgery", but I don't consider that any more or less of a forgery than what the IETF mailman will do to this message en route to the recipients. Mailman changes the headers (Subject) and body. Seems like that's about what you've done in the sample message...but at least you took responsibility for doing so with ARCset[7] (or someone with the private key for brong.net ;-) ). --Kurt --94eb2c0dd11e193afd05568357ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Aug 11, 2017 at 4:54 PM, Bron Gondwana <brong@fastmailteam.com> wrote:
. . . it's a bad idea to sign if = you're not modifying, because then everybody has to trust you or their = chain breaks, even though you didn't do anything which required signing= .

<elided>=C2=A0

In state #1, you don't need a chain of ARC Seal.=C2=A0 You just= need each site to sign their own AAR and each AAR to include "arc=3Dp= ass" for the previous AMS.=C2=A0 You trust the sites, so you trust the= m to verify the ARC status on ingress.
In the current layout, "signing [the] AAR" is done vi= a the AS. We wanted to keep the AAR as close to the A-R header as we could = to maximize leverage of previous definitions rather than inventing an entir= ely new one. Initially, we had intended the AMS to sign over the AAR, but p= eople objected to signing the AAR within both the AMS and AS scopes.
<= div>
<elided>=C2=A0

And this is the crux of our disagreement.=C2=A0 Seth thinks it's neces= sary to do more than signing a statement that you believed the message was = authenticated when you got it, in a way that the next hop can verify your s= ignature over your own Authentication Results plus the content of the messa= ge.=C2=A0 I disagree.

=C2=A0One= could replace the AMS with an "egress DKIM" signature, but then = you would still have to decide what to do about alignment on this new DKIM = signature. That's why we built the AMS - to avoid the question of align= ment and have the ARCset as a self-contained "package".

--Kurt

--94eb2c0dd11e193afd05568357ea-- From nobody Fri Aug 11 17:19:41 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9628132466 for ; Fri, 11 Aug 2017 17:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=RKBXjFvd; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=kTFtvF/G Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vwq-FJZFS1Av for ; Fri, 11 Aug 2017 17:19:39 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 514D6132460 for ; Fri, 11 Aug 2017 17:19:39 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id B842D20DC6 for ; Fri, 11 Aug 2017 20:19:38 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Fri, 11 Aug 2017 20:19:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=3/Q8cDyVnIu+kpYSp 7scRPCAU0ALlrtr/mhvWgp7bCU=; b=RKBXjFvd4oZBu7l+bd64tNdfVVJUkGRCf X8Wzrxv6E50xx589mia43BIKK8SLJGOq/tyxoXRa6qRv8+fp0HYDW511Xo6BFj2W AbEA4gOOe1++5Q5qTrYbHD6ylM79QMqxrBB2BY1sY5FPVAArM3wz/EE/DMfqAvIo JZIAhqLgfu81+e3Mv1NVxuPMLhYmEBU7Ckv9UqKXseL6oW0P8LvY0544IZ+E2VNu NYgUBtvSqCKBg5k2hv7Czk5S+at8Cyd6i9pTAWDoQH4nTJq6WKqrFGF9Rj5EPJb9 +9X9JZK/bIQydSj1D+cofGGlp6BlPa5b9LFTVx38a4GKlsMwKiikw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=3/Q8cD yVnIu+kpYSp7scRPCAU0ALlrtr/mhvWgp7bCU=; b=kTFtvF/GGGWFhhkH3ssoZP hbS4GAqf768X5Wx30yyDeE2LE/cA0NXwVSq8L/nK0eFi/WlnCXfHj3YW0h/qECjT DX4NZNOzkyo9MSm1xKix+hGemHwWQ9Wz/H0/21/wEaMCEostZcClyya6Ib8umiyL nz8mZbFvviFNy35hUg5z5ctdJ6XDcJQKaW5NXFU2W7g4CzZjHSwPAekOo0J09zUz uPOr+kGeiZtEcunvlNV2KPfFs5jujl352O+/VBSAVeVeAVtmRqaN/U/IYZTY/vSI 6EbqMAOhHh2DDlnR/uZQr9AkA+WOB5tOc8khPkigF6o5NfuBIcLRi5g3n6gTG89w == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 91090BAB71; Fri, 11 Aug 2017 20:19:38 -0400 (EDT) Message-Id: <1502497178.4103451.1070917304.23DD466D@webmail.messagingengine.com> From: Bron Gondwana To: dmarc@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150249717841034510" X-Mailer: MessagingEngine.com Webmail Interface - ajax-33d44821 In-Reply-To: <166070f0-4ba1-70da-1f73-885b4a7f7640@gmail.com> Date: Sat, 12 Aug 2017 10:19:38 +1000 References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> <166070f0-4ba1-70da-1f73-885b4a7f7640@gmail.com> Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Aug 2017 00:19:41 -0000 This is a multi-part message in MIME format. --_----------=_150249717841034510 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Sat, 12 Aug 2017, at 10:04, Dave Crocker wrote: > On 8/11/2017 4:54 PM, Bron Gondwana wrote: >> On Sat, 12 Aug 2017, at 03:22, Dave Crocker wrote: >> >> I'm just picking out the key quote here: >> >>> On 8/7/2017 4:22 PM, Seth Blank wrote: >>> >>> When validating an ARC signed message, one verifies the latest AMS>>> (which must validate), and *the entire chain* of ARC Seals, not >>> only>>> the latest. This guarantees you a list of all message >>> signatories ->>> the chain of custody we're talking about. >> >> Yes, I follow this bit, but then... >> >>> When evaluating the chain for final receipt, there are two >>> states to>>> worry about as a matter of local policy: 1) you trust all the >>> signatories on the chain 2) there is an untrusted signatory on the>>> chain >> >> Which is why it's a bad idea to sign if you're not modifying, because>> then everybody has to trust you or their chain breaks, even >> though you>> didn't do anything which required signing. > > I don't have an opinion about whether this conclusion is correct, but> I'm quite certain it a type of consideration that needs to be > fundamental, to recommendations about usage. Who should do what, and> why? What are the upsides of their doing or not? Downsides? > > > >>> Without the ARC Seal this determination is not possible and >>> there is>>> no way to evaluate the ARC chain for delivery as a final receiver.>> >> And this is the crux of our disagreement. Seth thinks it's >> necessary to>> do more than signing a statement that you believed the message was >> authenticated when you got it, in a way that the next hop can verify>> your signature over your own Authentication Results plus the >> content of>> the message. I disagree. >> >> I'm proposing exactly the same stragety DKIM uses, just with >> series of>> signed "chain of custody" statements rather than the DKIM signature >> having to align with the sender domain. > > by 'strategy DKIM uses' what do you mean exactly? I'm guessing > you mean> having the signature cover more of the header and all of the body, but> please confirm or clarify. Sorry - yes, to clarify... DKIM signs the entire body plus parts of the header. In the strategy I am proposing, site "X" modifying a message in transit (e.g. a mailing list) would add their own DKIM-like header (ARC-Message- Signature is a perfectly fine name for it) which signed the new "body and parts of the header", including a statement that site "X" had verified the message authentication before modifying it (ARC-Authentication- Results is a perfectly fine name for that statement). That gives a complete chain of custody. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_150249717841034510 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Sat, 12 Aug 2017, at 10:04, Dave Crocker wrote:
On 8/11/2017 4:54 PM, Bron Gondwana wrote:
On Sat, 12 Aug 2017, at 03:22, Dave Crocker wrote:

I'm just picking out the key quote here:

On 8/7/2017 4:22 PM, Seth Blank wrote:

  When validating an ARC signed message, one verifies the latest AMS
  (which must validate), and *the entire chain* of ARC Seals, not only
  the latest. This guarantees you a list of all message signatories -
  the chain of custody we're talking about.

Yes, I follow this bit, but then...

  When evaluating the chain for final receipt, there are two states to
  worry about as a matter of local policy: 1) you trust all the
  signatories on the chain 2) there is an untrusted signatory on the
  chain

Which is why it's a bad idea to sign if you're not modifying, because
then everybody has to trust you or their chain breaks, even though you
didn't do anything which required signing.

I don't have an opinion about whether this conclusion is correct, but
I'm quite certain it a type of consideration that needs to be
fundamental, to recommendations about usage.  Who should do what, and
why?  What are the upsides of their doing or not?  Downsides?



  Without the ARC Seal this determination is not possible and there is
  no way to evaluate the ARC chain for delivery as a final receiver.

And this is the crux of our disagreement.  Seth thinks it's necessary to
do more than signing a statement that you believed the message was
authenticated when you got it, in a way that the next hop can verify
your signature over your own Authentication Results plus the content of
the message.  I disagree.

I'm proposing exactly the same stragety DKIM uses, just with series of
signed "chain of custody" statements rather than the DKIM signature
having to align with the sender domain.

by 'strategy DKIM uses' what do you mean exactly?  I'm guessing you mean
having the signature cover more of the header and all of the body, but
please confirm or clarify.

Sorry - yes, to clarify...

DKIM signs the entire body plus parts of the header.

In the strategy I am proposing, site "X" modifying a message in transit (e.g. a mailing list) would add their own DKIM-like header (ARC-Message-Signature is a perfectly fine name for it) which signed the new "body and parts of the header", including a statement that site "X" had verified the message authentication before modifying it (ARC-Authentication-Results is a perfectly fine name for that statement).

That gives a complete chain of custody.

Bron.

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


--_----------=_150249717841034510-- From nobody Fri Aug 11 17:27:29 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DBE113240D for ; Fri, 11 Aug 2017 17:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=oY/dr/BW; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=X9BMrQyg Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRL7dV9uotWH for ; Fri, 11 Aug 2017 17:27:24 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EAB71275FD for ; Fri, 11 Aug 2017 17:27:24 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 8968F20EA9 for ; Fri, 11 Aug 2017 20:27:21 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Fri, 11 Aug 2017 20:27:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=UY1s3WHbmrYbJKqge 198Rpysj1H4si7UmO8oZxY9juM=; b=oY/dr/BWPf1x3dbalZY3DfI8aSn7B1Jtf M9M+NznBVmS+uvRVVPbkyEVoHOHqbklulg+2vB+i8pbfiPWg8BB8V7mJvekvDLo1 OZx2quCOdXrsTuY9Ue4k/gC+Q3mazt+owFal1Hrk/O1tb6YsaSpJ+tLCiyOcuAzy RGQsq5UDVgBOlXDqwdIIOyMDUmhpqcss7m2vmAeOFKasDn7sOBCVz2TcGgNpfrn2 cbsYwPlvYCGyiIhPF4nlTcyFT/uspPoPriEGavzYFOEUcfDquadaBnGeQ7GzJa89 mvE6CXseQ/oLTco9Km+F/pvMWd5XjulL2X/RIdSLwIWzAKBdu8X4A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=UY1s3W HbmrYbJKqge198Rpysj1H4si7UmO8oZxY9juM=; b=X9BMrQygshSdKtssJvfCAk BENH0Av+b7pmpjR36OB/D9+pzAG5cydinlBgAGdUso3kWUb9dAy6sWspfQN2xHv5 vjNCU8vVjGMKrX/T8ssKjfvtDZEWHfBZ7h6SwruDIO2qxhEsSUhoReC8n8ZZNEEY AohOgIznH7gZgPRp3SB3WkfKlMnBzMny9NRiPibe5FlDtGLFwr8u/BqwSBjHlH60 F8Z3w1iLk/0qLS9S/rWNJR1mQxE9ePVwxCEmMLl6D1Rl3orSb3t0bAklVG16HPE8 RtB0AxdOcuyt04VautkXEB1ItaKqFvYIw/IW7/9/L8j6dedFZhYnSf8Z/pcvNGQA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 64E84BAB71; Fri, 11 Aug 2017 20:27:21 -0400 (EDT) Message-Id: <1502497641.4105093.1070922904.7A15BD5D@webmail.messagingengine.com> From: Bron Gondwana To: dmarc@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150249764141050930" X-Mailer: MessagingEngine.com Webmail Interface - ajax-33d44821 References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> In-Reply-To: Date: Sat, 12 Aug 2017 10:27:21 +1000 Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Aug 2017 00:27:27 -0000 This is a multi-part message in MIME format. --_----------=_150249764141050930 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Sat, 12 Aug 2017, at 10:16, Kurt Andersen (b) wrote: > On Fri, Aug 11, 2017 at 4:54 PM, Bron Gondwana > wrote:>> __ >> . . . it's a bad idea to sign if you're not modifying, because then >> everybody has to trust you or their chain breaks, even though you >> didn't do anything which required signing.> > I would like to address this point, but maybe we should have a separate thread for it? I would strongly argue that sites not changing the message SHOULD NOT add ARC headers. I spelled out the reasons in my initial posting on this thread. >> In state #1, you don't need a chain of ARC Seal. You just need each >> site to sign their own AAR and each AAR to include "arc=pass" for the >> previous AMS. You trust the sites, so you trust them to verify the >> ARC status on ingress.> > In the current layout, "signing [the] AAR" is done via the AS. We > wanted to keep the AAR as close to the A-R header as we could to > maximize leverage of previous definitions rather than inventing an > entirely new one. Initially, we had intended the AMS to sign over the > AAR, but people objected to signing the AAR within both the AMS and > AS scopes. I can understand that. I would fix it by not having AS scopes rather than removing AAR from AMS. > >> And this is the crux of our disagreement. Seth thinks it's necessary >> to do more than signing a statement that you believed the message was >> authenticated when you got it, in a way that the next hop can verify >> your signature over your own Authentication Results plus the content >> of the message. I disagree.> > One could replace the AMS with an "egress DKIM" signature, but then > you would still have to decide what to do about alignment on this new > DKIM signature. That's why we built the AMS - to avoid the question > of alignment and have the ARCset as a self-contained "package". Yes - calling it something different from DKIM-Signature is good, so that nobody tries to check alignment with the "From:" domain. But I don't see any reason to replace AMS - it does what's needed (apart from not signing the AAR). It's AS that bothers me. > I see the point that you are driving at regarding the claim of > "forgery", but I don't consider that any more or less of a forgery > than what the IETF mailman will do to this message en route to the > recipients. Mailman changes the headers (Subject) and body. Seems like > that's about what you've done in the sample message...but at least you > took responsibility for doing so with ARCset[7] (or someone with the > private key for brong.net ;-) ). It's true, anybody at FastMail could have done that. At least anybody with production access to our DKIM keys database :) The point with forgery is that "a chain of unbroken ARC-Seals" is meaningless, because they're not protecting anything. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_150249764141050930 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Sat, 12 Aug 2017, at 10:16, Kurt Andersen (b) wrote:
On Fri, Aug 11, 2017 at 4:54 PM, Bron Gondwana <brong@fastmailteam.com> wrote:

. . . it's a bad idea to sign if you're not modifying, because then everybody has to trust you or their chain breaks, even though you didn't do anything which required signing.

<elided> 

I would like to address this point, but maybe we should have a separate thread for it?  I would strongly argue that sites not changing the message SHOULD NOT add ARC headers.  I spelled out the reasons in my initial posting on this thread.

In state #1, you don't need a chain of ARC Seal.  You just need each site to sign their own AAR and each AAR to include "arc=pass" for the previous AMS.  You trust the sites, so you trust them to verify the ARC status on ingress.

In the current layout, "signing [the] AAR" is done via the AS. We wanted to keep the AAR as close to the A-R header as we could to maximize leverage of previous definitions rather than inventing an entirely new one. Initially, we had intended the AMS to sign over the AAR, but people objected to signing the AAR within both the AMS and AS scopes.

I can understand that.  I would fix it by not having AS scopes rather than removing AAR from AMS.

<elided> 
And this is the crux of our disagreement.  Seth thinks it's necessary to do more than signing a statement that you believed the message was authenticated when you got it, in a way that the next hop can verify your signature over your own Authentication Results plus the content of the message.  I disagree.

 One could replace the AMS with an "egress DKIM" signature, but then you would still have to decide what to do about alignment on this new DKIM signature. That's why we built the AMS - to avoid the question of alignment and have the ARCset as a self-contained "package".

Yes - calling it something different from DKIM-Signature is good, so that nobody tries to check alignment with the "From:" domain.

But I don't see any reason to replace AMS - it does what's needed (apart from not signing the AAR).  It's AS that bothers me.

I see the point that you are driving at regarding the claim of "forgery", but I don't consider that any more or less of a forgery than what the IETF mailman will do to this message en route to the recipients. Mailman changes the headers (Subject) and body. Seems like that's about what you've done in the sample message...but at least you took responsibility for doing so with ARCset[7] (or someone with the private key for brong.net ;-) ).

It's true, anybody at FastMail could have done that.  At least anybody with production access to our DKIM keys database :)

The point with forgery is that "a chain of unbroken ARC-Seals" is meaningless, because they're not protecting anything.

Bron.


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


--_----------=_150249764141050930-- From nobody Fri Aug 11 17:36:33 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 217F1132497 for ; Fri, 11 Aug 2017 17:36:32 -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 bzbs754teixj for ; Fri, 11 Aug 2017 17:36:30 -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 08A46132491 for ; Fri, 11 Aug 2017 17:36:30 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id i66so3323173wmg.0 for ; Fri, 11 Aug 2017 17:36:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=ThhHLsBnLgWu59hAqQryMB4RRAYiaQ54WXr0X5WotXo=; b=ebMsn2+mkya/zv0w20s9Zll8hQeXV3AUywjj6nQmfXet5+9kOQxrM4FY/wx2OjGVH/ nJf0rU0Cok/OKRI03+ZVNrWRFFQzeJyCWijQ4QX7v7b9QoJmJ8ub8JRaEQSLnu53H0mq 6jAVr99eRncCtHkGDLkjiIZiYuGbwUso8KUB0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc; bh=ThhHLsBnLgWu59hAqQryMB4RRAYiaQ54WXr0X5WotXo=; b=Fxc32BG9YjEDorsDfnWYQ/898KZbH8Q2YZOFUpmY7yts10j7K/SSsDK0WtVDvKbSn6 zaZZxEgNt6kqNykFbJePhxnAbvW+KpdbJDOTQA3qBvPtBmROg8PY9iCv1XL1ZzuyWXyp WBeHk4pGYwLjCDQiV/tgb3f8Uopk2S255oO5xm1gdwZlbXZ8LmRdOIWjXPe27mXCB59U 2N5fxZBF0KXw5T5vzX2EdF2iJbNWffZeTaLGFyK+y67eRggYTx8CaJNm6nYoagILxP9r wlrdBsbsU2hDjd4tP+Y0yswWYfLWgLxkqUvwFvanIAvZ/YNfZtSI43Fv1L1N1O41BZPr 9asA== X-Gm-Message-State: AHYfb5jLHdg8P02GuZ06a/StfgPgJdHDf8HVTpuCXCSAy5LopdankDYv vSRGZnDC38hYXm3RuQqFSqZAyCHXYglm X-Received: by 10.80.221.2 with SMTP id t2mr17671647edk.134.1502498188538; Fri, 11 Aug 2017 17:36:28 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.80.178.229 with HTTP; Fri, 11 Aug 2017 17:36:27 -0700 (PDT) From: "Kurt Andersen (b)" Date: Fri, 11 Aug 2017 17:36:27 -0700 X-Google-Sender-Auth: n3wZKiVVZM_44VYJ0M7WCW4qa9U Message-ID: To: Bron Gondwana Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="f403043e7314cdba6c0556839ee1" Archived-At: Subject: [dmarc-ietf] ARC signing when *not* modifying the message... X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Aug 2017 00:36:32 -0000 --f403043e7314cdba6c0556839ee1 Content-Type: text/plain; charset="UTF-8" Splitting out this discussion point into a new thread... On Fri, Aug 11, 2017 at 5:27 PM, Bron Gondwana wrote: > On Sat, 12 Aug 2017, at 10:16, Kurt Andersen (b) wrote: > > On Fri, Aug 11, 2017 at 4:54 PM, Bron Gondwana > wrote: > > > . . . it's a bad idea to sign if you're not modifying, because then > everybody has to trust you or their chain breaks, even though you didn't do > anything which required signing. > > I would like to address this point, but maybe we should have a separate > thread for it? I would strongly argue that sites not changing the message > SHOULD NOT add ARC headers. I spelled out the reasons in my initial > posting on this thread. > Various folks in the ARC space have debated this particular point. You make a good argument from a trust point of view. The reasoning for our (current) advice to "always" ARC-seal is that not sealing requires a comprehensive understanding of everything that might happen within the realm of your ADMD - and that is usually not available beyond the smallest of realms. By "always" sealing, the ADMD does not have to worry about whether the message might pass through some previously unknown internal list or forwarding mechanism which may or may not break the signature on the received message. It's certainly possible for an ADMD to ARC-seal upon receipt and then redact that seal upon egress if the AMS is unbroken, but I'm worried about explaining that operational nuance effectively (given that it has only recently become known to some people that the ingress state needs to be propagated through to the egress sealing process). --Kurt --f403043e7314cdba6c0556839ee1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Splitting out this discussion p= oint into a new thread...

On Fri, Aug 11,= 2017 at 5:27 PM, Bron Gondwana <brong@fastmailteam.com> wrote:
On Sat, 12 Aug 2017,= at 10:16, Kurt Andersen (b) wrote:
On Fri, Aug 11, 2017 at 4:54 PM, Bron Gondwana <brong@fastmailteam.c= om> wrote:
<= /u>
. . . it's a bad idea to sign if = you're not modifying, because then everybody has to trust you or their = chain breaks, even though you didn't do anything which required signing= .
I would like to address this point,= but maybe we should have a separate thread for it?=C2=A0 I would strongly = argue that sites not changing the message SHOULD NOT add ARC headers.=C2=A0= I spelled out the reasons in my initial posting on this thread.

Various folks in the ARC space have debat= ed this particular point. You make a good argument from a trust point of vi= ew.=C2=A0

The reasoning for our (current) advice t= o "always" ARC-seal is that not sealing requires a comprehensive = understanding of everything that might happen within the realm of your ADMD= - and that is usually not available beyond the smallest of realms. By &quo= t;always" sealing, the ADMD does not have to worry about whether the m= essage might pass through some previously unknown internal list or forwardi= ng mechanism which may or may not break the signature on the received messa= ge.

It's certainly possible for an ADMD to ARC= -seal upon receipt and then redact that seal upon egress if the AMS is unbr= oken, but I'm worried about explaining that operational nuance effectiv= ely (given that it has only recently become known to some people that the i= ngress state needs to be propagated through to the egress sealing process).=

--Kurt

--f403043e7314cdba6c0556839ee1-- From nobody Fri Aug 11 17:50:52 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 748A6132467 for ; Fri, 11 Aug 2017 17:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=Ni7gZq/k; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Seo84kFR Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5e-ibg_QFEK for ; Fri, 11 Aug 2017 17:50:50 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E51CF13245A for ; Fri, 11 Aug 2017 17:50:49 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 5ACC120E8C for ; Fri, 11 Aug 2017 20:50:49 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Fri, 11 Aug 2017 20:50:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=Xn3+MCw7PHh6KO9jX SJZxhoXQiMszg3Moj3kzYIwLVU=; b=Ni7gZq/kpPvUFeoMxYRjIHXMfhkkiWFpQ m/1SYV9zsJwV18UFITx+G5b/opo3p6o+AqzEzrVI5/WnHHwy2mXV7SU5jgxUcOjF aXGINflhD32y2W8mwBbRah2taEoHqdzPOSRWfTBbt7BTjdZrnM5CcjsAy5EFEoFn ci+p7wZwWcqrclIARfS6UZAN2pddFrLDXZoaCOdygLu6bQhMP2dBJblGqTkoHGk5 uA/mp+jxOn5cEnl97kxtEM58JQnMSOAOJWzoA/8/yyy1dixnSgkSamodQwl8DWFn 4MYsf0uObmOxVVXao72W8rfXn/vlas+v9qouPmO5QGgEJcQkUWcVQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=Xn3+MC w7PHh6KO9jXSJZxhoXQiMszg3Moj3kzYIwLVU=; b=Seo84kFR40BdRp9hMqsMFI nI43NGS6IXdw7qvIaiUXD6KRg8HTu42KihXApB39zf9wrt1wqSk5QB1FAGOINoE2 MAlaJecE3gHQQkY16z+HjjQTBHqZ2nAsbDi7vnq9ey8nduDxq6StLPWeE34WFYEf GWgrc1babZJzCZrteE/ThGs4bVIBchBE7ly1wjp6+XLGxvESeLKZkbWTDvryTfBh TNix1GlZVvCrwXjF0rGsuHOMdzeCGzilTmgUXYqatRwj+0MDCBeSoMMkA76oIHXP UH8Z/n3GFEFCMgTeSrf3bVkuUdoXdyYU5MsFapjNZTkq01wRBBOCbn+rI/zMQO7g == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 341B9BAB71; Fri, 11 Aug 2017 20:50:49 -0400 (EDT) Message-Id: <1502499049.4110221.1070935024.1071B9AE@webmail.messagingengine.com> From: Bron Gondwana To: dmarc@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150249904941102210" X-Mailer: MessagingEngine.com Webmail Interface - ajax-33d44821 Date: Sat, 12 Aug 2017 10:50:49 +1000 In-Reply-To: References: Archived-At: Subject: Re: [dmarc-ietf] ARC signing when *not* modifying the message... X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Aug 2017 00:50:51 -0000 This is a multi-part message in MIME format. --_----------=_150249904941102210 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Sat, 12 Aug 2017, at 10:36, Kurt Andersen (b) wrote: > Splitting out this discussion point into a new thread... > > On Fri, Aug 11, 2017 at 5:27 PM, Bron Gondwana > wrote:>> __ >> >> On Sat, 12 Aug 2017, at 10:16, Kurt Andersen (b) wrote: >>> On Fri, Aug 11, 2017 at 4:54 PM, Bron Gondwana >>> wrote:>>>> __ >>>> . . . it's a bad idea to sign if you're not modifying, because then >>>> everybody has to trust you or their chain breaks, even though you >>>> didn't do anything which required signing.>> >> I would like to address this point, but maybe we should have a >> separate thread for it? I would strongly argue that sites not >> changing the message SHOULD NOT add ARC headers. I spelled out the >> reasons in my initial posting on this thread.> > Various folks in the ARC space have debated this particular point. You > make a good argument from a trust point of view.> > The reasoning for our (current) advice to "always" ARC-seal is that > not sealing requires a comprehensive understanding of everything that > might happen within the realm of your ADMD - and that is usually not > available beyond the smallest of realms. By "always" sealing, the ADMD > does not have to worry about whether the message might pass through > some previously unknown internal list or forwarding mechanism which > may or may not break the signature on the received message. How does that help? If there is an internal list or forwarding mechanism which breaks the signature then you're going to need to ARC- Seal it again afterwards. If you added an Authentication-Results header on ingress which you know is yours because you always add it on ingress (and strip other Authentication- Results headers), then you can confirm from that header that you checked ARC on ingress, and then you can ARC-Seal on egress. At that point any ARC you added on ingress is either unbroken (in which case pointless anyway) or broken (in which case you need to re-ARC-sign anyway). Either way, the ingress ARC is useless. > It's certainly possible for an ADMD to ARC-seal upon receipt and then > redact that seal upon egress if the AMS is unbroken, but I'm worried > about explaining that operational nuance effectively (given that it > has only recently become known to some people that the ingress state > needs to be propagated through to the egress sealing process). Again - why seal on ingress? It's bogus. * check authentication on ingress * add authentication on egress That's the pattern that means something and works. Otherwise your internal mechanisms are going to have to be either ARC aware anyway, or you'll have to fix up ARC anyway. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_150249904941102210 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Sat, 12 Aug 2017, at 10:36, Kurt Andersen (b) wrote:
Splitting out this discussion point into a new thread...

On Fri, Aug 11, 2017 at 5:27 PM, Bron Gondwana <brong@fastmailteam.com> wrote:


On Sat, 12 Aug 2017, at 10:16, Kurt Andersen (b) wrote:
On Fri, Aug 11, 2017 at 4:54 PM, Bron Gondwana <brong@fastmailteam.com> wrote:

. . . it's a bad idea to sign if you're not modifying, because then everybody has to trust you or their chain breaks, even though you didn't do anything which required signing.

I would like to address this point, but maybe we should have a separate thread for it?  I would strongly argue that sites not changing the message SHOULD NOT add ARC headers.  I spelled out the reasons in my initial posting on this thread.

Various folks in the ARC space have debated this particular point. You make a good argument from a trust point of view. 

The reasoning for our (current) advice to "always" ARC-seal is that not sealing requires a comprehensive understanding of everything that might happen within the realm of your ADMD - and that is usually not available beyond the smallest of realms. By "always" sealing, the ADMD does not have to worry about whether the message might pass through some previously unknown internal list or forwarding mechanism which may or may not break the signature on the received message.

How does that help?  If there is an internal list or forwarding mechanism which breaks the signature then you're going to need to ARC-Seal it again afterwards.

If you added an Authentication-Results header on ingress which you know is yours because you always add it on ingress (and strip other Authentication-Results headers), then you can confirm from that header that you checked ARC on ingress, and then you can ARC-Seal on egress.

At that point any ARC you added on ingress is either unbroken (in which case pointless anyway) or broken (in which case you need to re-ARC-sign anyway).  Either way, the ingress ARC is useless.

It's certainly possible for an ADMD to ARC-seal upon receipt and then redact that seal upon egress if the AMS is unbroken, but I'm worried about explaining that operational nuance effectively (given that it has only recently become known to some people that the ingress state needs to be propagated through to the egress sealing process).

Again - why seal on ingress?  It's bogus.

* check authentication on ingress
* add authentication on egress

That's the pattern that means something and works.  Otherwise your internal mechanisms are going to have to be either ARC aware anyway, or you'll have to fix up ARC anyway.

Bron.

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


--_----------=_150249904941102210-- From nobody Fri Aug 11 17:55:00 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC2AF1324C6 for ; Fri, 11 Aug 2017 17:54:58 -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 dyobmW5V5jR5 for ; Fri, 11 Aug 2017 17:54:56 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C188F1324BA for ; Fri, 11 Aug 2017 17:54:55 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id f15so3389594wmg.1 for ; Fri, 11 Aug 2017 17:54:55 -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=1n2V8nKOt+UOl+DgjIJYaVdVCtdeN0eIA7aK2ypPdFQ=; b=JOAzTP+xmUyAu2EpbtaG5wtJM29VzMQoSocvvk0ckOLgztNOC56ZnQnnz5SSCIIDgD svdEY5ZKBJS8D1ZeJGnjqq7reYCdavJ5SSweIrwCgfPmsF7zPbA97Spmr1oQNMFnOL5q fO/LlzfdFP2AIidaeFEeCQoRq6uFEC4CpH9gk= 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=1n2V8nKOt+UOl+DgjIJYaVdVCtdeN0eIA7aK2ypPdFQ=; b=p7irWDlJG05XmmGtoqMORSIYtNwJ3qtwgpj1DwctEQAQGbHtcslM1P/L3DKhOpJstF 9gBG9gdjm2jQuql2WfuEsmqFg1Ag6p7ek347tadX4pNhJgcku2uq9Nee+a4ecPUKCnBv vBzZSFI7pMhhcwqJdNWwjwaUAqsuqTS85DwDtKuiBOcn36z8AmzRC56V66Xke7WOjl+0 5aPDprMMBm+nyvMpTAz4FWWat/+rLzabx1Fhi5meTQjYYAd3w6q8QFvirLtpK5cy+pUD w54Sk+WF9g4SkCZDcSpGSfRe9vUzTY9gaC8DHZcYXjIpf5C4KzjsaDW6DYBAR+WaFNiR wItQ== X-Gm-Message-State: AHYfb5gpdytXqdrmRrA9s8E2NUsNWD71E12K97f6LFCx/9HtysLZjIjM plkbloTXyb/ZDnWxzJBRgMNDMjFZJGq9 X-Received: by 10.80.187.13 with SMTP id y13mr17285996ede.122.1502499294124; Fri, 11 Aug 2017 17:54:54 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.80.178.229 with HTTP; Fri, 11 Aug 2017 17:54:53 -0700 (PDT) In-Reply-To: <1502499049.4110221.1070935024.1071B9AE@webmail.messagingengine.com> References: <1502499049.4110221.1070935024.1071B9AE@webmail.messagingengine.com> From: "Kurt Andersen (b)" Date: Fri, 11 Aug 2017 17:54:53 -0700 X-Google-Sender-Auth: Dcc1MoMIA880u51fuqDKgstp2RU Message-ID: To: Bron Gondwana Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c19c61cb3c38f055683e055" Archived-At: Subject: Re: [dmarc-ietf] ARC signing when *not* modifying the message... X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Aug 2017 00:54:59 -0000 --94eb2c19c61cb3c38f055683e055 Content-Type: text/plain; charset="UTF-8" On Fri, Aug 11, 2017 at 5:50 PM, Bron Gondwana wrote: > > Again - why seal on ingress? It's bogus. > > * check authentication on ingress > * add authentication on egress > > That's the pattern that means something and works. Otherwise your > internal mechanisms are going to have to be either ARC aware anyway, or > you'll have to fix up ARC anyway. > As long as your method of communicating the ingress auth check survives the transit of your internal infrastructure (which A-R does not necessarily do as a result of some brain-dead gateway implementations), I agree. Sealing on ingress is one such way to provide that communication from ingress point to egress point but is a bit noisy to do so. --Kurt --94eb2c19c61cb3c38f055683e055 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Aug 11, 2017 at 5:50 PM, Bron Gondwana <brong@fastmailteam.com> wrote:

Again - why seal on ingress?=C2=A0 It's b= ogus.

* check authentication on ingress
* add authentication on egress

That's the pattern that means somethin= g and works.=C2=A0 Otherwise your internal mechanisms are going to have to = be either ARC aware anyway, or you'll have to fix up ARC anyway.

<= div class=3D"gmail_extra">As long as your method of communicating the ingre= ss auth check survives the transit of your internal infrastructure (which A= -R does not necessarily do as a result of some brain-dead gateway implement= ations), I agree. Sealing on ingress is one such way to provide that commun= ication from ingress point to egress point but is a bit noisy to do so.

--Kurt
--94eb2c19c61cb3c38f055683e055-- From nobody Fri Aug 11 18:01:12 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A84D132480 for ; Fri, 11 Aug 2017 18:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=POGWiU7b; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=J7cDKD3f Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGRha75Yn6jR for ; Fri, 11 Aug 2017 18:01:07 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7182C13247D for ; Fri, 11 Aug 2017 18:01:07 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id C8FD920F2B; Fri, 11 Aug 2017 21:01:06 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Fri, 11 Aug 2017 21:01:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=ncu/y7 KudGNBmPnjPJyE69GboBTIYhbNARcE3eG2XYw=; b=POGWiU7bw5HPnx9zJK6wqP osFemlPvZ9cx7whpzqnnyK18vl6t0x5ZZ4c0CfDiZ3H8tquu7EjR1yKsgHNUMffz DZXkLgF1+Q2E2ZfgxAmHxGUPq0gJcmxs8muvf1HIRyUO281V8HQ2kePif0ypZRnd B0/FrIDlr7LkkcnD6OImKafQDiDkQ2O5oitS2ODEDO/8ytAmkEgZEMpbmxg7F7Rb Nre7l9TclUKNynXkbycSt6OfrJGLXq8hzLCSZikYgszVdtaVvFwWoXPKmQykZHKb GHXDxH6CAkKAfTl0usKBkfNX/IyX1Yrf2x7acfHPdjN8SsTfTk/1l5FzsJp/srag == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=ncu/y7 KudGNBmPnjPJyE69GboBTIYhbNARcE3eG2XYw=; b=J7cDKD3fWex5eSY29ULws4 ea7wrIXyru+hBeVFfnIZzT2vylLpyoQfUncUCIqTlWs2wYteXzJaKgXOtqvNutb8 RbI5bl/wNy9/5pb3M1Mj23+cUC+XKkgVFBZn60pp4y9NZJZvRos74SB3SPI1ZTqZ Rnzzm7qyxWpYbAOBMbMSB48tXukrwtOBE7dkmjk6MwgWgcxwdWWKsyRH0MT/SU+D CKlEXkb9oxbocd3E7CjSniDvnubaFRtySx9FfFWa8flbjCcrTGSh3iWz9+ZJHNef OgYhFaifKJNQmdr4jm0+qNskkZfjHqqNjm+Q/naSrcmgt8A/qdnoGE8XS9JV34Mw == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id A3304BAB71; Fri, 11 Aug 2017 21:01:06 -0400 (EDT) Message-Id: <1502499666.4112384.1070937152.65224E08@webmail.messagingengine.com> From: Bron Gondwana To: "Kurt Andersen (b)" Cc: dmarc@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150249966641123840" X-Mailer: MessagingEngine.com Webmail Interface - ajax-33d44821 References: <1502499049.4110221.1070935024.1071B9AE@webmail.messagingengine.com> In-Reply-To: Date: Sat, 12 Aug 2017 11:01:06 +1000 Archived-At: Subject: Re: [dmarc-ietf] ARC signing when *not* modifying the message... X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Aug 2017 01:01:09 -0000 This is a multi-part message in MIME format. --_----------=_150249966641123840 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Sat, 12 Aug 2017, at 10:54, Kurt Andersen (b) wrote: > On Fri, Aug 11, 2017 at 5:50 PM, Bron Gondwana > wrote:>> __ >> >> >> >> Again - why seal on ingress? It's bogus. >> >> * check authentication on ingress >> * add authentication on egress >> >> That's the pattern that means something and works. Otherwise your >> internal mechanisms are going to have to be either ARC aware anyway, >> or you'll have to fix up ARC anyway.>> > As long as your method of communicating the ingress auth check > survives the transit of your internal infrastructure (which A-R does > not necessarily do as a result of some brain-dead gateway > implementations), I agree. Sealing on ingress is one such way to > provide that communication from ingress point to egress point but is a > bit noisy to do so. The obvious thing to do here (something we do in our FastMail infrastructure) is to add X-orgname-*: headers as required, and strip them all on egress. If your infrastructure is that complex, it's definitely worth doing something with your own custom headers internally, and by namespacing them with a common prefix, it's easy to make sure they don't leak out. And yes - in that case I would be making our egress system check the X-FM- AR header to make sure it came in authenticated, and then do an ARC check of its own to see if the message got modified internally, strip X-FM-*, and then either add ARC if the message was modified internally, or just send it with its existing ARC if it was untouched. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_150249966641123840 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"

On Sat, 12 Aug 2017, at 10:54, Kurt Andersen (b) wrote:




Again - why seal on ingress?  It's bogus.

* check authentication on ingress
* add authentication on egress

That's the pattern that means something and works.  Otherwise your internal mechanisms are going to have to be either ARC aware anyway, or you'll have to fix up ARC anyway.

As long as your method of communicating the ingress auth check survives the transit of your internal infrastructure (which A-R does not necessarily do as a result of some brain-dead gateway implementations), I agree. Sealing on ingress is one such way to provide that communication from ingress point to egress point but is a bit noisy to do so.

The obvious thing to do here (something we do in our FastMail infrastructure) is to add X-orgname-*: headers as required, and strip them all on egress.  If your infrastructure is that complex, it's definitely worth doing something with your own custom headers internally, and by namespacing them with a common prefix, it's easy to make sure they don't leak out.

And yes - in that case I would be making our egress system check the X-FM-AR header to make sure it came in authenticated, and then do an ARC check of its own to see if the message got modified internally, strip X-FM-*, and then either add ARC if the message was modified internally, or just send it with its existing ARC if it was untouched.

Bron.


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


--_----------=_150249966641123840-- From nobody Sat Aug 12 16:22:17 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2518113237B for ; Sat, 12 Aug 2017 16:22:16 -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_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=isdg.net header.b=Nx4Y8iZm; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=kyNXPgeq Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WE1fM1KTy-D for ; Sat, 12 Aug 2017 16:22:14 -0700 (PDT) Received: from demo.winserver.com (secure.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 2D03E131CED for ; Sat, 12 Aug 2017 16:22:13 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=930; t=1502580126; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=PoxKymFPZo9nrRZ5ZfIXSOh7ZOA=; b=Nx4Y8iZm+HIE5pJz0Zl9tehEAHiRtCIfNpJ6WZCzNv+Zn/dbEIbvBAOrQBFJJl XR6Z47mNUq3lcmW2RsK42Yb23kXbh5Y8KDCKGGU8FPxbG9qCSV/KbE+QG6/lsbrw otmLj75reaWG147G8gkoshhGW/SXkcZxwLWE6+Rbr3Syw= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Sat, 12 Aug 2017 19:22:05 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 2643985028.1.3924; Sat, 12 Aug 2017 19:22:04 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=930; t=1502580093; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=KhC9ZPD AfZfBS9/RFNn/Q0ZFZmI1j5eJmn1/wC6qJO4=; b=kyNXPgeqUeekVVPzSCHJDxQ Yl/U42e8Y4u6p8GqqWhZh7G1HRJRHu3sgWAK4Ff9xYGIt+fHICaDDGyMbxQ+JhyO NRLmsgWE9NpvbRXrev72ZUmMa6CpypPg7PaOKXA6lXvubuCTpEbrDQ+gmZ4UZtWW IjvloLRDXa8qVnxHREIo= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Sat, 12 Aug 2017 19:21:33 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 3186489924.9.634444; Sat, 12 Aug 2017 19:21:31 -0400 Message-ID: <598F8DA1.8020700@isdg.net> Date: Sat, 12 Aug 2017 19:22:09 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: Dave Crocker , "Kurt Andersen (b)" CC: "dmarc@ietf.org" References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> <89f1a978-0cc6-f7f3-5d3d-0ccd67341369@gmail.com> <4a8d9564-ba0c-9c9b-7a23-ab6340fd2400@gmail.com> In-Reply-To: <4a8d9564-ba0c-9c9b-7a23-ab6340fd2400@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Aug 2017 23:22:16 -0000 On 8/11/2017 1:19 PM, Dave Crocker wrote: > On 8/11/2017 9:34 AM, Kurt Andersen (b) wrote: >> I think that we have that sort of information scattered around in >> various non-spec presentations that have happened regarding ARC. Do >> you consider this to be something that should be tackled before or >> after the "intent"-related notes in your earlier review notes from >> the end of July? > > > I think it's compatible with some of the concerns I raise and so > should be pursued at the same time. I'm hoping that the exercise will > produce much better clarity and coherence and widespread understanding > of what ARC will and will not do. > This is important if there is going to be an wider implementation here especially among the community of non-open source developers. This is where the expense will be and there is an expectation of having a document can developers can produce code from. -- HLS From nobody Sat Aug 12 16:51:36 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD75132439 for ; Sat, 12 Aug 2017 16:51:34 -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_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=isdg.net header.b=aGCiYmrn; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=MlPnYb97 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgzNWE0Y5U1H for ; Sat, 12 Aug 2017 16:51:33 -0700 (PDT) Received: from demo.winserver.com (secure.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id EB3E0132443 for ; Sat, 12 Aug 2017 16:51:32 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2424; t=1502581885; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=p0/5sDhrw6TWwYjeVhqzJg7VLs4=; b=aGCiYmrnpkAmfuk5iB8R2StHwU9WedcxUepTykkEzaihfavmrQO8/45TZjq2ks HGDlugk/lOKOSoV7pt5I7/ODl5c2D0+oZBgAx2Ji+iWgrKa4+ZM5fA6Tb17aig7V P7FMgKpF9OJgUFvcvtQpCILev7hWMgRTdi+l3cr8qLu3g= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Sat, 12 Aug 2017 19:51:25 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 2645745202.1.4180; Sat, 12 Aug 2017 19:51:24 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2424; t=1502581855; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=ESYGuP1 7nDSHOQgZlWShROwynA2aU9N+sCL3O9/C7A4=; b=MlPnYb97mMqG0VZz+kh26FF pU9z5ML7YhhprowkU/oObhPJhkSq2HN8Ae6hzOgtUVWr4GpXjBwU8fgqwKjlgx5/ sGyJEiPVcjJQKKXxZY848Fa+La4M1wC6qb5xcdP7Mr50rdIOuwxYJ4bibqBwcdHv iC6QgL9DnPxGKWfXJ/qs= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Sat, 12 Aug 2017 19:50:55 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 3188252815.9.638828; Sat, 12 Aug 2017 19:50:54 -0400 Message-ID: <598F9484.7020700@isdg.net> Date: Sat, 12 Aug 2017 19:51:32 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: Bron Gondwana , dmarc@ietf.org References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> <166070f0-4ba1-70da-1f73-885b4a7f7640@gmail.com> <1502497178.4103451.1070917304.23DD466D@webmail.messagingengine.com> In-Reply-To: <1502497178.4103451.1070917304.23DD466D@webmail.messagingengine.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Aug 2017 23:51:34 -0000 On 8/11/2017 8:19 PM, Bron Gondwana wrote: > On Sat, 12 Aug 2017, at 10:04, Dave Crocker wrote: >> by 'strategy DKIM uses' what do you mean exactly? I'm guessing you mean >> having the signature cover more of the header and all of the body, but >> please confirm or clarify. > > Sorry - yes, to clarify... > > DKIM signs the entire body plus parts of the header. > > In the strategy I am proposing, site "X" modifying a message in > transit (e.g. a mailing list) would add their own DKIM-like header > (ARC-Message-Signature is a perfectly fine name for it) which signed > the new "body and parts of the header", including a statement that > site "X" had verified the message authentication before modifying it > (ARC-Authentication-Results is a perfectly fine name for that statement). > > That gives a complete chain of custody. Its a great idea.... but it still suffers from the long time 3rd party signature registration problem. This is why we are here. All the DKIM policy models, including DMARC with a p=reject policy) suffered this issue. ARC is suppose to save 3rd party signed indirect messages. The "Arc-Authentication-Results" header can claim this but it still be phishing, forged mail -- no trust at the downlink receiver level and/or MUA client when DMARC p=reject rejection results are seen. What is needed is the Originating Domain making this claim that authorizes X as a legitimate modifier. We can either lookup that information (ATPS, https://tools.ietf.org/html/rfc6541) or we pass it as a new DKIM-signature. Levine had a DKIM Conditional proposal that does this. It wasn't a lookup concept, which I prefer, but Levine's idea was the next best option that touches base with a "3rd Party Authorization" concept: https://tools.ietf.org/html/draft-levine-dkim-conditional-02 Abstract This experimental specification proposes a modification to DomainKeys Identified Mail (DKIM) allowing advertisement of third-party signature authorizations that are to be interpreted as equivalent to a signature added by the administrative domain of the message's author. I'm not against ARC other than it seems like complex, overhead that doesn't address the main issue of authorized 3rd party routes. If we even have a DMARC ARC Policy concept, than that may be enough to begin pursuing the high cost of experimentation and development here. -- HLS From nobody Sun Aug 13 07:28:07 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36340131F21 for ; Sun, 13 Aug 2017 07:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjXXpXB7xXbk for ; Sun, 13 Aug 2017 07:28:04 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F3FB132424 for ; Sun, 13 Aug 2017 07:28:04 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id i66so25698316wmg.0 for ; Sun, 13 Aug 2017 07:28:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=W49vO47g5N9EY0Q5k7vdn3CZTkR9T/uXVvDEuGeeCzo=; b=Jf7/a0oYFdt5NJflEixU+f2TfZf5mLARLTv8wmj6SrvHUYby0eMEV2vuxEJb19pYjG uWuQXKwZCzgXW96uppN9fKlHoe0REfqcJFwa+eNRQnGV5/G62j9S1EcK7MCyJkVO/crL 3gjqErM238IOPMaNYiS7hLNMkBOvJ3om7GVOg= 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=W49vO47g5N9EY0Q5k7vdn3CZTkR9T/uXVvDEuGeeCzo=; b=FFzsx/JWvid0yb1g4cpMLbyPPwl8kHPAPbnRfoZDrwKz8hRrwgYfNIOHQup5nA++wA oh/Vy+9V10WwCrXrdhrc3+6UY2Tqy+QK8hcE7nQcgPO9edgE0DjQzO1lnKDEUKuAG97c 5hHUVkeyy4h4w3R5IMOvPAyNZhXE05+u9ENNhtNmDoGBQ7lWD/yvsAO5bTp7KleAnNE3 b4fPaPSBjoNuyzHWtj2+WLKP54wC0KtLeMlUHhhNMRv1MLrRelyQrjPfqDCMlVXgXH1v YIy0YFH2lwFVi+Z/QzQCOIMqC778WRtcuMWMHC2wCMpFIdpdtJge4CuYmJ+6foLOHKYf UwFQ== X-Gm-Message-State: AHYfb5j4lxHCuwRpYUIEe2mn197mpO0Y2e0qyRn1681qcyjhRsrjc9Jc LwZKoUiGUCSxnGoGgme87C9KGF0RfY8N9ik= X-Received: by 10.80.217.4 with SMTP id t4mr20713198edj.225.1502634482537; Sun, 13 Aug 2017 07:28:02 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.80.178.229 with HTTP; Sun, 13 Aug 2017 07:28:01 -0700 (PDT) In-Reply-To: <598F9484.7020700@isdg.net> References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> <166070f0-4ba1-70da-1f73-885b4a7f7640@gmail.com> <1502497178.4103451.1070917304.23DD466D@webmail.messagingengine.com> <598F9484.7020700@isdg.net> From: "Kurt Andersen (b)" Date: Sun, 13 Aug 2017 07:28:01 -0700 X-Google-Sender-Auth: 6kbo99iMaTH-ucDdk614Gy-DNNw Message-ID: To: Hector Santos Cc: Bron Gondwana , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="089e082235d88f2b380556a35a7e" Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Aug 2017 14:28:06 -0000 --089e082235d88f2b380556a35a7e Content-Type: text/plain; charset="UTF-8" On Sat, Aug 12, 2017 at 4:51 PM, Hector Santos wrote: > If we even have a DMARC ARC Policy concept, than that may be enough to > begin pursuing the high cost of experimentation and development here. > > Beyond the protocol and usage specs, what are you looking for? --Kurt --089e082235d88f2b380556a35a7e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= at, Aug 12, 2017 at 4:51 PM, Hector Santos <hsantos@isdg.net>= wrote:
=C2=A0 If we even have a DMARC AR= C Policy concept, than that may be enough to begin pursuing the high cost o= f experimentation and development here.

= Beyond the protocol and usage specs, what are you looking for?
--Kurt=C2=A0

--089e082235d88f2b380556a35a7e-- From nobody Sun Aug 13 11:41:46 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21A4513272B for ; Sun, 13 Aug 2017 11:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UajKa8Y23QPc for ; Sun, 13 Aug 2017 11:41:43 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::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 E53881326FA for ; Sun, 13 Aug 2017 11:41:42 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id d145so41762141qkc.2 for ; Sun, 13 Aug 2017 11:41:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6vN6M5jU9drriob77j3+DJdPZhp9px06AkmvKWFf7yY=; b=fqVAwefx07HqL6GQQL8eain6o5rVyGZvZICDBtz0KdM03zvWYiwfjpDrm6KFscuQid 38KbqO8ECwsPRVssgw0HZhm0CNNHQE0nN8/kUUmF83fbjIT2bmrDKYw7s+vbIrIz49yK g4AgihAumrueVLNSeBLyGdS01coO05aDzOjf3u24h5CqDRc6U96x4YqmSxQRT7Jz23sY mWHwNKHegkrBubgOEbitsiiaHqss/4IGQS2UJU5ljLmOZType2JxHAV9fV+CFwLBTChC tnwmq0myy8SCi9J/79EKXZU37Z5YRhz4XsBrH1G2H16HRVOJXzxa+b35c5uuURmCa43f 1RCw== 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=6vN6M5jU9drriob77j3+DJdPZhp9px06AkmvKWFf7yY=; b=PjaKUn9RA+I2U0Iq/JPZDpzY1UeWvQ7GsvGKgG4qyfz+qVzJnOGescWJhVch8I9yJz EfX9w/2XaaOto3gn45rBOUQz9xQApa40AN0Y5aKcQvmkPCdHm2WU2wCXMpghXs4pjgfL X7d1qMCDTK6xQOI8DPXrEVmZKK/Le814boNKZ/lORHbI9e9qNLdFVakEg4vHfDGmLgjn QsRiNRXmvgfwPjK7aQsgzMt5gbNZ1YJOtuq2ee1n5iw700SN/c5NEW9vniYgmd13QVrc TuqTxCKX65epzCBsJ8L20zVvMmjHWlpu8zCwD5TnqWNvCkoqbxQY1ZnlH/mXT1tHRQKV RZng== X-Gm-Message-State: AHYfb5hYYVnZHinEogO+yip5AnLFRiXJFWZw8O/FHleZ37W0e0M0mfAu Ko858cZYNILYHvFj76IcSm/535hdoQaP X-Received: by 10.55.118.71 with SMTP id r68mr23531657qkc.234.1502649702025; Sun, 13 Aug 2017 11:41:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.57.34 with HTTP; Sun, 13 Aug 2017 11:41:41 -0700 (PDT) In-Reply-To: <1501002028.380815.1052223552.1E89BD5D@webmail.messagingengine.com> References: <1501002028.380815.1052223552.1E89BD5D@webmail.messagingengine.com> From: "Murray S. Kucherawy" Date: Sun, 13 Aug 2017 11:41:41 -0700 Message-ID: To: Alexey Melnikov Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c05f7e6b613cd0556a6e5fe" Archived-At: Subject: Re: [dmarc-ietf] Review of draft-ietf-dmarc-arc-protocol-07 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Aug 2017 18:41:45 -0000 --94eb2c05f7e6b613cd0556a6e5fe Content-Type: text/plain; charset="UTF-8" On Tue, Jul 25, 2017 at 10:00 AM, Alexey Melnikov wrote: > I've noticed that you've posted draft-ietf-dmarc-arc-protocol-08, so > some of the issues identified below might no longer be relevant: > > 1) The new abstract doesn't even use the word "email". This needs to be > fixed, because otherwise it is not possible to determine that this is > related to email or DKIM from reading the abstract. > > The current abstract: > > The Authenticated Received Chain (ARC) protocol creates a mechanism > whereby a series of handlers of a message can conduct authentication > > suggestion to insert "email" before "message" above. > > of a message as it passes among them on the way to its destination, > and record the status of that authentication at each step along the > handling path, for use by the final recipient in making choices about > the disposition of the message. > I've always understood the term "message" to mean "email" at the IETF, given the titles of RFC5321, RFC5322, and what the "M" stands for in "SMTP", "LMTP", "IMAP", etc. 2) I liked "Primary Design Criteria" (section 2.1) from -06. Maybe add > it back as an Appendix? It is not important for new readers, but might > be of interest to more advanced readers. > It seemed like clutter to me, but an appendix is probably fine. > 6). In 9.5 (I think it is 9.6 in -08): should the document formally > register the "arc" Authentication-Results method in the IANA > Considerations? > Yes. -MSK --94eb2c05f7e6b613cd0556a6e5fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 25, 2017 at 10:00 AM, Alexey Melnikov <a= amelnikov@fastmail.fm> wrote:
<= div class=3D"gmail_quote">
I've noticed t= hat you've posted draft-ietf-dmarc-arc-protocol-08, so
some of the issues identified below might no longer be relevant:

1) The new abstract doesn't even use the word "email". This n= eeds to be
fixed, because otherwise it is not possible to determine that this is
related to email or DKIM from reading the abstract.

The current abstract:

=C2=A0 =C2=A0The Authenticated Received Chain (ARC) protocol creates a mech= anism
=C2=A0 =C2=A0whereby a series of handlers of a message can conduct authenti= cation

suggestion to insert "email" before "message" above.
=C2=A0 =C2=A0of a message as it passes among them on the way to its destina= tion,
=C2=A0 =C2=A0and record the status of that authentication at each step alon= g the
=C2=A0 =C2=A0handling path, for use by the final recipient in making choice= s about
=C2=A0 =C2=A0the disposition of the message.

I've always understood the term "message" to mean "= ;email" at the IETF, given the titles of RFC5321, RFC5322, and what th= e "M" stands for in "SMTP", "LMTP", "IMA= P", etc.

2) I liked "Primary Design Criteria" (section 2.1) from -06. Mayb= e add
it back as an Appendix? It is not important for new readers, but might
be of interest to more advanced readers.

It seemed like clutter to me, but an appendix is probably fine.
=C2=A0=
6). In 9.5 (I think it is 9.6 in -08): should the document formally
register the "arc" Authentication-Results method in the IANA
Considerations?

Yes.
=C2=A0
-MSK
--94eb2c05f7e6b613cd0556a6e5fe-- From nobody Mon Aug 14 12:42:39 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39E211323D4 for ; Mon, 14 Aug 2017 12:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fiction.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 zQPfpwhGSdJM for ; Mon, 14 Aug 2017 12:42:35 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::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 96E661323A6 for ; Mon, 14 Aug 2017 12:42:35 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id d29so40554408uai.2 for ; Mon, 14 Aug 2017 12:42:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fiction.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LW09ipMZfRTdsg4yCZAjJBYUd46yBLd5vzdkAC9AGcU=; b=bHJIBIHTloW1MXx512DZQqD9PA9oczDM9PN1GFhgKTna1ZsVlnTypyBoS6zMuYSIBB zVWP1nFCIF3+ay5rJGUVCenQvAwLF4JPyruqIzfCfOEfiZ3m/MpeqCMTeFiavkiiLqJv 3wVpcsY5zHGxQLc5gWdVr6Wr1ZIDxLZvrvDjgMp9XkTrSc18q2av5+VbtzqMFSX/PIeK zU98vHVEidfyD17sQXqtWY6qPx0gYf8itaigNGSTGEBNDcvvaUEJ1NGaBUmdmaDUEImz O4C/DF5eEPURa3L1PSfQ5NTo8BH71ZkACmRFp/FSkYlTlj4CoO5Sej8uyvULtGILH1vD eQVg== 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=LW09ipMZfRTdsg4yCZAjJBYUd46yBLd5vzdkAC9AGcU=; b=jIeg/oUSZT8Fug753OHPtkqvIyRQ32M+3opBYzMKtbB90gMtp6RYxtRmpprUMLYrjK MUd+gVKdDzceXqxcfQt1LugMjhRi5AJiGPLhn9t3hb41+dneejUvjJusJsKYOtvD3fLY hSEmrHuBlb5FvNDsUAclzAeH6enTRKt/4iB+yRw/V90qcSi9oHriy6fZHoVwcG+MkszY 5f6jLq3Da+vTljPNylXyePdoOaq5JnASdcNu+ad/t4AUwINjXhabdF30orCiKYevJcIG wWzsOg2hib7PNri8enkmLZmgzmXh8xF7Ub48qT9vgXgQrOx7BJ1ru3kMnLl/jlR5wNHu 7R5w== X-Gm-Message-State: AHYfb5hSQEPNKD7MBIYJ0Q63Yj/TdnKi/75psVcVdWBsEOVl2PW3t8bL Ulh/IQP1IIgJiiepWN5CtQ== X-Received: by 10.176.76.33 with SMTP id l33mr19007442uaf.4.1502739754602; Mon, 14 Aug 2017 12:42:34 -0700 (PDT) Received: from mail-ua0-f181.google.com (mail-ua0-f181.google.com. [209.85.217.181]) by smtp.gmail.com with ESMTPSA id d26sm2009877uaa.49.2017.08.14.12.42.33 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Aug 2017 12:42:33 -0700 (PDT) Received: by mail-ua0-f181.google.com with SMTP id y36so844080uac.5 for ; Mon, 14 Aug 2017 12:42:33 -0700 (PDT) X-Received: by 10.176.26.155 with SMTP id j27mr18445321uai.45.1502739752761; Mon, 14 Aug 2017 12:42:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.135.139 with HTTP; Mon, 14 Aug 2017 12:42:32 -0700 (PDT) In-Reply-To: <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> From: Brandon Long Date: Mon, 14 Aug 2017 12:42:32 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Bron Gondwana Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="f403045f280a27e5b20556bbdd81" Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre 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, 14 Aug 2017 19:42:38 -0000 --f403045f280a27e5b20556bbdd81 Content-Type: text/plain; charset="UTF-8" On Fri, Aug 11, 2017 at 4:54 PM, Bron Gondwana wrote: > On Sat, 12 Aug 2017, at 03:22, Dave Crocker wrote: > > I'm just picking out the key quote here: > > On 8/7/2017 4:22 PM, Seth Blank wrote: > > When validating an ARC signed message, one verifies the latest AMS > (which must validate), and *the entire chain* of ARC Seals, not only > the latest. This guarantees you a list of all message signatories - > the chain of custody we're talking about. > > > Yes, I follow this bit, but then... > > When evaluating the chain for final receipt, there are two states to > worry about as a matter of local policy: 1) you trust all the > signatories on the chain 2) there is an untrusted signatory on the > chain > > > Which is why it's a bad idea to sign if you're not modifying, because then > everybody has to trust you or their chain breaks, even though you didn't do > anything which required signing. > This is an interesting point. If there is a non-participating intermediary, either the message wasn't modified (so the next hop passes arc) or it was (and the next hop fails the whole chain). If you are participating, the fact that you didn't modify the message is lost when the message is modified down the chain. This is a clearly worse scenario for participation, due to the lack of information that is passed forward in the chain. We would need to include more information in the chain in order to overcome this, some information from hop N about which previous hop was the last modifying hop. [snip] > The critical thing about the ARC Seal is that it guarantees this > > behavior in state #1 - if you trust all the d= values in the ARC > Seals, they all validate, and you have cv=pass, then you know for > certain everyone who has manipulated the message (and maybe some who > handled but did not modify). > > > In state #1, you don't need a chain of ARC Seal. You just need each site > to sign their own AAR and each AAR to include "arc=pass" for the previous > AMS. You trust the sites, so you trust them to verify the ARC status on > ingress. > > So ARC Seal isn't adding anything other than complexity. I'm not saying > "ARC Seal doesn't work in case #1" - I'm saying "ARC Seal is security > theater in state #1". It's overly complex and adding no value. > If a message goes through two modifying hops, then there is no utility in the AMS/AAR from the first hop, because it no longer verifies. At that point, you only ever have the AMS/AAR from the last modifying hop, which is exactly what we had with XOAR (or at least the Google implementation). The Google implementation was basically X-Google-DKIM-Signature as the AMS and X-Original-Authentication-Results as the AAR. Theoretically, the second modifying hop could include information from the preceding AAR in it's AAR, and maybe that transitive trust (I trust hop 2, which trusts hop 1, so I have to trust hop 1) is ok, because by trusting hop 2, they could have completely replaced the message. This wasn't done with XOAR. There would be no point in including multiple AMS/AAR headers, why bother keeping the non-verifiable ones. Or maybe, you just get rid of the AMS and keep the AAR and have your AMS sign over all of the existing AAR records. Brandon --f403045f280a27e5b20556bbdd81 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Aug 11, 2017 at 4:54 PM, Bron Gondwana <brong@fastmailtea= m.com> wrote:
On Sat, 12 Aug 2017, at 03:22, Dave C= rocker wrote:

I'm just picking out the key quote her= e:

On 8/7/2017 4:22 PM, Seth Blank wrote:
When validating an ARC signed message, one verifies the la= test AMS
(which must validate), and *the entire chain* of ARC Seals, not only
the latest. This guarantees you a list of all message signatories -
the chain of custody we're talking about.

Yes, I follow this bit, but then...=

When evaluating the chain for fi= nal receipt, there are two states to
worry about as a matter of local policy: 1) you trust all the
signatories on the chain 2) there is an untrusted signatory on the
=
chain

Which is why it's a bad idea to= sign if you're not modifying, because then everybody has to trust you = or their chain breaks, even though you didn't do anything which require= d signing.

This is an inter= esting point.

If there is a non-participating inte= rmediary, either the message wasn't modified (so the next hop passes ar= c) or it was (and the next hop fails the whole chain).

If you= are participating, the fact that you didn't modify the message is lost= when the message is modified down the chain.

This= is a clearly worse scenario for participation, due to the lack of informat= ion that is passed forward in the chain.

We would = need to include more information in the chain in order to overcome this, so= me information from hop N about which previous hop was the last modifying h= op.
=C2=A0
[snip]
<= div>
The critical thing about the ARC= Seal is that it guarantees this
=
behavior in state #1 - if you trust all the d=3D values in the ARC
=
Seals, they all validate, and you have cv=3Dpass, then you know for
certain everyone who has manipulated the message (and maybe some who
handled but did not modify).

In state #1, you don't need a c= hain of ARC Seal.=C2=A0 You just need each site to sign their own AAR and e= ach AAR to include "arc=3Dpass" for the previous AMS.=C2=A0 You t= rust the sites, so you trust them to verify the ARC status on ingress.
<= /div>

So ARC Seal isn't adding anything othe= r than complexity.=C2=A0 I'm not saying "ARC Seal doesn't work= in case #1" - I'm saying "ARC Seal is security theater in st= ate #1".=C2=A0 It's overly complex and adding no value.

If a message goes through two modifying h= ops, then there is no utility in the AMS/AAR from the first hop, because it= no longer verifies.

At that point, you only ever = have the AMS/AAR from the last modifying hop, which is exactly what we had = with XOAR (or at least the Google implementation).

The Google implementation was basically X-Google-DKIM-Signature as the AMS= and X-Original-Authentication-Results as the AAR.

Theoretically, the second modifying hop could include information from the= preceding AAR in it's AAR, and maybe that transitive trust (I trust ho= p 2, which trusts hop 1, so I have to trust hop 1) is ok, because by trusti= ng hop 2, they could have completely replaced the message.=C2=A0 This wasn&= #39;t done with XOAR.

There would be no point in i= ncluding multiple AMS/AAR headers, why bother keeping the non-verifiable on= es.=C2=A0 Or maybe, you just get rid of the AMS and keep the AAR and have y= our AMS sign over all of the existing AAR records.

Brandon


--f403045f280a27e5b20556bbdd81-- From nobody Mon Aug 14 17:12:09 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7280513245F for ; Mon, 14 Aug 2017 17:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=SEXOQ0Hj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=oQI4g3gu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7_S4Thpr5gH for ; Mon, 14 Aug 2017 17:12:02 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BC7D13245E for ; Mon, 14 Aug 2017 17:12:02 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id A41F520783; Mon, 14 Aug 2017 20:12:01 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Mon, 14 Aug 2017 20:12:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=UuzTEg OQZ32UtkrBUhs2k50h69EJYeuN+WgG+m9JmGo=; b=SEXOQ0HjyZDqMykjN/Wubu Pu3YLLjjfv/WFMHScYooF1/R7WThUHVBHq5QDVHxH8tOnD1OGB8ThxRAwCrThbmF rcM+IF3lxi/Mginlp2eDrqmBqCSFXa3k9dsG96yYxiPjgNI2YJMZar3NZQmU7JRo Y0CTX1b4iqE2Ye+s1T17tmVLMBmSRzsbIChtQYrs2T5PWdxUMzrYQOY1v/lVyGEj IP0pGbIJ/7J5HorZ7nkgERvGDqc2GFdBLIdcA6ESxsy+odIoxqXGjYwotUM0HMpa Pu6fjWIqg6kzr0KtODiuW72afW+I9CUy4J7Z/Jmo1m+WkxSB44uDFdU0NwWD5IBQ == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=UuzTEg OQZ32UtkrBUhs2k50h69EJYeuN+WgG+m9JmGo=; b=oQI4g3guSEXTIQIBN/bftE p/kvx9Pk+lWMZzAZqVMxI/ngUeCLtQF6kGC64MEFn4TnN2Q0UUC46rt5sveUt2d4 Rt4mEgX2a+Zr2rEu/LwEJc55V1Ic4SMo8434eICUsaRSN2dSeIM2ZI4hlIh2Grt+ zD6sOlXl4Rk4YXrc7iOcPHuekRdpyglCyfYZQxWw4yFPxELkJ9L6mADb+s6smmhf 3bjY/8LaTqp8Jpco3FsbfeI6r/HwKjq2ETzc14L2iVWR493fM8WQbPdjS1q35Z8X HVhDS2x5mKBCo++KOQ6BMPGBTdzARrS7zL36VYJiAplJxOAe6d7Oq1te3a1FNpNQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 7D32D9E264; Mon, 14 Aug 2017 20:12:01 -0400 (EDT) Message-Id: <1502755921.1067004.1073467336.14612B87@webmail.messagingengine.com> From: Bron Gondwana To: Brandon Long Cc: dmarc@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150275592110670042" X-Mailer: MessagingEngine.com Webmail Interface - ajax-ff6d44b3 In-Reply-To: References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> Date: Tue, 15 Aug 2017 10:12:01 +1000 Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre 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 Aug 2017 00:12:05 -0000 This is a multi-part message in MIME format. --_----------=_150275592110670042 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Tue, 15 Aug 2017, at 05:42, Brandon Long wrote: > > > On Fri, Aug 11, 2017 at 4:54 PM, Bron Gondwana > wrote:>> __ >> On Sat, 12 Aug 2017, at 03:22, Dave Crocker wrote: >> >> I'm just picking out the key quote here: >> >> >>> On 8/7/2017 4:22 PM, Seth Blank wrote: >>>> When validating an ARC signed message, one verifies the latest AMS>>>> (which must validate), and *the entire chain* of ARC Seals, >>>> not only>>>> the latest. This guarantees you a list of all message signatories ->>>> the chain of custody we're talking about. >> >> >> Yes, I follow this bit, but then... >> >> >>>> When evaluating the chain for final receipt, there are two >>>> states to>>>> worry about as a matter of local policy: 1) you trust all the >>>> signatories on the chain 2) there is an untrusted signatory on the>>>> chain >> >> >> Which is why it's a bad idea to sign if you're not modifying, because >> then everybody has to trust you or their chain breaks, even though >> you didn't do anything which required signing.> > This is an interesting point. > > If there is a non-participating intermediary, either the message > wasn't modified (so the next hop passes arc) or it was (and the next > hop fails the whole chain).> > If you are participating, the fact that you didn't modify the message > is lost when the message is modified down the chain.> > This is a clearly worse scenario for participation, due to the lack of > information that is passed forward in the chain.> > We would need to include more information in the chain in order to > overcome this, some information from hop N about which previous hop > was the last modifying hop. That seems like it would be enough to fix that objection. An additional "first AMS failure" header at each hop would give you a list of who actually modified the message. > Theoretically, the second modifying hop could include information from > the preceding AAR in it's AAR, and maybe that transitive trust (I > trust hop 2, which trusts hop 1, so I have to trust hop 1) is ok, > because by trusting hop 2, they could have completely replaced the > message. This wasn't done with XOAR. Right. That's the bit that we do absolutely need, regardless of everything else. Every link in the chain has to be trustworthy or they can just repurpose an existing chain valid chain. If you didn't have that with XOAR I can see how an intermediate could have falsified the chain of custody under XOAR without being implicated for reputation purposes. We definitely need to be able to know who the injection point for bad content! > There would be no point in including multiple AMS/AAR headers, why > bother keeping the non-verifiable ones. Or maybe, you just get rid of > the AMS and keep the AAR and have your AMS sign over all of the > existing AAR records. Yes, that makes sense - So long as each AAR includes the signing domain that it checked against for its arc=pass, then no information is lost. I just had a really good chat with Seth on Skype half an hour ago about this. He was unable to find a case where having a full AS,AMS,AAR adds any provable value over just checking the most-recent AMS and having AAR signed. I do like your proposal of signing ALL the existing AARs, because they're the thing of value. Old AMS have no value, and old AS have no value either so long as you have a cv=pass on the current AS. So if we had this: AMS: i=4, h=[...]:arc-authentication-results:arc-authentication-results:arc-authentication-results:arc-authentication-results:[...]AAR: i=4, arc=pass, dkim=fail, spf=fail AAR: i=3, arc=pass, dkim=fail, spf=fail AAR: i=2, arc=pass, dkim=pass, spf=fail AAR: i=1, dkim=pass, spf=pass That would give you everything. The one downside is that every ARC layer added another item to the h= header in the AMS. One nice thing about AS is that you don't need the h=, because it's implied. But overall I'd say removing the other AMS headers and all the AS headers still leads to a smaller payload than adding one h=arc-authentication- results for each hop. Unless I'm missing something, this design is just as robust as the existing AS,AMS,AAR for tracking chain of custody back to the first untrusted site, and neither design is any good for knowing things for certain about the changes made before the first untrusted site. Of course - this design doesn't tell you which of the steps modified the message any more (my first point above). I do like the idea of tagging the message with data about which hops modified it... which is an argument for not stripping AMS while is still validates. You would wind up with something like: AMS: i=4, h=[...]:arc-authentication-results:arc-authentication-results:arc-authentication-results:arc-authentication-results:[...]AAR: i=4, arc3=pass, arc2=pass, dkim=fail, spf=fail AMS: i=3 h=[...]:arc-authentication-results:arc-authentication-results:arc-authentication-results:[...]AAR: i=3, arc2=pass, dkim=fail, spf=fail AMS: i=2 h=[...]:arc-authentication-results:arc-authentication-results:[...]AAR: i=2, arc1=pass, dkim=pass, spf=fail AAR: i=1, dkim=pass, spf=pass Which tells you that i=3 and i=4 didn't modify the message, because arc2 passed when i=4 validated it (proving that i=3 didn't modify it), and the AMS for i=2, i=3 and i=4 all pass now. If the next hop was to modify the message it would add: AAR: i=5, arc4=pass, arc3=pass, arc2=pass, dkim=fail, spf=fail then strip all the existing AMS and add its own: AMS: i=5, h=[...]:arc-authentication-results:arc-authentication-results:arc-authentication-results:arc-authentication-results:arc-authentication-results:[...] Which signed that it verified hops 3 and 4 as non-modifiers. Regards, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_150275592110670042 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Tue, 15 Aug 2017, at 05:42, Brandon Long wrote:


On Fri, Aug 11, 2017 at 4:54 PM, Bron Gondwana <brong@fastmailteam.com> wrote:

On Sat, 12 Aug 2017, at 03:22, Dave Crocker wrote:

I'm just picking out the key quote here:


On 8/7/2017 4:22 PM, Seth Blank wrote:
When validating an ARC signed message, one verifies the latest AMS
(which must validate), and *the entire chain* of ARC Seals, not only
the latest. This guarantees you a list of all message signatories -
the chain of custody we're talking about.


Yes, I follow this bit, but then...


When evaluating the chain for final receipt, there are two states to
worry about as a matter of local policy: 1) you trust all the
signatories on the chain 2) there is an untrusted signatory on the
chain


Which is why it's a bad idea to sign if you're not modifying, because then everybody has to trust you or their chain breaks, even though you didn't do anything which required signing.

This is an interesting point.

If there is a non-participating intermediary, either the message wasn't modified (so the next hop passes arc) or it was (and the next hop fails the whole chain).

If you are participating, the fact that you didn't modify the message is lost when the message is modified down the chain.

This is a clearly worse scenario for participation, due to the lack of information that is passed forward in the chain.

We would need to include more information in the chain in order to overcome this, some information from hop N about which previous hop was the last modifying hop. 

That seems like it would be enough to fix that objection.  An additional "first AMS failure" header at each hop would give you a list of who actually modified the message.

Theoretically, the second modifying hop could include information from the preceding AAR in it's AAR, and maybe that transitive trust (I trust hop 2, which trusts hop 1, so I have to trust hop 1) is ok, because by trusting hop 2, they could have completely replaced the message.  This wasn't done with XOAR.

Right.  That's the bit that we do absolutely need, regardless of everything else.  Every link in the chain has to be trustworthy or they can just repurpose an existing chain valid chain.  If you didn't have that with XOAR I can see how an intermediate could have falsified the chain of custody under XOAR without being implicated for reputation purposes.  We definitely need to be able to know who the injection point for bad content!

There would be no point in including multiple AMS/AAR headers, why bother keeping the non-verifiable ones.  Or maybe, you just get rid of the AMS and keep the AAR and have your AMS sign over all of the existing AAR records.

Yes, that makes sense - So long as each AAR includes the signing domain that it checked against for its arc=pass, then no information is lost.

I just had a really good chat with Seth on Skype half an hour ago about this.  He was unable to find a case where having a full AS,AMS,AAR adds any provable value over just checking the most-recent AMS and having AAR signed.  I do like your proposal of signing ALL the existing AARs, because they're the thing of value.  Old AMS have no value, and old AS have no value either so long as you have a cv=pass on the current AS.

So if we had this:

AMS: i=4, h=[...]:arc-authentication-results:arc-authentication-results:arc-authentication-results:arc-authentication-results:[...]
AAR: i=4, arc=pass, dkim=fail, spf=fail
AAR: i=3, arc=pass, dkim=fail, spf=fail
AAR: i=2, arc=pass, dkim=pass, spf=fail
AAR: i=1, dkim=pass, spf=pass

That would give you everything.  The one downside is that every ARC layer added another item to the h= header in the AMS.  One nice thing about AS is that you don't need the h=, because it's implied.

But overall I'd say removing the other AMS headers and all the AS headers still leads to a smaller payload than adding one h=arc-authentication-results for each hop.

Unless I'm missing something, this design is just as robust as the existing AS,AMS,AAR for tracking chain of custody back to the first untrusted site, and neither design is any good for knowing things for certain about the changes made before the first untrusted site.

Of course - this design doesn't tell you which of the steps modified the message any more (my first point above).  I do like the idea of tagging the message with data about which hops modified it... which is an argument for not stripping AMS while is still validates.  You would wind up with something like:

AMS: i=4, h=[...]:arc-authentication-results:arc-authentication-results:arc-authentication-results:arc-authentication-results:[...]
AAR: i=4, arc3=pass, arc2=pass, dkim=fail, spf=fail
AMS: i=3 h=[...]:arc-authentication-results:arc-authentication-results:arc-authentication-results:[...]
AAR: i=3, arc2=pass, dkim=fail, spf=fail
AMS: i=2 h=[...]:arc-authentication-results:arc-authentication-results:[...]
AAR: i=2, arc1=pass, dkim=pass, spf=fail
AAR: i=1, dkim=pass, spf=pass

Which tells you that i=3 and i=4 didn't modify the message, because arc2 passed when i=4 validated it (proving that i=3 didn't modify it), and the AMS for i=2, i=3 and i=4 all pass now.

If the next hop was to modify the message it would add:

AAR: i=5, arc4=pass, arc3=pass, arc2=pass, dkim=fail, spf=fail

then strip all the existing AMS and add its own:

AMS: i=5, h=[...]:arc-authentication-results:arc-authentication-results:arc-authentication-results:arc-authentication-results:arc-authentication-results:[...]

Which signed that it verified hops 3 and 4 as non-modifiers.

Regards,

Bron.


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


--_----------=_150275592110670042-- From nobody Mon Aug 14 17:47:13 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0369B132477 for ; Mon, 14 Aug 2017 17:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 0hhdgPMujdcm for ; Mon, 14 Aug 2017 17:47:09 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2BA0132476 for ; Mon, 14 Aug 2017 17:47:08 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id 80so42836745uas.0 for ; Mon, 14 Aug 2017 17:47:08 -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=AcpWTMIRHo7fx+RvWyXzr2mHgtSKFoqFH/PYhNrU3KA=; b=mxmX1SL18ySUI38YiCAn3gk6pgsQgGO8HHJ/y7JTS7LvfuFAKQgk4a6sXnAOmrDi5V kSsSK1Sn8I2N+yUoB3REItz99PZ+hP8dzdEurbKNp/EijL7ChtOiScseWtV4sS/2cXuK fAzcIXlJD/Nn8npZyC+kX0pS425WiShdJKti2LTcj+KFHcRgyaO4aHoioFr67Nvzpdi3 S4r2ZvDUNaIZVANYNejpBBncU6c+VwvAsAhKjFM5N8WUvJjUvv9fZEWvYAjMz+wAKoLK b6H+fHr6kMkLi777Zs6NfByhn16Gyhn8L3IYo6ZLj/MlNWffVu4XFkN53mYZZ5wRIpI0 PV/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=AcpWTMIRHo7fx+RvWyXzr2mHgtSKFoqFH/PYhNrU3KA=; b=BZuAwlK37QGzeeaz+HzCAfycksk9+520nL3KUCItQWggT/83JKBJTIL97O3JbWUPCy GueP/Vm+6mXceK3UuyVKEXFZeYKiBV5tcHkiRrSDwZmH0x1SNZP1xhhIqIaPprEZA/7K U+urkWUMV/A2xUw/IKiAp6M6rqGrxwbkxB/9x8MD20AlnHYDNfgtt2a+J2BVLWXEhzG/ GRbNO+A3wFsWYjyilr9lbGXUzxA4v+OIQgLyV4eYRAOywvq1ll3orQYVcrlpFegdHzr5 2UvrSWRJBSSoQ0SSFjiKEBD6Pg7bayj4LLa4jXPg8HsJtTK0uy9KIjgk2x6UYgo5IL9Z R3uA== X-Gm-Message-State: AHYfb5jxFGEWm5nmuxyjR7FlLsVhJtV64u3Y96O7oJ3Yq+vpq3FGMSH9 wP/Q+EN1+6KFBaYbXunWrcxFH/uePoQNtto= X-Received: by 10.176.87.138 with SMTP id x10mr18343479uaa.57.1502758027518; Mon, 14 Aug 2017 17:47:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.151.25 with HTTP; Mon, 14 Aug 2017 17:46:46 -0700 (PDT) In-Reply-To: <1502755921.1067004.1073467336.14612B87@webmail.messagingengine.com> References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> <1502755921.1067004.1073467336.14612B87@webmail.messagingengine.com> From: Seth Blank Date: Mon, 14 Aug 2017 17:46:46 -0700 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="f403045dd08e6a51a00556c01ebc" Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre 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 Aug 2017 00:47:12 -0000 --f403045dd08e6a51a00556c01ebc Content-Type: text/plain; charset="UTF-8" On Mon, Aug 14, 2017 at 5:12 PM, Bron Gondwana wrote: > > If there is a non-participating intermediary, either the message wasn't > modified (so the next hop passes arc) or it was (and the next hop fails the > whole chain). > > If you are participating, the fact that you didn't modify the message is > lost when the message is modified down the chain. > > This is a clearly worse scenario for participation, due to the lack of > information that is passed forward in the chain. > > We would need to include more information in the chain in order to > overcome this, some information from hop N about which previous hop was the > last modifying hop. > > > That seems like it would be enough to fix that objection. An additional > "first AMS failure" header at each hop would give you a list of who > actually modified the message. > This makes sense, and should be a simple addition to 5.1.1 regarding what/how to stamp. I'll noodle over this and suggest language. > > Theoretically, the second modifying hop could include information from the > preceding AAR in it's AAR, and maybe that transitive trust (I trust hop 2, > which trusts hop 1, so I have to trust hop 1) is ok, because by trusting > hop 2, they could have completely replaced the message. This wasn't done > with XOAR. > > > Right. That's the bit that we do absolutely need, regardless of > everything else. Every link in the chain has to be trustworthy or they can > just repurpose an existing chain valid chain. If you didn't have that with > XOAR I can see how an intermediate could have falsified the chain of > custody under XOAR without being implicated for reputation purposes. We > definitely need to be able to know who the injection point for bad content! > Do we, though? ARC has NOT ever been about localizing or understanding changes to a message, it has been about understanding *actors* who may have modified the message. For instance, if we have two ARC-participating hops, and it was a non-participating hop between them who modified the message, we could localize the breakage to being at or between the two hops, but could not with certainty ascribe it to either hop, which is why ARC has avoided this. > There would be no point in including multiple AMS/AAR headers, why bother > keeping the non-verifiable ones. Or maybe, you just get rid of the AMS and > keep the AAR and have your AMS sign over all of the existing AAR records. > > > Yes, that makes sense - So long as each AAR includes the signing domain > that it checked against for its arc=pass, then no information is lost. > So much of ARC keeps trace information that might be useful to someone at some point, it feels very weird to throw some headers out and keep others. I argue we keep them all, and (to the discussion around Experimental status) see what ends up being useful after this is in the wild for a bit. This data can always be tossed later if it serves no real world purpose. > I just had a really good chat with Seth on Skype half an hour ago about > this. He was unable to find a case where having a full AS,AMS,AAR adds any > provable value over just checking the most-recent AMS and having AAR > signed. I do like your proposal of signing ALL the existing AARs, because > they're the thing of value. Old AMS have no value, and old AS have no > value either so long as you have a cv=pass on the current AS. > That's not quite what I said ;-) If you throw old AMSs out, you cannot validate current ASs or walk the chain back. > So if we had this: > > AMS: i=4, h=[...]:arc-authentication-results:arc-authentication- > results:arc-authentication-results:arc-authentication-results:[...] > AAR: i=4, arc=pass, dkim=fail, spf=fail > AAR: i=3, arc=pass, dkim=fail, spf=fail > AAR: i=2, arc=pass, dkim=pass, spf=fail > AAR: i=1, dkim=pass, spf=pass > > That would give you everything. The one downside is that every ARC layer > added another item to the h= header in the AMS. One nice thing about AS is > that you don't need the h=, because it's implied. > All these items already get added to the h=. > > But overall I'd say removing the other AMS headers and all the AS headers > still leads to a smaller payload than adding one > h=arc-authentication-results for each hop. > We can't remove old AMS and AS headers for the reasons listed above (mainly, a) we're saving trace information to see what's beneficial downstream, and b) you can't validate the latest AS or walk the chain back if you throw out old headers). > Unless I'm missing something, this design is just as robust as the > existing AS,AMS,AAR for tracking chain of custody back to the first > untrusted site, and neither design is any good for knowing things for > certain about the changes made before the first untrusted site. > > Of course - this design doesn't tell you which of the steps modified the > message any more (my first point above). I do like the idea of tagging the > message with data about which hops modified it... which is an argument for > not stripping AMS while is still validates. You would wind up with > something like: > > AMS: i=4, h=[...]:arc-authentication-results:arc-authentication- > results:arc-authentication-results:arc-authentication-results:[...] > AAR: i=4, arc3=pass, arc2=pass, dkim=fail, spf=fail > AMS: i=3 h=[...]:arc-authentication-results:arc-authentication- > results:arc-authentication-results:[...] > AAR: i=3, arc2=pass, dkim=fail, spf=fail > AMS: i=2 h=[...]:arc-authentication-results:arc-authentication- > results:[...] > AAR: i=2, arc1=pass, dkim=pass, spf=fail > AAR: i=1, dkim=pass, spf=pass > > Which tells you that i=3 and i=4 didn't modify the message, because arc2 > passed when i=4 validated it (proving that i=3 didn't modify it), and the > AMS for i=2, i=3 and i=4 all pass now. > > If the next hop was to modify the message it would add: > > AAR: i=5, arc4=pass, arc3=pass, arc2=pass, dkim=fail, spf=fail > > then strip all the existing AMS and add its own: > > AMS: i=5, h=[...]:arc-authentication-results:arc-authentication- > results:arc-authentication-results:arc-authentication- > results:arc-authentication-results:[...] > > Which signed that it verified hops 3 and 4 as non-modifiers. > I'll suggest language for stamping "first AMS failure", but we shouldn't strip old AMS/AS headers. Seth > > Regards, > > Bron. > > > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --f403045dd08e6a51a00556c01ebc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Aug 14, 2017 at 5:12 PM, Bron Gondwana <brong@fastmailteam.com> wrote:
If there is a non-participating intermediary, either the message wasn&= #39;t modified (so the next hop passes arc) or it was (and the next hop fai= ls the whole chain).

If you are participating, the fact that yo= u didn't modify the message is lost when the message is modified down t= he chain.

This is a clearly worse scenario for participation, due to the lack of= information that is passed forward in the chain.

We would need to include more information in the chain in order to ove= rcome this, some information from hop N about which previous hop was the la= st modifying hop.=C2=A0

That seems like it would be enough = to fix that objection.=C2=A0 An additional "first AMS failure" he= ader at each hop would give you a list of who actually modified the message= .



=C2=A0
There would be no= point in including multiple AMS/AAR headers, why bother keeping the non-ve= rifiable ones.=C2=A0 Or maybe, you just get rid of the AMS and keep the AAR= and have your AMS sign over all of the existing AAR records.

Yes, that makes sense - So long as = each AAR includes the signing domain that it checked against for its arc=3D= pass, then no information is lost.

So much of ARC keeps trace information that might be useful to some= one at some point, it feels very weird to throw some headers out and keep o= thers. I argue we keep them all, and (to the discussion around Experimental= status) see what ends up being useful after this is in the wild for a bit.= This data can always be tossed later if it serves no real world purpose.

=C2=A0
I just had a really good chat with Seth on= Skype half an hour ago about this.=C2=A0 He was unable to find a case wher= e having a full=C2=A0AS,AMS,AAR adds any provable value over just checking = the most-recent AMS and having AAR signed.=C2=A0 I do like your proposal of= signing ALL the existing AARs, because they're the thing of value.=C2= =A0 Old AMS have no value, and old AS have no value either so long as you h= ave a cv=3Dpass on the current AS.

That's not quite what I said ;-)

If yo= u throw old AMSs out, you cannot validate current ASs or walk the chain bac= k.
=C2=A0
So if we had this:

AMS: i=3D4, h=3D[...]:arc-authentication-<= wbr>results:arc-authentication-results:arc-authentication-results= :arc-authentication-results:[...]
AAR: i=3D4, arc=3Dpass, dkim=3Dfail, spf= =3Dfail
AAR: i=3D3, arc=3Dpass, dkim=3Dfail, spf= =3Dfail
AAR: i=3D2, arc=3Dpass, dkim=3Dpass, spf= =3Dfail
AAR: i=3D1, dkim=3Dpass, spf=3Dpass

That would give you everything.=C2=A0 The = one downside is that every ARC layer added another item to the h=3D header = in the AMS.=C2=A0 One nice thing about AS is that you don't need the h= =3D, because it's implied.

<= div>All these items already get added to the h=3D.
=C2=A0

But overall I'd say removing the other= AMS headers and all the AS headers still leads to a smaller payload than a= dding one h=3Darc-authentication-results for each hop.

We can't remove old AMS and AS headers for = the reasons listed above (mainly, a) we're saving trace information to = see what's beneficial downstream, and b) you can't validate the lat= est AS or walk the chain back if you throw out old headers).
=C2= =A0
Unless I'm missing something, this des= ign is just as robust as the existing AS,AMS,AAR for tracking chain of cust= ody back to the first untrusted site, and neither design is any good for kn= owing things for certain about the changes made before the first untrusted = site.

Of course - this design doesn't tell y= ou which of the steps modified the message any more (my first point above).= =C2=A0 I do like the idea of tagging the message with data about which hops= modified it... which is an argument for not stripping AMS while is still v= alidates.=C2=A0 You would wind up with something like:

AMS: i=3D4, h=3D[...]:arc-authentication-<= wbr>results:arc-authentication-results:arc-authentication-results= :arc-authentication-results:[...]
AAR: i=3D4, arc3=3Dpass, arc2=3Dpass, dkim= =3Dfail, spf=3Dfail
AMS: i=3D3 h=3D[...]:arc-authentication-results:arc-authentication-results:arc-authentication-results:= [...]
AAR: i=3D3, arc2=3Dpass, dkim=3Dfail, spf= =3Dfail
AMS: i=3D2 h=3D[...]:arc-authentication-results:arc-authentication-results:[...]
AAR: i=3D2, arc1=3Dpass, dkim=3Dpass, spf= =3Dfail
AAR: i=3D1, dkim=3Dpass, spf=3Dpass

Which tells you that i=3D3 and i=3D4 didn&= #39;t modify the message, because arc2 passed when i=3D4 validated it (prov= ing that i=3D3 didn't modify it), and the AMS for i=3D2, i=3D3 and i=3D= 4 all pass now.

If the next hop was to modify the message = it would add:

AAR: i=3D5, arc4=3Dpass, arc3=3Dpass, arc2= =3Dpass, dkim=3Dfail, spf=3Dfail

then strip all the existing AMS and add it= s own:

AMS: i=3D5, h=3D[...]:arc-authentication-<= wbr>results:arc-authentication-results:arc-authentication-results= :arc-authentication-results:arc-authentication-results:[...]
<= /div>

Which signed that it verified hops 3 and 4= as non-modifiers.

I'll= suggest language for stamping "first AMS failure", but we should= n't strip old AMS/AS headers.

Seth
= =C2=A0

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


--f403045dd08e6a51a00556c01ebc-- From nobody Mon Aug 14 18:31:53 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B562D1321B6 for ; Mon, 14 Aug 2017 18:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=YDSuSa5n; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hJ89O8Xc Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3YlfYdAEoO6 for ; Mon, 14 Aug 2017 18:31:46 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF0B013247D for ; Mon, 14 Aug 2017 18:31:38 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 095C220925 for ; Mon, 14 Aug 2017 21:31:38 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Mon, 14 Aug 2017 21:31:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=QOdygMG+pwUf1+shx rLAAjNNzI6xZrRV9bilwL1P12k=; b=YDSuSa5nNvRDhAQI9LXAkX9o9HtIuQNlk +XFqSjne1Qs6gEQ3iEcWIhy4FeRLFPfSE81EZqgZ1lcMCCHAkP1zGC92AFodEYyV yqD8IpnxsFMpAqoOUh2+1cZ63XEz4SQ3+a8dT1d3EDVlc/c7BhciWjqkChi20/2g wmpCjVBq80ayUA3jWohfn6kUIeLuhknE4l16Qfxtcdz7ap+77pT/vZcdkg8rSc8p 1U2oy4OZaSpkQo2AQ0fZyV/UqiJqyUq5uDsW0f+1e0pC1EfsnqMbkMd8ZtdSBGsl QWe4vKxPW9xkClExb1rvfUsoPypB/mlTZeE8AQwGV9XVlQsFVqYPQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=QOdygM G+pwUf1+shxrLAAjNNzI6xZrRV9bilwL1P12k=; b=hJ89O8Xc4QPeBcwmecDsy5 zBa/PiqCmLIveaPVVUXFco4Aw3L+o7AhwQgbLBIupdACQUh0FJ0IaH7cldaiccFu sCrwAob60uL4huAAKTVyRSLHxmj8jByLllDAsjjFrETcyU0myEKZD8DqfAE8luBR FdO/qTDqVP1gnHtEzs2rJjEdaz8SiYuNMKecKXFRzHO+4EM/fFvJjSMz6sQKhJq3 SWEvCrDWa1BEbkwGw9ZY5LJZPm8nXJ8kvDsYYsVYR7Lk5c+qjOMB+L3OOnGpGMpK J3ManlsPhdjlt5iandNPhPpWAhCjgw7Gj63PP8zq+jiaoVd6GxLTq7d58cL05PKg == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id D01D79E264; Mon, 14 Aug 2017 21:31:37 -0400 (EDT) Message-Id: <1502760697.1080249.1073516280.7B4109C1@webmail.messagingengine.com> From: Bron Gondwana To: dmarc@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150276069710802494" X-Mailer: MessagingEngine.com Webmail Interface - ajax-ff6d44b3 In-Reply-To: References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> <1502755921.1067004.1073467336.14612B87@webmail.messagingengine.com> Date: Tue, 15 Aug 2017 11:31:37 +1000 Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre 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 Aug 2017 01:31:50 -0000 This is a multi-part message in MIME format. --_----------=_150276069710802494 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Tue, 15 Aug 2017, at 10:46, Seth Blank wrote: > On Mon, Aug 14, 2017 at 5:12 PM, Bron Gondwana > wrote:>> >>> If there is a non-participating intermediary, either the message >>> wasn't modified (so the next hop passes arc) or it was (and the next >>> hop fails the whole chain).>>> >>> If you are participating, the fact that you didn't modify the >>> message is lost when the message is modified down the chain.>>> >>> This is a clearly worse scenario for participation, due to the lack >>> of information that is passed forward in the chain.>>> >>> We would need to include more information in the chain in order to >>> overcome this, some information from hop N about which previous hop >>> was the last modifying hop.>> >> >> That seems like it would be enough to fix that objection. An >> additional "first AMS failure" header at each hop would give you a >> list of who actually modified the message.> > This makes sense, and should be a simple addition to 5.1.1 regarding > what/how to stamp. I'll noodle over this and suggest language. Excellent, thanks. > >> >>> Theoretically, the second modifying hop could include information >>> from the preceding AAR in it's AAR, and maybe that transitive trust >>> (I trust hop 2, which trusts hop 1, so I have to trust hop 1) is ok, >>> because by trusting hop 2, they could have completely replaced the >>> message. This wasn't done with XOAR.>> >> >> Right. That's the bit that we do absolutely need, regardless of >> everything else. Every link in the chain has to be trustworthy or >> they can just repurpose an existing chain valid chain. If you didn't >> have that with XOAR I can see how an intermediate could have >> falsified the chain of custody under XOAR without being implicated >> for reputation purposes. We definitely need to be able to know who >> the injection point for bad content!> > Do we, though? ARC has NOT ever been about localizing or understanding > changes to a message, it has been about understanding *actors* who may > have modified the message. Sure, but knowing which actors may have modified the message and which actors definitely didn't modify the message is super useful. It means that if you trust the next hop, you don't need to trust the intermediates that couldn't modified the message without colluding with that next hop. > > For instance, if we have two ARC-participating hops, and it was a non- > participating hop between them who modified the message, we could > localize the breakage to being at or between the two hops, but could > not with certainty ascribe it to either hop, which is why ARC has > avoided this. If you trust hop 2, you can confirm that it was modified since hop 1 (or that hop 1 can't form a valid signature). If you don't trust hop 2, then you don't know anything at all about the message before hop 2, regardless of any signatures. If that isn't clear, then I didn't explain myself very well on our call! Unless you trust hop 2, everything before that is meaningless, regardless of ARC headers. An ARC chain through an untrusted hop 2 could be totally fiction. >> >>> There would be no point in including multiple AMS/AAR headers, why >>> bother keeping the non-verifiable ones. Or maybe, you just get rid >>> of the AMS and keep the AAR and have your AMS sign over all of the >>> existing AAR records.>> >> >> Yes, that makes sense - So long as each AAR includes the signing >> domain that it checked against for its arc=pass, then no information >> is lost.> > So much of ARC keeps trace information that might be useful to someone > at some point, it feels very weird to throw some headers out and keep > others. I argue we keep them all, and (to the discussion around > Experimental status) see what ends up being useful after this is in > the wild for a bit. This data can always be tossed later if it serves > no real world purpose. "might be useful to someone at some point" - that kind of wooliness is a crock, sorry. Once crypto doesn't validate it has no meaning if all the data is present elsewhere - and everything that an AMS claims except for the crypto over the message is duplicated in the next hop's AAR. If that's not the case, we should fix it so that it is. "see what ends up being useful after this is in the wild for a bit" makes sense for informational records. It doesn't make sense for cryptographic data. Either the crypto is sound and it means something, or it's actively misleading. A no-longer-validating AMS contains nothing that the next hop's AAR doesn't contain. > >> I just had a really good chat with Seth on Skype half an hour ago >> about this. He was unable to find a case where having a full >> AS,AMS,AAR adds any provable value over just checking the most-recent >> AMS and having AAR signed. I do like your proposal of signing ALL >> the existing AARs, because they're the thing of value. Old AMS have >> no value, and old AS have no value either so long as you have a >> cv=pass on the current AS.> > That's not quite what I said ;-) OK, did I misunderstand? You couldn't quote a case where AS,AMS,AAR adds provable value over an AMS that signs the most recent AAR. If you can find that case, I will eat all my words, because I've spent a lot of time thinking through the cases. I agree with what Brandon seemed to be saying above - that it should be all the AAR being signed, not just the top one. Otherwise an intermediate could strip or modify earlier AAR without breaking the authentication, and that would be bad. Each AAR contains real, valuable, meaningful data. As far as I see, we're quibbling over how much cryptographic infrastructure is needed to maintain the integrity of the chain of AAR headers. > If you throw old AMSs out, you cannot validate current ASs or walk the > chain back. So what. AS is bunk. A current AMS over all AAR gives the same auditability, since AAR is the only thing that has meaning. AMS only has meaning while it still validates, and AS only has meaning because it ties AMS and AAR together. Those meanings don't add value. None of them mean jack once you've been through an untrusted site, all previous headers are suspect regardless of whether they have crypto that still validates, unless that crypto covers facts about the message which we actually care about. >> So if we had this: >> >> AMS: i=4, h=[...]:arc-authentication-results:arc-authentication-results:arc- >> authentication-results:arc-authentication-results:[...]>> AAR: i=4, arc=pass, dkim=fail, spf=fail >> AAR: i=3, arc=pass, dkim=fail, spf=fail >> AAR: i=2, arc=pass, dkim=pass, spf=fail >> AAR: i=1, dkim=pass, spf=pass >> >> That would give you everything. The one downside is that every ARC >> layer added another item to the h= header in the AMS. One nice thing >> about AS is that you don't need the h=, because it's implied.> > All these items already get added to the h=. > Of AS in the current draft, yes. If we added AAR to AMS and kept AMS as a DKIM signature structure, then we would want the h= key to contain the full list of headers. >> >> >> But overall I'd say removing the other AMS headers and all the AS >> headers still leads to a smaller payload than adding one h=arc-authentication- >> results for each hop.> > We can't remove old AMS and AS headers for the reasons listed above > (mainly, a) we're saving trace information to see what's beneficial > downstream, and b) you can't validate the latest AS or walk the chain > back if you throw out old headers). Forget AS when reading my examples here, because I was assuming no AS. >> Unless I'm missing something, this design is just as robust as the >> existing AS,AMS,AAR for tracking chain of custody back to the first >> untrusted site, and neither design is any good for knowing things for >> certain about the changes made before the first untrusted site.>> >> Of course - this design doesn't tell you which of the steps modified >> the message any more (my first point above). I do like the idea of >> tagging the message with data about which hops modified it... which >> is an argument for not stripping AMS while is still validates. You >> would wind up with something like:>> >> AMS: i=4, h=[...]:arc-authentication-results:arc-authentication-results:arc- >> authentication-results:arc-authentication-results:[...]>> AAR: i=4, arc3=pass, arc2=pass, dkim=fail, spf=fail >> AMS: i=3 h=[...]:arc-authentication-results:arc-authentication-results:arc- >> authentication-results:[...]>> AAR: i=3, arc2=pass, dkim=fail, spf=fail >> AMS: i=2 h=[...]:arc-authentication-results:arc-authentication- >> results:[...]>> AAR: i=2, arc1=pass, dkim=pass, spf=fail >> AAR: i=1, dkim=pass, spf=pass >> >> Which tells you that i=3 and i=4 didn't modify the message, because >> arc2 passed when i=4 validated it (proving that i=3 didn't modify >> it), and the AMS for i=2, i=3 and i=4 all pass now.>> >> If the next hop was to modify the message it would add: >> >> AAR: i=5, arc4=pass, arc3=pass, arc2=pass, dkim=fail, spf=fail >> >> then strip all the existing AMS and add its own: >> >> AMS: i=5, h=[...]:arc-authentication-results:arc-authentication-results:arc- >> authentication-results:arc-authentication-results:arc-authentication- >> results:[...]>> >> Which signed that it verified hops 3 and 4 as non-modifiers. > > I'll suggest language for stamping "first AMS failure", but we > shouldn't strip old AMS/AS headers. This is where we disagree. We shouldn't create AS headers in the first place. We should have AMS sign all the AAR and that's it. No AS, no need to retain broken AMS. It gets you all the same machine readable chain of custody as AS+AMS+AAR in the unbroken case, and it breaks at the same place with the same detectability in the fraudulent-actor case. There are no other cases. There's no middle here. Please do prove me wrong if you can think of another case, I really can't. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_150276069710802494 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Tue, 15 Aug 2017, at 10:46, Seth Blank wrote:
On Mon, Aug 14, 2017 at 5:12 PM, Bron Gondwana <brong@fastmailteam.com> wrote:

If there is a non-participating intermediary, either the message wasn't modified (so the next hop passes arc) or it was (and the next hop fails the whole chain).

If you are participating, the fact that you didn't modify the message is lost when the message is modified down the chain.

This is a clearly worse scenario for participation, due to the lack of information that is passed forward in the chain.

We would need to include more information in the chain in order to overcome this, some information from hop N about which previous hop was the last modifying hop. 


That seems like it would be enough to fix that objection.  An additional "first AMS failure" header at each hop would give you a list of who actually modified the message.

This makes sense, and should be a simple addition to 5.1.1 regarding what/how to stamp. I'll noodle over this and suggest language.

Excellent, thanks.

 

Theoretically, the second modifying hop could include information from the preceding AAR in it's AAR, and maybe that transitive trust (I trust hop 2, which trusts hop 1, so I have to trust hop 1) is ok, because by trusting hop 2, they could have completely replaced the message.  This wasn't done with XOAR.


Right.  That's the bit that we do absolutely need, regardless of everything else.  Every link in the chain has to be trustworthy or they can just repurpose an existing chain valid chain.  If you didn't have that with XOAR I can see how an intermediate could have falsified the chain of custody under XOAR without being implicated for reputation purposes.  We definitely need to be able to know who the injection point for bad content!

Do we, though? ARC has NOT ever been about localizing or understanding changes to a message, it has been about understanding *actors* who may have modified the message.

Sure, but knowing which actors may have modified the message and which actors definitely didn't modify the message is super useful.

It means that if you trust the next hop, you don't need to trust the intermediates that couldn't modified the message without colluding with that next hop.


For instance, if we have two ARC-participating hops, and it was a non-participating hop between them who modified the message, we could localize the breakage to being at or between the two hops, but could not with certainty ascribe it to either hop, which is why ARC has avoided this. 

If you trust hop 2, you can confirm that it was modified since hop 1 (or that hop 1 can't form a valid signature).

If you don't trust hop 2, then you don't know anything at all about the message before hop 2, regardless of any signatures.

If that isn't clear, then I didn't explain myself very well on our call!  Unless you trust hop 2, everything before that is meaningless, regardless of ARC headers.  An ARC chain through an untrusted hop 2 could be totally fiction.


There would be no point in including multiple AMS/AAR headers, why bother keeping the non-verifiable ones.  Or maybe, you just get rid of the AMS and keep the AAR and have your AMS sign over all of the existing AAR records.


Yes, that makes sense - So long as each AAR includes the signing domain that it checked against for its arc=pass, then no information is lost.

So much of ARC keeps trace information that might be useful to someone at some point, it feels very weird to throw some headers out and keep others. I argue we keep them all, and (to the discussion around Experimental status) see what ends up being useful after this is in the wild for a bit. This data can always be tossed later if it serves no real world purpose.

"might be useful to someone at some point" - that kind of wooliness is a crock, sorry.  Once crypto doesn't validate it has no meaning if all the data is present elsewhere - and everything that an AMS claims except for the crypto over the message is duplicated in the next hop's AAR.

If that's not the case, we should fix it so that it is.

"see what ends up being useful after this is in the wild for a bit" makes sense for informational records.  It doesn't make sense for cryptographic data.  Either the crypto is sound and it means something, or it's actively misleading.  A no-longer-validating AMS contains nothing that the next hop's AAR doesn't contain.

 
I just had a really good chat with Seth on Skype half an hour ago about this.  He was unable to find a case where having a full AS,AMS,AAR adds any provable value over just checking the most-recent AMS and having AAR signed.  I do like your proposal of signing ALL the existing AARs, because they're the thing of value.  Old AMS have no value, and old AS have no value either so long as you have a cv=pass on the current AS.

That's not quite what I said ;-)

OK, did I misunderstand?

You couldn't quote a case where AS,AMS,AAR adds provable value over an AMS that signs the most recent AAR.  If you can find that case, I will eat all my words, because I've spent a lot of time thinking through the cases.

I agree with what Brandon seemed to be saying above - that it should be all the AAR being signed, not just the top one.  Otherwise an intermediate could strip or modify earlier AAR without breaking the authentication, and that would be bad.  Each AAR contains real, valuable, meaningful data.

As far as I see, we're quibbling over how much cryptographic infrastructure is needed to maintain the integrity of the chain of AAR headers.

If you throw old AMSs out, you cannot validate current ASs or walk the chain back. 

So what.  AS is bunk.

A current AMS over all AAR gives the same auditability, since AAR is the only thing that has meaning.  AMS only has meaning while it still validates, and AS only has meaning because it ties AMS and AAR together.  Those meanings don't add value.  None of them mean jack once you've been through an untrusted site, all previous headers are suspect regardless of whether they have crypto that still validates, unless that crypto covers facts about the message which we actually care about.

So if we had this:

AMS: i=4, h=[...]:arc-authentication-results:arc-authentication-results:arc-authentication-results:arc-authentication-results:[...]
AAR: i=4, arc=pass, dkim=fail, spf=fail
AAR: i=3, arc=pass, dkim=fail, spf=fail
AAR: i=2, arc=pass, dkim=pass, spf=fail
AAR: i=1, dkim=pass, spf=pass

That would give you everything.  The one downside is that every ARC layer added another item to the h= header in the AMS.  One nice thing about AS is that you don't need the h=, because it's implied.

All these items already get added to the h=.
 

Of AS in the current draft, yes.  If we added AAR to AMS and kept AMS as a DKIM signature structure, then we would want the h= key to contain the full list of headers.



But overall I'd say removing the other AMS headers and all the AS headers still leads to a smaller payload than adding one h=arc-authentication-results for each hop.

We can't remove old AMS and AS headers for the reasons listed above (mainly, a) we're saving trace information to see what's beneficial downstream, and b) you can't validate the latest AS or walk the chain back if you throw out old headers).

Forget AS when reading my examples here, because I was assuming no AS.

Unless I'm missing something, this design is just as robust as the existing AS,AMS,AAR for tracking chain of custody back to the first untrusted site, and neither design is any good for knowing things for certain about the changes made before the first untrusted site.

Of course - this design doesn't tell you which of the steps modified the message any more (my first point above).  I do like the idea of tagging the message with data about which hops modified it... which is an argument for not stripping AMS while is still validates.  You would wind up with something like:

AMS: i=4, h=[...]:arc-authentication-results:arc-authentication-results:arc-authentication-results:arc-authentication-results:[...]
AAR: i=4, arc3=pass, arc2=pass, dkim=fail, spf=fail
AMS: i=3 h=[...]:arc-authentication-results:arc-authentication-results:arc-authentication-results:[...]
AAR: i=3, arc2=pass, dkim=fail, spf=fail
AMS: i=2 h=[...]:arc-authentication-results:arc-authentication-results:[...]
AAR: i=2, arc1=pass, dkim=pass, spf=fail
AAR: i=1, dkim=pass, spf=pass

Which tells you that i=3 and i=4 didn't modify the message, because arc2 passed when i=4 validated it (proving that i=3 didn't modify it), and the AMS for i=2, i=3 and i=4 all pass now.

If the next hop was to modify the message it would add:

AAR: i=5, arc4=pass, arc3=pass, arc2=pass, dkim=fail, spf=fail

then strip all the existing AMS and add its own:

AMS: i=5, h=[...]:arc-authentication-results:arc-authentication-results:arc-authentication-results:arc-authentication-results:arc-authentication-results:[...]

Which signed that it verified hops 3 and 4 as non-modifiers.

I'll suggest language for stamping "first AMS failure", but we shouldn't strip old AMS/AS headers.

This is where we disagree.  We shouldn't create AS headers in the first place.

We should have AMS sign all the AAR and that's it.  No AS, no need to retain broken AMS.

It gets you all the same machine readable chain of custody as AS+AMS+AAR in the unbroken case, and it breaks at the same place with the same detectability in the fraudulent-actor case.

There are no other cases.  There's no middle here.

Please do prove me wrong if you can think of another case, I really can't.

Bron.

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


--_----------=_150276069710802494-- From nobody Mon Aug 14 19:06:30 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8D013249D for ; Mon, 14 Aug 2017 19:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=DrNxSJe3; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=HTTx+SB2 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2A0rCXb-HBrK for ; Mon, 14 Aug 2017 19:06:27 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1E4313249F for ; Mon, 14 Aug 2017 19:06:21 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 542B320D50 for ; Mon, 14 Aug 2017 22:06:19 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Mon, 14 Aug 2017 22:06:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=mf1NC6Sc7OhaGhjxeIPprNkR2qgWmdcdKvVM1peZQ 14=; b=DrNxSJe3T2i7uu+bxExxvVULOTZsmvyArI7PKsM6XFX8+3sB+h+2F6iKJ 7r1kotUKxm1w63CLJYnYF6CwkhiqxHcargQfqndW0rxo0RCBLSl21CQPfwuLs64c INotd981WBc+wsljO40z4AAeI5RKvrM1KhpXAEPArUE0svK7l91SwPijt8KoUZGA ez+ytime0aY3o9gc1tR+Ny8wjAxHJPHJBY/DGLd4yHI13E+0Jcw/uwpRg9yejyJ+ WlIByXsdXhRDR1Vzn/1mRS0ckJyujTu1sfWTqahizYPQ9zUyWD0T9R92LNAXK9hK 6QemcsyojMLkX24wKxBzPDAAYOFtw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=mf1NC6Sc7OhaGhjxeIPprNkR2qgWm dcdKvVM1peZQ14=; b=HTTx+SB2Qhw4MscIl8eJQ1ieClXZXkYMamypAn+TLqT3q /8GX6HulFYrapb9Rx7K9Aycc6B1MeqriQvkKY32qoc0ee2mbN4vD00UrSPjQFlRW XuL6esnBGuD801d+fj8oho/FXfkivtxclfmXFVBq7xI6GW6GLrrNgfpfdhW2iTvV HGFpGjuGQiSVSbTd8PSKLWpjmH3Upunac0GOBK6uyh/s6RrlqjPanx1kzxRhVh1I QHi6AQK7hZ66dpCD8MV4f6qySAXlFikhnbetkK4vxEbzt3S0T6bSLgqpHptTfgJ2 AHT0n+7eJ41sQvhze2GllbP6a7Fj+IkDtTqYibxAQ== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 2267E9E264; Mon, 14 Aug 2017 22:06:19 -0400 (EDT) Message-Id: <1502762779.1086232.1073552432.22DE7E98@webmail.messagingengine.com> From: Bron Gondwana To: dmarc@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150276277910862320" X-Mailer: MessagingEngine.com Webmail Interface - ajax-ff6d44b3 Date: Tue, 15 Aug 2017 12:06:19 +1000 Archived-At: Subject: [dmarc-ietf] Prove me wrong! 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 Aug 2017 02:06:29 -0000 This is a multi-part message in MIME format. --_----------=_150276277910862320 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Seth pointed out that my emails have been long and contained many points, so I'd like to keep this really simple. I will propose two sets of headers on the same message, and I ask if anybody can find a case where the set with AS headers provides some information which is not present in the set without. Assume you are a receiver at site5.com who just received this message on your MX and are validating it. Set 1: AS: i=3; cv=pass; d=site4.com AMS: i=3; d=site4.com AAR: i=3; arc=pass (spf=fail spfdomain=site1.com dmarc=fail fromdomain=site1.com)AS; i=2; cv=pass; d=site3.com AMS: i=2; d=site3.com AAR i=2; arc=pass (spf=fail spfdomain=site1.com dmarc=pass fromdomain=site1.com)AS; i=1; cv=none; d=site2.com AMS: i=1; d=site2.com AAR i=1; arc=none (spf=pass spfdomain=site1.com dmarc=pass fromdomain=site1.com)DKIM-Signature: d=site1.com From: Set 2: AMS: i=3; d=site4.com; h=aar:aar:aar:to:from:etc AAR: i=3; arc=pass (arcdomain=site3.com spf=fail spfdomain=site1.com dmarc=fail fromdomain=site1.com)AMS: i=2; d=site3.com; h=aar:aar:to:from:etc AAR: i=2; arc=pass (arcdomain=site2.com spf=fail spfdomain=site1.com dmarc=pass fromdomain=site1.com)AAR: i=1; arc=none (spf=pass spfdomain=site1.com dmarc=pass fromdomain=site1.com)DKIM-Signature: d=site1.com From: In each case the AMS with i=2 and the AMS with i=3 are valid. I would love to see a case where Set 1 gives information that Set 2 doesn't, because that would prove that my understanding was incorrect. Regards, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_150276277910862320 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Seth pointed out that my emails have been long and contained many points, so I'd like to keep this really simple.

I will propose two sets of headers on the same message, and I ask if anybody can find a case where the set with AS headers provides some information which is not present in the set without.  Assume you are a receiver at site5.com who just received this message on your MX and are validating it.

Set 1:

AS: i=3; cv=pass; d=site4.com
AMS: i=3; d=site4.com
AAR: i=3; arc=pass (spf=fail spfdomain=site1.com dmarc=fail fromdomain=site1.com)
AS; i=2; cv=pass; d=site3.com
AMS: i=2; d=site3.com
AAR i=2; arc=pass (spf=fail spfdomain=site1.com dmarc=pass fromdomain=site1.com)
AS; i=1; cv=none; d=site2.com
AMS: i=1; d=site2.com
AAR i=1; arc=none (spf=pass spfdomain=site1.com dmarc=pass fromdomain=site1.com)
DKIM-Signature: d=site1.com
From: <foo@site1.com>

Set 2:

AMS: i=3; d=site4.com; h=aar:aar:aar:to:from:etc
AAR: i=3; arc=pass (arcdomain=site3.com spf=fail spfdomain=site1.com dmarc=fail fromdomain=site1.com)
AMS: i=2; d=site3.com; h=aar:aar:to:from:etc
AAR: i=2; arc=pass (arcdomain=site2.com spf=fail spfdomain=site1.com dmarc=pass fromdomain=site1.com)
AAR: i=1; arc=none (spf=pass spfdomain=site1.com dmarc=pass fromdomain=site1.com)
DKIM-Signature: d=site1.com
From: <foo@site1.com>

In each case the AMS with i=2 and the AMS with i=3 are valid.

I would love to see a case where Set 1 gives information that Set 2 doesn't, because that would prove that my understanding was incorrect.

Regards,

Bron.

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


--_----------=_150276277910862320-- From nobody Mon Aug 14 19:59:44 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 905681324AB for ; Mon, 14 Aug 2017 19:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 KNq4tV65jmIL for ; Mon, 14 Aug 2017 19:59:39 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A6FE1324A1 for ; Mon, 14 Aug 2017 19:59:39 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id f9so43385751uaf.4 for ; Mon, 14 Aug 2017 19:59:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=a236AFJmYMYU0xLBzHwYMSPLkxWN1X63Fc+1Y0THXNE=; b=a1JSyvXcUbHNCPKCf9IydCUieHzm6NVHNjBXE7l2UEI7YnZapu/vZgt+XqUhghzbX6 h0bvWCmZfIEia90VwlaHhooEkec+7vx95iHrzPk/O6cvV02z40IdGl0WW6e606ypyLxC DG8KEUKzzKoOMWTV/rjDs4P4Abuyuv/bibNxPbVquztJaDvgieZlWxYqOjC2nDjsz17q NEedyXGuxDjNCHmSntTQkAy+PoaRzUvMkKjKUvbFhpElZELUUHsFCqQZHAlaKzo5qlVT J+LO/SkYmYS9wsRReiYCqB8A5bxZxi6QwJn7TyWEqNS2ZssoiljkBnP/ye7xyvCpLwUC hZVw== 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=a236AFJmYMYU0xLBzHwYMSPLkxWN1X63Fc+1Y0THXNE=; b=LTiTtDUTIdWUWX+B5moeCTAh79QttbClNJBVk17jfMTCEBR7o1B8ahKrpAta9RIllZ Qc3egq/sBLhF4/zdcaj/QBhaWXbHmsOGWwdquxqLfnxYeMP2pD3u47UIVZuzlYm4txBt NKLyciEmKxA+kft4OW8Lyvc49WHaYyIaajXIQbrWZicW58hM7wm3Y0hp7nFz9m8Dht1P 4hddrOQzTxPkqtlMk7n8dZxFzrANaXKFfgiJhK7fsXvWfk0LNxE1HW+73oKG9FV3SVql dih7ULV21fMtzzY2nwE4lFKnCm58A/+a4Ja4JKaAUPwSPN93bCXkhNRjDhBNhJo5XPtY PNig== X-Gm-Message-State: AHYfb5jjWA6nb75yVHw4r/jcMvzUQ29P2XGBU+tRSGTTxBceNawLXZoY ctSPqnSarW8fTlnkuHpuxFP59yAiPSY0TbA= X-Received: by 10.176.74.71 with SMTP id r7mr16105388uae.180.1502765978391; Mon, 14 Aug 2017 19:59:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.151.25 with HTTP; Mon, 14 Aug 2017 19:59:17 -0700 (PDT) In-Reply-To: <1502760697.1080249.1073516280.7B4109C1@webmail.messagingengine.com> References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> <1502755921.1067004.1073467336.14612B87@webmail.messagingengine.com> <1502760697.1080249.1073516280.7B4109C1@webmail.messagingengine.com> From: Seth Blank Date: Mon, 14 Aug 2017 19:59:17 -0700 Message-ID: To: Bron Gondwana Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="f403045f8f0e53077e0556c1f8b4" Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre 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 Aug 2017 02:59:43 -0000 --f403045f8f0e53077e0556c1f8b4 Content-Type: text/plain; charset="UTF-8" On Mon, Aug 14, 2017 at 6:31 PM, Bron Gondwana wrote: > Do we, though? ARC has NOT ever been about localizing or understanding > changes to a message, it has been about understanding *actors* who may have > modified the message. > > > Sure, but knowing which actors may have modified the message and which > actors definitely didn't modify the message is super useful. > We get that with you suggestion above "first AMS failure" > > It means that if you trust the next hop, you don't need to trust the > intermediates that couldn't modified the message without colluding with > that next hop. > That's also how I see it. > For instance, if we have two ARC-participating hops, and it was a > non-participating hop between them who modified the message, we could > localize the breakage to being at or between the two hops, but could not > with certainty ascribe it to either hop, which is why ARC has avoided this. > > > If you trust hop 2, you can confirm that it was modified since hop 1 (or > that hop 1 can't form a valid signature). > > If you don't trust hop 2, then you don't know anything at all about the > message before hop 2, regardless of any signatures. > > If that isn't clear, then I didn't explain myself very well on our call! > Unless you trust hop 2, everything before that is meaningless, regardless > of ARC headers. An ARC chain through an untrusted hop 2 could be totally > fiction. > Nope, we're in agreement. > Yes, that makes sense - So long as each AAR includes the signing domain > that it checked against for its arc=pass, then no information is lost. > > > So much of ARC keeps trace information that might be useful to someone at > some point, it feels very weird to throw some headers out and keep others. > I argue we keep them all, and (to the discussion around Experimental > status) see what ends up being useful after this is in the wild for a bit. > This data can always be tossed later if it serves no real world purpose. > > > "might be useful to someone at some point" - that kind of wooliness is a > crock, sorry. Once crypto doesn't validate it has no meaning if all the > data is present elsewhere - and everything that an AMS claims except for > the crypto over the message is duplicated in the next hop's AAR. > > If that's not the case, we should fix it so that it is. > > "see what ends up being useful after this is in the wild for a bit" makes > sense for informational records. It doesn't make sense for cryptographic > data. Either the crypto is sound and it means something, or it's actively > misleading. A no-longer-validating AMS contains nothing that the next > hop's AAR doesn't contain. > So there have been two years of discussion about this on the list, and the consensus was that ARC will include trace information - like all non-originating AARs - because that information might be interesting or useful to some party at some point. Google has many instances where a non-originating AAR has the information that matters to them. But the tl;dr here is simply that the decision was made at its inception to include extra information that might be helpful later, and that the working group wasn't open to re-evaluating that decision because the body of ARC was built on it. If that's the design decision, then we need to be consistent in its application - which means not throwing out excess data, especially if someone says "that might be valuable to me." > > > > I just had a really good chat with Seth on Skype half an hour ago about > this. He was unable to find a case where having a full AS,AMS,AAR adds any > provable value over just checking the most-recent AMS and having AAR > signed. I do like your proposal of signing ALL the existing AARs, because > they're the thing of value. Old AMS have no value, and old AS have no > value either so long as you have a cv=pass on the current AS. > > > That's not quite what I said ;-) > > > OK, did I misunderstand? > > You couldn't quote a case where AS,AMS,AAR adds provable value over an AMS > that signs the most recent AAR. If you can find that case, I will eat all > my words, because I've spent a lot of time thinking through the cases. > > I agree with what Brandon seemed to be saying above - that it should be > all the AAR being signed, not just the top one. Otherwise an intermediate > could strip or modify earlier AAR without breaking the authentication, and > that would be bad. Each AAR contains real, valuable, meaningful data. > I said the AS forces anyone who modified the chain to sign. In the obvious "all trusted" and "clearly untrusted" signers cases, the AS doesn't seem to add much value. But if a bad actor finds a way to send a chain through a good intermediary, then not having an AS would allow this message to be delivered. This is an edge case, and maybe doesn't matter - but the AS certainly protects against it. The spec already covers all AARs by the AS. > > As far as I see, we're quibbling over how much cryptographic > infrastructure is needed to maintain the integrity of the chain of AAR > headers. > > If you throw old AMSs out, you cannot validate current ASs or walk the > chain back. > > > So what. AS is bunk. > > A current AMS over all AAR gives the same auditability, since AAR is the > only thing that has meaning. AMS only has meaning while it still > validates, and AS only has meaning because it ties AMS and AAR together. > Those meanings don't add value. None of them mean jack once you've been > through an untrusted site, all previous headers are suspect regardless of > whether they have crypto that still validates, unless that crypto covers > facts about the message which we actually care about. > I thought our discussion ended with the AS adding an extra layer that was benign at worst, and protected against future unknown attacks at best. And your concern was the overhead of evaluating the AS on DNS, especially for long chains. I thought where we ended was your suggestion that the spec only requiring validation of the latest AS and AMS, and implementations MAY validate all AS's if they wish. If this is the case, then we can't throw out any AMS because none of the ASs would validate any longer. > > I'll suggest language for stamping "first AMS failure", but we shouldn't > strip old AMS/AS headers. > > > This is where we disagree. We shouldn't create AS headers in the first > place. > This is 180 degrees from where we left off on the call. > We should have AMS sign all the AAR and that's it. No AS, no need to > retain broken AMS. > > It gets you all the same machine readable chain of custody as AS+AMS+AAR > in the unbroken case, and it breaks at the same place with the same > detectability in the fraudulent-actor case. > I'll let someone who's more familiar with where ARC started from - my understanding was that ARC stemmed from something similar to AMS+AAR being insufficient, but I don't have enough context here to provide meaningful insight. Seth There are no other cases. There's no middle here. > > Please do prove me wrong if you can think of another case, I really can't. > > Bron. > > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --f403045f8f0e53077e0556c1f8b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Aug 14, 2017 at 6:31 PM, Bron Gondwana <brong@fastmailteam.com> wrote:
=
Do we, though? ARC has NOT ever been about localizing or understanding= changes to a message, it has been about understanding *actors* who may hav= e modified the message.

Sure, but knowing which actors may = have modified the message and which actors definitely didn't modify the= message is super useful.

W= e get that with you suggestion above "first AMS failure"
=C2=A0

For instance, if = we have two ARC-participating hops, and it was a non-participating hop betw= een them who modified the message, we could localize the breakage to being = at or between the two hops, but could not with certainty ascribe it to eith= er hop, which is why ARC has avoided this.=C2=A0

If you trust hop 2, you can confirm= that it was modified since hop 1 (or that hop 1 can't form a valid sig= nature).

If you don't trust hop 2, then you do= n't know anything at all about the message before hop 2, regardless of = any signatures.

If that isn't clear, then I didn't= explain myself very well on our call!=C2=A0 Unless you trust hop 2, everyt= hing before that is meaningless, regardless of ARC headers.=C2=A0 An ARC ch= ain through an untrusted hop 2 could be totally fiction.

Nope, we're in agreement.
=C2= =A0
Yes, that makes sense= - So long as each AAR includes the signing domain that it checked against = for its arc=3Dpass, then no information is lost.

So much of ARC keeps trace information that might be useful to someone= at some point, it feels very weird to throw some headers out and keep othe= rs. I argue we keep them all, and (to the discussion around Experimental st= atus) see what ends up being useful after this is in the wild for a bit. Th= is data can always be tossed later if it serves no real world purpose.
<= /div>

"might be useful to someone at= some point" - that kind of wooliness is a crock, sorry.=C2=A0 Once c= rypto doesn't validate it has no meaning if all the data is present els= ewhere - and everything that an AMS claims except for the crypto over the m= essage is duplicated in the next hop's AAR.

If that's not the case, we should fix = it so that it is.

"see what ends up being useful after = this is in the wild for a bit" makes sense for informational records.= =C2=A0 It doesn't make sense for cryptographic data.=C2=A0 Either the c= rypto is sound and it means something, or it's actively misleading.=C2= =A0 A no-longer-validating AMS contains nothing that the next hop's AAR= doesn't contain.

So th= ere have been two years of discussion about this on the list, and the conse= nsus was that ARC will include trace information - like all non-originating= AARs - because that information might be interesting or useful to some par= ty at some point. Google has many instances where a non-originating AAR has= the information that matters to them. But the tl;dr here is simply that th= e decision was made at its inception to include extra information that migh= t be helpful later, and that the working group wasn't open to re-evalua= ting that decision because the body of ARC was built on it. If that's t= he design decision, then we need to be consistent in its application - whic= h means not throwing out excess data, especially if someone says "that= might be valuable to me."
=C2=A0

=C2=A0
I just had a really good chat with Seth on Skype half an hour ago about th= is.=C2=A0 He was unable to find a case where having a full=C2=A0AS,AMS,AAR = adds any provable value over just checking the most-recent AMS and having A= AR signed.=C2=A0 I do like your proposal of signing ALL the existing AARs, = because they're the thing of value.=C2=A0 Old AMS have no value, and ol= d AS have no value either so long as you have a cv=3Dpass on the current AS= .

That's not quite what I said ;-)

OK, did I misunderstand?

You couldn't quote a case where AS,AM= S,AAR adds provable value over an AMS that signs the most recent AAR.=C2=A0= If you can find that case, I will eat all my words, because I've spent= a lot of time thinking through the cases.

I agree with what Brandon seemed to be say= ing above - that it should be all the AAR being signed, not just the top on= e.=C2=A0 Otherwise an intermediate could strip or modify earlier AAR withou= t breaking the authentication, and that would be bad.=C2=A0 Each AAR contai= ns real, valuable, meaningful data.

I said the AS forces anyone who modified the chain to sign. In the= obvious "all trusted" and "clearly untrusted" signers = cases, the AS doesn't seem to add much value. But if a bad actor finds = a way to send a chain through a good intermediary, then not having an AS wo= uld allow this message to be delivered. This is an edge case, and maybe doe= sn't matter - but the AS certainly protects against it.

<= /div>
The spec already covers all AARs by the AS.
=C2=A0

As far as I see, we're quibbling over = how much cryptographic infrastructure is needed to maintain the integrity o= f the chain of AAR headers.

If you throw old = AMSs out, you cannot validate current ASs or walk the chain back.=C2=A0
=

So what.=C2=A0 AS is bunk.

A current AMS over all AAR gives the same = auditability, since AAR is the only thing that has meaning.=C2=A0 AMS only = has meaning while it still validates, and AS only has meaning because it ti= es AMS and AAR together.=C2=A0 Those meanings don't add value.=C2=A0 No= ne of them mean jack once you've been through an untrusted site, all pr= evious headers are suspect regardless of whether they have crypto that stil= l validates, unless that crypto covers facts about the message which we act= ually care about.

I thought= our discussion ended with the AS adding an extra layer that was benign at = worst, and protected against future unknown attacks at best. And your conce= rn was the overhead of evaluating the AS on DNS, especially for long chains= . I thought where we ended was your suggestion that the spec only requiring= validation of the latest AS and AMS, and implementations MAY validate all = AS's if they wish.

If this is the case, then w= e can't throw out any AMS because none of the ASs would validate any lo= nger.
=C2=A0

I'll suggest language for stamping "first AMS failure", = but we shouldn't strip old AMS/AS headers.

This is where we disagree.=C2=A0 We= shouldn't create AS headers in the first place.

This is 180 degrees from where we left off on the= call.
=C2=A0
We should have AMS sign all the AAR and th= at's it.=C2=A0 No AS, no need to retain broken AMS.

It gets you all the same machine readable = chain of custody as AS+AMS+AAR in the unbroken case, and it breaks at the = same place with the same detectability in the fraudulent-actor case.

I'll let someone who's mo= re familiar with where ARC started from - my understanding was that ARC ste= mmed from something similar to AMS+AAR being insufficient, but I don't = have enough context here to provide meaningful insight.

--f403045f8f0e53077e0556c1f8b4-- From nobody Mon Aug 14 20:26:50 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0E31324A8 for ; Mon, 14 Aug 2017 20:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=C2WrJk9j; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=p0zptvKk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEz1x3hLigbe for ; Mon, 14 Aug 2017 20:26:41 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53AA21320CF for ; Mon, 14 Aug 2017 20:26:41 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id C3D38209F9; Mon, 14 Aug 2017 23:26:40 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Mon, 14 Aug 2017 23:26:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=LOVwAo ztlvn2qtrdArVU2JqWcBSwwoZUxMjbsTozNV4=; b=C2WrJk9jTDOmGpML2Buk1e ZcMx7rhDkgPG0Hzkb3mvW8Lr7/i+dlWWuvKkyegHApGqmxyBbjK3n+cOcb+MPzuP 8vm0Hha6BEJgTdbIYFxaqFiC2s/bO7aarfYIl6XAu0L8NpKrU8Ji0LBCklWDP7vF fhtyg2iLSQdIDipEtVRSm1pokN1hsmwe5wlRxrmK1rmQAwFLElC+wVCRbK5LPoAT 3Tmz9cjD9T7yKMwfADOVIvIGjHQZSth7Jj8+sy/+ddqFLjepXqFfBcEc8sfEIqK+ j+EwgewA/4+5WlzDiri22VSX6NndLq9BkWJltMVccsuGbWdit52kcngWbLU47AVQ == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=LOVwAo ztlvn2qtrdArVU2JqWcBSwwoZUxMjbsTozNV4=; b=p0zptvKk/y00NdDa3H8wFO OQ+NbQY5ku7cJ75njRwFrXFmbDLi7a30BIhE5d5WxggmsYxJ5jitJ3jXM5JjOoGP VJ4eHIjXEUQFyLIp2XC1tqIRuOr+vvov+t/hUGXDKonDspmGiNnFA+gEHdqj72l0 9CsLG+ujFjV0IQXQZs1IhIAhW6FXextVvJ9kgOMvsbyPQfpiLMuXf2gmsh28IfS0 p2z7Vqft0/i8ME/z/xXbymcaMG2NZtXK2zHjeK1jYlBAGq6bIBG6GPiA3lTJm5M0 W9CIBJYbYtVKD1fslrb2woYixiAVqPYOs1aarM3GNDuoS0CwOcFXPNvpXK1KrRQA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 8E9439E264; Mon, 14 Aug 2017 23:26:40 -0400 (EDT) Message-Id: <1502767600.1109836.1073601728.39EC6083@webmail.messagingengine.com> From: Bron Gondwana To: Seth Blank Cc: dmarc@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150276760011098360" X-Mailer: MessagingEngine.com Webmail Interface - ajax-ff6d44b3 References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> <1502755921.1067004.1073467336.14612B87@webmail.messagingengine.com> <1502760697.1080249.1073516280.7B4109C1@webmail.messagingengine.com> Date: Tue, 15 Aug 2017 13:26:40 +1000 In-Reply-To: Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre 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 Aug 2017 03:26:45 -0000 This is a multi-part message in MIME format. --_----------=_150276760011098360 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Tue, 15 Aug 2017, at 12:59, Seth Blank wrote: > >> >> "might be useful to someone at some point" - that kind of wooliness >> is a crock, sorry. Once crypto doesn't validate it has no meaning >> if all the data is present elsewhere - and everything that an AMS >> claims except for the crypto over the message is duplicated in the >> next hop's AAR.>> >> If that's not the case, we should fix it so that it is. >> >> "see what ends up being useful after this is in the wild for a bit" >> makes sense for informational records. It doesn't make sense for >> cryptographic data. Either the crypto is sound and it means >> something, or it's actively misleading. A no-longer-validating AMS >> contains nothing that the next hop's AAR doesn't contain.> > So there have been two years of discussion about this on the list, > and the consensus was that ARC will include trace information - like > all non-originating AARs - because that information might be > interesting or useful to some party at some point. Google has many > instances where a non-originating AAR has the information that > matters to them. But the tl;dr here is simply that the decision was > made at its inception to include extra information that might be > helpful later, and that the working group wasn't open to re- > evaluating that decision because the body of ARC was built on it. If > that's the design decision, then we need to be consistent in its > application - which means not throwing out excess data, especially if > someone says "that might be valuable to me."> Yes, trace information is good. I absolutely agree that you need to keep all the AARs. The problem with AS is that it's not trace information in any meaningful way over time. The AS only validates while that key is still published, so it's not "forever". (mind you, nothing validates forever, the AMSes only validate while they key is still in DNS too) The fact that there was an AMS gets captured in the next AAR. >> >>>> I just had a really good chat with Seth on Skype half an hour ago >>>> about this. He was unable to find a case where having a full >>>> AS,AMS,AAR adds any provable value over just checking the most- >>>> recent AMS and having AAR signed. I do like your proposal of >>>> signing ALL the existing AARs, because they're the thing of value. >>>> Old AMS have no value, and old AS have no value either so long as >>>> you have a cv=pass on the current AS.>>> >>> That's not quite what I said ;-) >> >> >> OK, did I misunderstand? >> >> You couldn't quote a case where AS,AMS,AAR adds provable value over >> an AMS that signs the most recent AAR. If you can find that case, I >> will eat all my words, because I've spent a lot of time thinking >> through the cases.>> >> I agree with what Brandon seemed to be saying above - that it should >> be all the AAR being signed, not just the top one. Otherwise an >> intermediate could strip or modify earlier AAR without breaking the >> authentication, and that would be bad. Each AAR contains real, >> valuable, meaningful data.> > I said the AS forces anyone who modified the chain to sign. In the > obvious "all trusted" and "clearly untrusted" signers cases, the AS > doesn't seem to add much value. But if a bad actor finds a way to send > a chain through a good intermediary, then not having an AS would allow > this message to be delivered. This is an edge case, and maybe doesn't > matter - but the AS certainly protects against it. Can you please expand on this point and show how the AS is protecting against a bad actor sending a chain through a good intermediary. I really don't see it. An example of AS protecting against a bad actor here would totally blow my argument out of the water. > > The spec already covers all AARs by the AS. > >> >> >> As far as I see, we're quibbling over how much cryptographic >> infrastructure is needed to maintain the integrity of the chain of >> AAR headers.>> >> >>> If you throw old AMSs out, you cannot validate current ASs or walk >>> the chain back.>> >> >> So what. AS is bunk. >> >> A current AMS over all AAR gives the same auditability, since AAR is >> the only thing that has meaning. AMS only has meaning while it still >> validates, and AS only has meaning because it ties AMS and AAR >> together. Those meanings don't add value. None of them mean jack >> once you've been through an untrusted site, all previous headers are >> suspect regardless of whether they have crypto that still validates, >> unless that crypto covers facts about the message which we actually >> care about.> > I thought our discussion ended with the AS adding an extra layer that > was benign at worst, and protected against future unknown attacks at > best. And your concern was the overhead of evaluating the AS on DNS, > especially for long chains. I thought where we ended was your > suggestion that the spec only requiring validation of the latest AS > and AMS, and implementations MAY validate all AS's if they wish.> > If this is the case, then we can't throw out any AMS because none of > the ASs would validate any longer.> >> >>> >>> I'll suggest language for stamping "first AMS failure", but we >>> shouldn't strip old AMS/AS headers.>> >> >> This is where we disagree. We shouldn't create AS headers in the >> first place.> > This is 180 degrees from where we left off on the call. That is true. We discussed an alternative world in which we keep the AS but reduce the validation requirement. That's my fallback position if I can't convince people that AS is pointless. It's not my preferred position, which is where I went in response to Brandon's post. >> We should have AMS sign all the AAR and that's it. No AS, no need to >> retain broken AMS.>> >> It gets you all the same machine readable chain of custody as >> AS+AMS+AAR in the unbroken case, and it breaks at the same place >> with the same detectability in the fraudulent-actor case.> > I'll let someone who's more familiar with where ARC started from - my > understanding was that ARC stemmed from something similar to AMS+AAR > being insufficient, but I don't have enough context here to provide > meaningful insight. I would love to see that. If you can show me a case where AS protects against a bad actor, and where having the latest AMS signing all AAR doesn't provide equivalent protection, I will eat a whole lot of crow and crawl back in my corner, because I don't see it. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_150276760011098360 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Tue, 15 Aug 2017, at 12:59, Seth Blank wrote:


"might be useful to someone at some point" - that kind of wooliness is a crock, sorry.  Once crypto doesn't validate it has no meaning if all the data is present elsewhere - and everything that an AMS claims except for the crypto over the message is duplicated in the next hop's AAR.

If that's not the case, we should fix it so that it is.

"see what ends up being useful after this is in the wild for a bit" makes sense for informational records.  It doesn't make sense for cryptographic data.  Either the crypto is sound and it means something, or it's actively misleading.  A no-longer-validating AMS contains nothing that the next hop's AAR doesn't contain.

So there have been two years of discussion about this on the list, and the consensus was that ARC will include trace information - like all non-originating AARs - because that information might be interesting or useful to some party at some point. Google has many instances where a non-originating AAR has the information that matters to them. But the tl;dr here is simply that the decision was made at its inception to include extra information that might be helpful later, and that the working group wasn't open to re-evaluating that decision because the body of ARC was built on it. If that's the design decision, then we need to be consistent in its application - which means not throwing out excess data, especially if someone says "that might be valuable to me."
 

Yes, trace information is good.  I absolutely agree that you need to keep all the AARs.

The problem with AS is that it's not trace information in any meaningful way over time.  The AS only validates while that key is still published, so it's not "forever".

(mind you, nothing validates forever, the AMSes only validate while they key is still in DNS too)

The fact that there was an AMS gets captured in the next AAR.

 
I just had a really good chat with Seth on Skype half an hour ago about this.  He was unable to find a case where having a full AS,AMS,AAR adds any provable value over just checking the most-recent AMS and having AAR signed.  I do like your proposal of signing ALL the existing AARs, because they're the thing of value.  Old AMS have no value, and old AS have no value either so long as you have a cv=pass on the current AS.

That's not quite what I said ;-)


OK, did I misunderstand?

You couldn't quote a case where AS,AMS,AAR adds provable value over an AMS that signs the most recent AAR.  If you can find that case, I will eat all my words, because I've spent a lot of time thinking through the cases.

I agree with what Brandon seemed to be saying above - that it should be all the AAR being signed, not just the top one.  Otherwise an intermediate could strip or modify earlier AAR without breaking the authentication, and that would be bad.  Each AAR contains real, valuable, meaningful data.

I said the AS forces anyone who modified the chain to sign. In the obvious "all trusted" and "clearly untrusted" signers cases, the AS doesn't seem to add much value. But if a bad actor finds a way to send a chain through a good intermediary, then not having an AS would allow this message to be delivered. This is an edge case, and maybe doesn't matter - but the AS certainly protects against it.

Can you please expand on this point and show how the AS is protecting against a bad actor sending a chain through a good intermediary.  I really don't see it.  An example of AS protecting against a bad actor here would totally blow my argument out of the water.


The spec already covers all AARs by the AS.
 


As far as I see, we're quibbling over how much cryptographic infrastructure is needed to maintain the integrity of the chain of AAR headers.


If you throw old AMSs out, you cannot validate current ASs or walk the chain back. 


So what.  AS is bunk.

A current AMS over all AAR gives the same auditability, since AAR is the only thing that has meaning.  AMS only has meaning while it still validates, and AS only has meaning because it ties AMS and AAR together.  Those meanings don't add value.  None of them mean jack once you've been through an untrusted site, all previous headers are suspect regardless of whether they have crypto that still validates, unless that crypto covers facts about the message which we actually care about.

I thought our discussion ended with the AS adding an extra layer that was benign at worst, and protected against future unknown attacks at best. And your concern was the overhead of evaluating the AS on DNS, especially for long chains. I thought where we ended was your suggestion that the spec only requiring validation of the latest AS and AMS, and implementations MAY validate all AS's if they wish.

If this is the case, then we can't throw out any AMS because none of the ASs would validate any longer.
 


I'll suggest language for stamping "first AMS failure", but we shouldn't strip old AMS/AS headers.


This is where we disagree.  We shouldn't create AS headers in the first place.

This is 180 degrees from where we left off on the call. 

That is true.   We discussed an alternative world in which we keep the AS but reduce the validation requirement.  That's my fallback position if I can't convince people that AS is pointless.  It's not my preferred position, which is where I went in response to Brandon's post.

We should have AMS sign all the AAR and that's it.  No AS, no need to retain broken AMS.

It gets you all the same machine readable chain of custody as AS+AMS+AAR in the unbroken case, and it breaks at the same place with the same detectability in the fraudulent-actor case.

I'll let someone who's more familiar with where ARC started from - my understanding was that ARC stemmed from something similar to AMS+AAR being insufficient, but I don't have enough context here to provide meaningful insight. 

I would love to see that.

If you can show me a case where AS protects against a bad actor, and where having the latest AMS signing all AAR doesn't provide equivalent protection, I will eat a whole lot of crow and crawl back in my corner, because I don't see it.

Bron.

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


--_----------=_150276760011098360-- From nobody Tue Aug 15 11:42:55 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8156132398 for ; Tue, 15 Aug 2017 11:42: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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMPxtg40ACuG for ; Tue, 15 Aug 2017 11:42:52 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 192811243F6 for ; Tue, 15 Aug 2017 11:42:52 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id e124so15436795oig.2 for ; Tue, 15 Aug 2017 11:42:52 -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=797hD6P1mXqUF/J6R1wg1/zpK8sqM3UWuma+nACrJao=; b=KGZzZCq0wX1j789L8y+YELQ8NY2FvfPrE1PBumdYACc7lXXiM4qoZ7+N9/cEfVHFo4 Ms9FvrMz7+Rawbuyf1mpksfHi+O274sohwVlpreERxKY5EIdO5qp02HrprzY9eHXJXM3 OVVHHOclz1CYOzwdJUYk0U7f949yhFBhtUdcXrJZtNBTGPP4ftbLm3nfEtJCpkQnkSkk yBNKKvp7Fx6fJls3jtNDDR537mFNEdO8/j8nCOfZV8IyZrbfCfwxnLHaMoJA+1y2dURh Rm/AkFuL5Jh7MheS+tC+g7cDECPDigJzcdfDK7O0lBwJkurgOnQUnvF4YgUaez41Y94m pJtA== 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=797hD6P1mXqUF/J6R1wg1/zpK8sqM3UWuma+nACrJao=; b=im/Wdumk3XN4JGk1fBFTukyTY+wlTo6WNOoNDrnV2pWV5+VPUmew63oHSW6r0WMsp8 K0tmiAXJDHd81qc6M9ewPafgtxw5T8bowMuY5p+hC4EMnZWo7JNc3YZM2SZBYjuIsL6I SmELyFDwinoAW/FJSd5YHhKzy4+uQIHaApdoWx7IEYLHT47oJySwkSmmHkyvYRp/1U98 liQ1aMqiGqunZQ441g8ymmONwHROmZMQyj3N6gFP19TyWICvOCsNds8AWbH4taoxjDhp dTcuWAPM706O2HuDlqrxe/iT407ejqWBzWM3eSRTc7U/FuJkfsm0g0J/Iu2FXvvGFNyv wPdA== X-Gm-Message-State: AHYfb5jJisAKG6rRBMuvHsxnmy1sYdjEqpwYNzyLmiaM7D+X9KIzQ/ro BPIoViGJk5FKtLpkIW4= X-Received: by 10.202.75.18 with SMTP id y18mr34684043oia.68.1502822570885; Tue, 15 Aug 2017 11:42:50 -0700 (PDT) Received: from ?IPv6:2602:304:cda0:8800:d17e:7fe3:9cb7:7c98? ([2602:304:cda0:8800:d17e:7fe3:9cb7:7c98]) by smtp.gmail.com with ESMTPSA id d189sm17516433oih.1.2017.08.15.11.42.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Aug 2017 11:42:49 -0700 (PDT) From: Dave Crocker To: "dmarc@ietf.org" Message-ID: <47f775ab-5cd3-ff00-1fb1-19328f8507e9@gmail.com> Date: Tue, 15 Aug 2017 11:42:47 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] How are ARC results processed, relative to 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 Aug 2017 18:42:54 -0000 G'day. ARC is motivated by a desire to deal with a class of DMARC failures. In that context, it can be seen as 'augmenting' DMARC, even though it is formally separate from DMARC. That is, ARC doesn't and shouldn't specify how ARC is used in a DMARC context. But there needs to be some understanding -- and I suspect a spec, somewhere, eventually -- that says how to integrate ARC into an engine that includes DMARC. BTW, the DMARC spec uses the terms 'pass' and 'fail' with respect to the underlying authentication mechanisms of DKIM and SPF. It also uses it within the context of DMARC processing, itself, but it does not define what those terms mean, in that context. Beyond reference to DMARC 'policy' records, text in the specs that talk about processing DMARC policy is similarly implicit, rather than explicit. The only clear, explicit directive about DMARC outcomes seems to be Section 6.6.2 #6, Apply policy. An example of possible confusion in the case of ARC: does DMARC still 'fail'? Yet the whole point of ARC is to create the possibility of still getting delivered, in spite of this. So, were one to write something to augment the DMARC spec, in support of ARC, what are the kinds of text one ought to formulate and how should they be linked to the DMARC spec? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Aug 15 15:18:53 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34E6413242D for ; Tue, 15 Aug 2017 15:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wlkNtxs0OlC for ; Tue, 15 Aug 2017 15:18:49 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0352132428 for ; Tue, 15 Aug 2017 15:18:48 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id d29so7892327uai.2 for ; Tue, 15 Aug 2017 15:18:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ghkxytZucs+UaD7B9L4rHOqG1vCSibqW0eswg5meGiE=; b=VY+jV/nD9ZcKVFFyF9QcBvLeE2gv/mii8pHvNU5xePfp0ANAa1scSoBSWUFhQZOmAH NVnsdT6Lp4dpzRLulx5L6c8/LGgfcKN1ndSuPT7yxLx4OT6iOAwEFMeMtPo05Qh+QJ/c 22B9H9LTQRpzS5bVikX5jYmVDLH2Y/skkLOcWCk96y8nAeGhx06/BhyRkkTxkfKR7twM hCy6gf+v6eHZDNwd+2vr7Ypz7UTEs5GZsHBKAW8o4c5Lc6F/09/KSEB8XNesusyGMxGL XQqBcgiryXmZk3Hn3cUJN5hY6+H/4EahPP58fu/uUhr6u5VoprQ6eo6p0oMo4vUf1Elr 7rWw== 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=ghkxytZucs+UaD7B9L4rHOqG1vCSibqW0eswg5meGiE=; b=GTXSBXi4dZPEVzsQQzWzCmYjszmYaKft4kBgmYlALJtTLrzs6eFj9RisqZf+rpwqio xxO7CjUOkNBBcsc0x6ybiTQp4CoZ9YKkSKskt4Bdc11exqD+MvD7PjICyDswwYWZcA7l uHz/mljTzD3+fQFW/cPJ+I2CgiLfnAhBMpxsfoYDM34/4AOJeRVNLHwE0/FbWwsfLtVo mp0nA/Vibbu6XSpZJyM7nvPPDNxED2duQ3d31jnIxMMTUZFZcpbWl/+2Qr3WyPT4SW28 SjHFlbRXX5LssZTbJT2H0MyP+vZETXMFY7ekSmPP++kJuaUsY0FybZOGShK1PaTG4jkT INJA== X-Gm-Message-State: AHYfb5j/SaqErPUm39FgC34J8D6ykfVWpcHphO4iEufpwoclwJOBN2A1 Ryltckmxdz2T2bNl8bsZqJ5xocl4Q+hs X-Received: by 10.176.26.155 with SMTP id j27mr20971320uai.45.1502835527414; Tue, 15 Aug 2017 15:18:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.135.139 with HTTP; Tue, 15 Aug 2017 15:18:46 -0700 (PDT) In-Reply-To: <47f775ab-5cd3-ff00-1fb1-19328f8507e9@gmail.com> References: <47f775ab-5cd3-ff00-1fb1-19328f8507e9@gmail.com> From: Brandon Long Date: Tue, 15 Aug 2017 15:18:46 -0700 Message-ID: To: Dave Crocker Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="f403045f280ac560b70556d2290f" Archived-At: Subject: Re: [dmarc-ietf] How are ARC results processed, relative to 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 Aug 2017 22:18:51 -0000 --f403045f280ac560b70556d2290f Content-Type: text/plain; charset="UTF-8" For our usage, we still consider dmarc=fail, and then include the actual disposition (dis=) in the comments in the auth-res header. In the xml rua report, we would then specify in the PolicyEvaluatedType the actual disposition and the PolicyOverrideType of local_policy with a comment saying arc=pass. This is all said explicitly in draft-ietf-dmarc-arc-protocol-08 9.6.2, though it does this with the fragment of the dmarc report instead of in text. We could expand this to something like... ARC is not used in DMARC evaluation, the DMARC result is independent of ARC. ARC can be used by a receiver to override the Domain Owner's policy and apply a different disposition from what they asked for. In that case, it should be reported as a DMARC fail with a PolicyOverrideType of local_policy. Brandon On Tue, Aug 15, 2017 at 11:42 AM, Dave Crocker wrote: > G'day. > > ARC is motivated by a desire to deal with a class of DMARC failures. In > that context, it can be seen as 'augmenting' DMARC, even though it is > formally separate from DMARC. That is, ARC doesn't and shouldn't specify > how ARC is used in a DMARC context. But there needs to be some > understanding -- and I suspect a spec, somewhere, eventually -- that says > how to integrate ARC into an engine that includes DMARC. > > BTW, the DMARC spec uses the terms 'pass' and 'fail' with respect to the > underlying authentication mechanisms of DKIM and SPF. It also uses it > within the context of DMARC processing, itself, but it does not define what > those terms mean, in that context. Beyond reference to DMARC 'policy' > records, text in the specs that talk about processing DMARC policy is > similarly implicit, rather than explicit. The only clear, explicit > directive about DMARC outcomes seems to be Section 6.6.2 #6, Apply policy. > > An example of possible confusion in the case of ARC: does DMARC still > 'fail'? Yet the whole point of ARC is to create the possibility of still > getting delivered, in spite of this. > > So, were one to write something to augment the DMARC spec, in support of > ARC, what are the kinds of text one ought to formulate and how should they > be linked to the DMARC spec? > > d/ > > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --f403045f280ac560b70556d2290f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For our usage, we still consider dmarc=3Dfail, and then in= clude the actual disposition (dis=3D) in the comments in the auth-res heade= r.=C2=A0 In the xml rua report, we would then specify in the PolicyEvaluate= dType the actual disposition and the PolicyOverrideType of local_policy wit= h a comment saying arc=3Dpass.

This is all said explicit= ly in draft-ietf-dmarc-arc-protocol-08 9.6.2, though it does this with the = fragment of the dmarc report instead of in text.

W= e could expand this to something like...

ARC is no= t used in DMARC evaluation, the DMARC result is independent of ARC.=C2=A0 A= RC can be used by a receiver to override the Domain Owner's policy and = apply a different disposition from what they asked for.=C2=A0 In that case,= it should be reported as a DMARC fail with a PolicyOverrideType of local_p= olicy.

Brandon

On Tue, Aug 15, 2017 at 11:42 AM, Dave Cr= ocker <dcrocker@gmail.com> wrote:
G'day.

ARC is motivated by a desire to deal with a class of DMARC failures.=C2=A0 = In that context, it can be seen as 'augmenting' DMARC, even though = it is formally separate from DMARC.=C2=A0 That is, ARC doesn't and shou= ldn't specify how ARC is used in a DMARC context.=C2=A0 But there needs= to be some understanding -- and I suspect a spec, somewhere, eventually --= that says how to integrate ARC into an engine that includes DMARC.

BTW, the DMARC spec uses the terms 'pass' and 'fail' with r= espect to the underlying authentication mechanisms of DKIM and SPF.=C2=A0 I= t also uses it within the context of DMARC processing, itself, but it does = not define what those terms mean, in that context.=C2=A0 Beyond reference t= o DMARC 'policy' records, text in the specs that talk about process= ing DMARC policy is similarly implicit, rather than explicit.=C2=A0 The onl= y clear, explicit directive about DMARC outcomes seems to be Section 6.6.2 = #6, Apply policy.

An example of possible confusion in the case of ARC:=C2=A0 does DMARC still= 'fail'?=C2=A0 Yet the whole point of ARC is to create the possibil= ity of still getting delivered, in spite of this.

So, were one to write something to augment the DMARC spec, in support of AR= C, what are the kinds of text one ought to formulate and how should they be= linked to the DMARC spec?
d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

--f403045f280ac560b70556d2290f-- From nobody Tue Aug 15 15:41:04 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A4113242D for ; Tue, 15 Aug 2017 15:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZIggzBXvhuL for ; Tue, 15 Aug 2017 15:41:00 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96CD71323B1 for ; Tue, 15 Aug 2017 15:41:00 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id u133so7052242vke.3 for ; Tue, 15 Aug 2017 15:41:00 -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=5ia3fQEL607xYLURqebTh6cZhcUiu2/wWGiSjO3pcbA=; b=b1/TrFeHU6EOEoQ0eVxATAbzWhqP1wx6Rsz5AhlRCHiJlMTT6KfasZeRy2z+5aV5Sh zf260ZdxCwUNNHFG+jjfTWFU7VHi+WrxLCsbTXj9KW0BZ+EP3Q8kG8HYhcTirnbCDoRD cWFoXpx8o7Z9CL+NcWKrrp7FUNMvntHfSnYV5+YrqsWqSrx+YQrJReB9eVV+2t3C2FYi d2V4WohufpFJbXtrEfzTSniJji9PduwP8zN0jp1USjfgbSelRvD2RWNeVn6KwX/qjdD1 uEkCdAr03zdthiL9on5mFZIiM5S0DCDuoFTyvTV1P4vMSKhr8Sf9rodVWL+8aErcdzEa ULPA== 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=5ia3fQEL607xYLURqebTh6cZhcUiu2/wWGiSjO3pcbA=; b=BnezaHQZTtdD+IqCSUkrrYfBYWKmw97ksaHThMqQQ3O1bjvMHoaWEKHTBMghMERQo6 uwTL1jP1ny9I1hRKOA2vBoooNtiEz69JqlC7RBWF0C1otgZ0NCUDwkIOpkcCX+XIpmBp wSH8HUdD4tGpNxMTWGVCHVdNegTjFUF/yezShfL5CvV3gMDYP46UPyOXdpvdDmEbGkCA ZmeO4iQm64cNueFB4BX1hlxAXGIgzzTRf4ynW9Hn/rbly52UMNohVay3tT4LjSHNKMY1 GH2IHSINHrppxTE6wNYKNED5lOtVIOhAzQwe33Mp+DXxzoVg7HMCwxYDOIwFA4I9pErr hVfw== X-Gm-Message-State: AHYfb5jjsIpvto5KjQDMn56jQnJIjnzvt+qawKHCREiqlOYX5Ymgc9xj TTDeosbf83rPasi/cOz2GDfGu45vpDRBfrk= X-Received: by 10.31.3.99 with SMTP id 96mr18997956vkd.185.1502836859405; Tue, 15 Aug 2017 15:40:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.151.25 with HTTP; Tue, 15 Aug 2017 15:40:38 -0700 (PDT) In-Reply-To: References: <47f775ab-5cd3-ff00-1fb1-19328f8507e9@gmail.com> From: Seth Blank Date: Tue, 15 Aug 2017 15:40:38 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a11426cd22920180556d279f0" Archived-At: Subject: Re: [dmarc-ietf] How are ARC results processed, relative to 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 Aug 2017 22:41:03 -0000 --001a11426cd22920180556d279f0 Content-Type: text/plain; charset="UTF-8" I'm on the same page as Brandon. Additionally, earlier on the list and also in Prague, it was discussed formalizing DMARC reporting for ARC in a separate document, which would extend/override 9.6.2 of the current spec. On Tue, Aug 15, 2017 at 3:18 PM, Brandon Long wrote: > For our usage, we still consider dmarc=fail, and then include the actual > disposition (dis=) in the comments in the auth-res header. In the xml rua > report, we would then specify in the PolicyEvaluatedType the actual > disposition and the PolicyOverrideType of local_policy with a comment > saying arc=pass. > > This is all said explicitly in draft-ietf-dmarc-arc-protocol-08 9.6.2, > though it does this with the fragment of the dmarc report instead of in > text. > > We could expand this to something like... > > ARC is not used in DMARC evaluation, the DMARC result is independent of > ARC. ARC can be used by a receiver to override the Domain Owner's policy > and apply a different disposition from what they asked for. In that case, > it should be reported as a DMARC fail with a PolicyOverrideType of > local_policy. > > Brandon > > On Tue, Aug 15, 2017 at 11:42 AM, Dave Crocker wrote: > >> G'day. >> >> ARC is motivated by a desire to deal with a class of DMARC failures. In >> that context, it can be seen as 'augmenting' DMARC, even though it is >> formally separate from DMARC. That is, ARC doesn't and shouldn't specify >> how ARC is used in a DMARC context. But there needs to be some >> understanding -- and I suspect a spec, somewhere, eventually -- that says >> how to integrate ARC into an engine that includes DMARC. >> >> BTW, the DMARC spec uses the terms 'pass' and 'fail' with respect to the >> underlying authentication mechanisms of DKIM and SPF. It also uses it >> within the context of DMARC processing, itself, but it does not define what >> those terms mean, in that context. Beyond reference to DMARC 'policy' >> records, text in the specs that talk about processing DMARC policy is >> similarly implicit, rather than explicit. The only clear, explicit >> directive about DMARC outcomes seems to be Section 6.6.2 #6, Apply policy. >> >> An example of possible confusion in the case of ARC: does DMARC still >> 'fail'? Yet the whole point of ARC is to create the possibility of still >> getting delivered, in spite of this. >> >> So, were one to write something to augment the DMARC spec, in support of >> ARC, what are the kinds of text one ought to formulate and how should they >> be linked to the DMARC spec? >> >> d/ >> >> >> -- >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >> >> _______________________________________________ >> 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 > > --001a11426cd22920180556d279f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm on the same page as Brandon.

Ad= ditionally, earlier on the list and also in Prague, it was discussed formal= izing DMARC reporting for ARC in a separate document, which would extend/ov= erride 9.6.2 of the current spec.
On Tue, Aug 15, 2017 at 3:18 PM, Brandon Long <= span dir=3D"ltr"><= blong@google.com> wrote:
For our usage, we still consider dmarc=3Dfail, and then incl= ude the actual disposition (dis=3D) in the comments in the auth-res header.= =C2=A0 In the xml rua report, we would then specify in the PolicyEvaluatedT= ype the actual disposition and the PolicyOverrideType of local_policy with = a comment saying arc=3Dpass.

This is all said explicitly= in draft-ietf-dmarc-arc-protocol-08 9.6.2, though it does this with t= he fragment of the dmarc report instead of in text.

We could expand this to something like...

ARC is= not used in DMARC evaluation, the DMARC result is independent of ARC.=C2= =A0 ARC can be used by a receiver to override the Domain Owner's policy= and apply a different disposition from what they asked for.=C2=A0 In that = case, it should be reported as a DMARC fail with a PolicyOverrideType of lo= cal_policy.

Brandon

On Tue, A= ug 15, 2017 at 11:42 AM, Dave Crocker <dcrocker@gmail.com> = wrote:
G'day.

ARC is motivated by a desire to deal with a class of DMARC failures.=C2=A0 = In that context, it can be seen as 'augmenting' DMARC, even though = it is formally separate from DMARC.=C2=A0 That is, ARC doesn't and shou= ldn't specify how ARC is used in a DMARC context.=C2=A0 But there needs= to be some understanding -- and I suspect a spec, somewhere, eventually --= that says how to integrate ARC into an engine that includes DMARC.

BTW, the DMARC spec uses the terms 'pass' and 'fail' with r= espect to the underlying authentication mechanisms of DKIM and SPF.=C2=A0 I= t also uses it within the context of DMARC processing, itself, but it does = not define what those terms mean, in that context.=C2=A0 Beyond reference t= o DMARC 'policy' records, text in the specs that talk about process= ing DMARC policy is similarly implicit, rather than explicit.=C2=A0 The onl= y clear, explicit directive about DMARC outcomes seems to be Section 6.6.2 = #6, Apply policy.

An example of possible confusion in the case of ARC:=C2=A0 does DMARC still= 'fail'?=C2=A0 Yet the whole point of ARC is to create the possibil= ity of still getting delivered, in spite of this.

So, were one to write something to augment the DMARC spec, in support of AR= C, what are the kinds of text one ought to formulate and how should they be= linked to the DMARC spec?

d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

_______________________________________________
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


--001a11426cd22920180556d279f0-- From nobody Tue Aug 15 16:55:37 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9FAD1323AC for ; Tue, 15 Aug 2017 16:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fiction.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 dBFCHdcUmfCB for ; Tue, 15 Aug 2017 16:55:31 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61DCC13232D for ; Tue, 15 Aug 2017 16:55:31 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id y36so8526521uac.5 for ; Tue, 15 Aug 2017 16:55:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fiction.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=56rgi0dA3CiXDPJTRoVGFUO8GiHRzrwFWgpVyl6SAiA=; b=RHKa7XbbmJxYrX+kJ2yTEL90NfDXKE9HZSncenTx0iA4VMCA8qhXh3qgTX5QA9eq43 gltkh64ictyUYIu5qd8TTaNYzA98ZFU8v8VrU9LLEN7Rq6P2MKZsdRkQobPGA8mcROG2 bs7EKMQqAu5mzy9lw+AvYTfXZoBnsaY6F6DFcap8wJ7p9gT28n9ip/crcEk4oJgful4w SKhRNDPoRpLbKXUb6KICbKp8ShOCbEqt/MCQys6c5HBInoFeWgA744gndwcsWDkXNL6k VvfGf3VoxckgTyIk18B/tIp2TtPu8HLRWA+PkHq7LxmjmI4BH3AOI2Uxs/1FVSMSZZ0V op2A== 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=56rgi0dA3CiXDPJTRoVGFUO8GiHRzrwFWgpVyl6SAiA=; b=PIwJNtzRPyhOQeHhQY2bi6GnZjcGvwpk26B57TkNFYVrcAEKE0gEgwG2ORl9s0L5Lp KCmERGoEnJYh4g0QDwUjz5G3OK9agURwW5yxJ/RCsRevf3s4jOXysTKVNGmRMWR68qr7 fjFp7JFIXnRVdyBF77ZR+fhimpbBsmtH2yoCpu627KSq4ZQRmj0f1AV0/uoeBfXY6Qmo cX/XgK5N41tSt8z4/qvisVGF+kaKwW4UBWKahYRkd7eA7WgAuXp6VgHDThvD0svU17FC J7o/5jo0RKjMExph9n0XMiJ7QuDfUnPxmw+b3zZgLgUHWDFK5UmdilES17wuJmMNz6GR r07A== X-Gm-Message-State: AHYfb5hJIosbAgnUsbG22WuYCDJrB6Y3dZqOb7PXEaoxIGau6yBliy12 Sgu8qSRMI3x5c0nH3MyCOA== X-Received: by 10.176.88.66 with SMTP id p2mr21799257uac.181.1502841330311; Tue, 15 Aug 2017 16:55:30 -0700 (PDT) Received: from mail-vk0-f54.google.com (mail-vk0-f54.google.com. [209.85.213.54]) by smtp.gmail.com with ESMTPSA id x16sm2337080vke.37.2017.08.15.16.55.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Aug 2017 16:55:29 -0700 (PDT) Received: by mail-vk0-f54.google.com with SMTP id r199so7432184vke.4 for ; Tue, 15 Aug 2017 16:55:29 -0700 (PDT) X-Received: by 10.31.202.69 with SMTP id a66mr17649613vkg.66.1502841329181; Tue, 15 Aug 2017 16:55:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.135.139 with HTTP; Tue, 15 Aug 2017 16:55:28 -0700 (PDT) In-Reply-To: <1502762779.1086232.1073552432.22DE7E98@webmail.messagingengine.com> References: <1502762779.1086232.1073552432.22DE7E98@webmail.messagingengine.com> From: Brandon Long Date: Tue, 15 Aug 2017 16:55:28 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Bron Gondwana Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a114dd64a951b820556d383b8" Archived-At: Subject: Re: [dmarc-ietf] Prove me wrong! 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 Aug 2017 23:55:35 -0000 --001a114dd64a951b820556d383b8 Content-Type: text/plain; charset="UTF-8" Since AMS i=1 doesn't pass, the information included in Set 2 only says that site3 claims that site2 said that spf passed, whereas in Set 1, the AS allows you to verify that site2 actually claimed that spf passed. Now, since the i=1 AMS doesn't pass, it is true that the i=1 headers in both cases could have been either made out of whole cloth (in Set 2) or copied from an existing message (in Set 1). Your formulation also means that who asserted anything in i=1 is now missing. You could include information in the i=1 aar on who made the assertion (srv-id?) or not strip the broken AMS for i=1. Looking at my whitelist based local policy override code, it doesn't care about the seal, the seal is only used to verify the intact arc chain. So, assuming some changes to what you're saying, your handling of a single message is not different based on the two versions above. That is not the only utility of the arc chain, however. AS allows me to verify that what was asserted was asserted by the actual service, but not that that assertion applies to this message. The fact that it applies to this message is based on trusting the services which handled receipt, yes. But your version allows a malicious actor to invent the path the message went through. With AS, they have to copy an existing chain, without it they can just write whatever they want. This distinction becomes more important when using the information as training data for learning which paths to trust and which not to trust. The AS certainly contains more information there, but perhaps that more information is only useful for the largest actors, and then maybe only as some small percentage of decreased false positives or the ability to allow trust further down the long tail. Without sufficient data and implementation, it's hard to judge whether the utility of this extra information is useful. Brandon On Mon, Aug 14, 2017 at 7:06 PM, Bron Gondwana wrote: > Seth pointed out that my emails have been long and contained many points, > so I'd like to keep this really simple. > > I will propose two sets of headers on the same message, and I ask if > anybody can find a case where the set with AS headers provides some > information which is not present in the set without. Assume you are a > receiver at site5.com who just received this message on your MX and are > validating it. > > Set 1: > > AS: i=3; cv=pass; d=site4.com > AMS: i=3; d=site4.com > AAR: i=3; arc=pass (spf=fail spfdomain=site1.com dmarc=fail fromdomain= > site1.com) > AS; i=2; cv=pass; d=site3.com > AMS: i=2; d=site3.com > AAR i=2; arc=pass (spf=fail spfdomain=site1.com dmarc=pass fromdomain= > site1.com) > AS; i=1; cv=none; d=site2.com > AMS: i=1; d=site2.com > AAR i=1; arc=none (spf=pass spfdomain=site1.com dmarc=pass fromdomain= > site1.com) > DKIM-Signature: d=site1.com > From: > > Set 2: > > AMS: i=3; d=site4.com; h=aar:aar:aar:to:from:etc > AAR: i=3; arc=pass (arcdomain=site3.com spf=fail spfdomain=site1.com > dmarc=fail fromdomain=site1.com) > AMS: i=2; d=site3.com; h=aar:aar:to:from:etc > AAR: i=2; arc=pass (arcdomain=site2.com spf=fail spfdomain=site1.com > dmarc=pass fromdomain=site1.com) > AAR: i=1; arc=none (spf=pass spfdomain=site1.com dmarc=pass fromdomain= > site1.com) > DKIM-Signature: d=site1.com > From: > > In each case the AMS with i=2 and the AMS with i=3 are valid. > > I would love to see a case where Set 1 gives information that Set 2 > doesn't, because that would prove that my understanding was incorrect. > > Regards, > > Bron. > > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --001a114dd64a951b820556d383b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Since AMS i=3D1 doesn't pass, the information included= in Set 2 only says that site3 claims that site2 said that spf passed, wher= eas in Set 1, the AS allows you to verify that site2 actually claimed that = spf passed.

Now, since the i=3D1 AMS doesn't pass, i= t is true that the i=3D1 headers in both cases could have been either made = out of whole cloth (in Set 2) or copied from an existing message (in Set 1)= .

Your formulation also means that who asserted an= ything in i=3D1 is now missing.=C2=A0 You could include information in the = i=3D1 aar on who made the assertion (srv-id?) or not strip the broken AMS f= or i=3D1.

Looking at my whitelist based local= policy override code, it doesn't care about the seal, the seal is only= used to verify the intact arc chain.

So, as= suming some changes to what you're saying, your handling of a single me= ssage is not different based on the two versions above.

That is not the only utility of the arc chain, however.
AS allows me to verify that what was asserted was asserted by t= he actual service, but not that that assertion applies to this message.=C2= =A0 The fact that it applies to this message is based on trusting the servi= ces which handled receipt, yes.=C2=A0 But your version allows a malicious a= ctor to invent the path the message went through.=C2=A0 With AS, they have = to copy an existing chain, without it they can just write whatever they wan= t.

This distinction becomes more important when us= ing the information as training data for learning which paths to trust and = which not to trust.=C2=A0 The AS certainly contains more information there,= but perhaps that more information is only useful for the largest actors, a= nd then maybe only as some small percentage of decreased false positives or= the ability to allow trust further down the long tail.=C2=A0 Without suffi= cient data and implementation, it's hard to judge whether the utility o= f this extra information is useful.

Brandon
<= div>

On Mon, Aug 14, 2017 at 7:06 PM, Bron Gondwana <brong@fastmailteam= .com> wrote:
Seth pointed out that my emails have = been long and contained many points, so I'd like to keep this really si= mple.

I will propose two sets of headers on the = same message, and I ask if anybody can find a case where the set with AS he= aders provides some information which is not present in the set without.=C2= =A0 Assume you are a receiver at site5.com who just received this message on your MX and are valida= ting it.

Set 1:

AS: i=3D3; cv=3Dpass; d=3Dsite4.com
AMS: i=3D3; d=3Dsite4.com
AAR: i=3D3; arc=3Dpass (spf=3Dfail spfdoma= in=3Dsite1.com dmarc=3Df= ail fromdomain=3Dsite1.com)
AMS: i=3D2; d=3Dsite3.com
AAR i=3D2; arc=3Dpass (spf=3Dfail spfdomai= n=3Dsite1.com dmarc=3Dpa= ss fromdomain=3Dsite1.com)
AMS: i=3D1; d=3Dsite2.com
AAR i=3D1; arc=3Dnone (spf=3Dpass spfdomai= n=3Dsite1.com dmarc=3Dpa= ss fromdomain=3Dsite1.com)

Set 2:

AMS: i=3D3; d=3Dsite4.com; h=3Daar:aar:aar:to:from:etc
AAR: i=3D3; arc=3Dpass (arcdomain=3Dsite3.com spf=3Dfail spfdomain= =3Dsite1.com dmarc=3Dfai= l fromdomain=3Dsite1.com= )
AMS: i=3D2; d=3Dsite3.com; h=3Daar:aar:to:from:etc
AAR: i=3D2; arc=3Dpass (arcdomain=3Dsite2.com spf=3Dfail spfdomain= =3Dsite1.com dmarc=3Dpas= s fromdomain=3Dsite1.com= )
AAR: i=3D1; arc=3Dnone (spf=3Dpass spfdoma= in=3Dsite1.com dmarc=3Dp= ass fromdomain=3Dsite1.com)

In each case the AMS with i=3D2 and the AM= S with i=3D3 are valid.

I would love to see a case where Set 1 giv= es information that Set 2 doesn't, because that would prove that my und= erstanding was incorrect.

Regards,

Bron.

--
=C2=A0 Bron Gondwana, CEO, FastMail Pty Lt= d



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


--001a114dd64a951b820556d383b8-- From nobody Tue Aug 15 18:36:00 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 810161323AF for ; Tue, 15 Aug 2017 18:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=N1ZwdOUp; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=L74D35DK Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcZcoHni_tmK for ; Tue, 15 Aug 2017 18:35:42 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84593132399 for ; Tue, 15 Aug 2017 18:35:42 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id DFCB520F8A; Tue, 15 Aug 2017 21:35:41 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Tue, 15 Aug 2017 21:35:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=Ac1uja sFcMy2qG+J0NJ97IIu4iXA0yDdgzx+6VVyFzs=; b=N1ZwdOUpFPihZxSI2rT5tv tNfR8dJc6P2q3dtgFos4K686084lqLpkSaCIPb06RBMvQQQDXjrLrit9X/RiN7oN Rgb0A6rtlcwycxYFKHOxR+RK6Lk/VH5ixXd9XkJGNwwP45InxokCkodnwvN7Chh0 IVX9f8FiA8sEMe34iOwr3uR0w6xAg4RCYK2+lZVgSXeTR1yqnv8nZobevqtqa3oV RqZdV+lNglZiVXcHq+MEFYECL2B0i3SrOjDHscMESvCLPDzFfX7h8P212dPQpgI7 JGUI9O+ZceFpHy7RhprAyT/G0OpSY1zo6crEMdsD8Fub35rkcS6Yz5rb5YROirWg == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=Ac1uja sFcMy2qG+J0NJ97IIu4iXA0yDdgzx+6VVyFzs=; b=L74D35DKJdTt9vFlR3f9FV 3adBCkUS//j4lUF11Hfzo5cDMqmxPlRDVVv007QOLIRXjCdINwY5f6hT9Pzu0FMD /2Y4ejkyc/tes3ruOMKTD02uEORCs/sBHZ0DiQiGQoRg/nXs4Vq2TDsTPtkAV66I 5ejXFZZlJ+tMvj+UP6SN8xdF5AF797SUYZ1LAAHLj44DeAADjgb0/E1ElUXxbRXI 5yOJzbfzLNk1MVNM/oTgp0GA25JuJDJV2czhjgdpsgqvugKrm0fhx8V5TCXN27DF cxzHK161dsPJSPIVEmqHlh0fzvw4GRENvzWDfMgKOt1IxspzIRcl7Q9uLI6KBNUA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id B79DA9E270; Tue, 15 Aug 2017 21:35:41 -0400 (EDT) Message-Id: <1502847341.2162341.1074690552.30E822B4@webmail.messagingengine.com> From: Bron Gondwana To: Brandon Long Cc: dmarc@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150284734121623412" X-Mailer: MessagingEngine.com Webmail Interface - ajax-42cf1507 In-Reply-To: Date: Wed, 16 Aug 2017 11:35:41 +1000 References: <1502762779.1086232.1073552432.22DE7E98@webmail.messagingengine.com> Archived-At: Subject: Re: [dmarc-ietf] Prove me wrong! 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, 16 Aug 2017 01:35:46 -0000 This is a multi-part message in MIME format. --_----------=_150284734121623412 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Wed, 16 Aug 2017, at 09:55, Brandon Long wrote: > Since AMS i=1 doesn't pass, the information included in Set 2 only > says that site3 claims that site2 said that spf passed, whereas in > Set 1, the AS allows you to verify that site2 actually claimed that > spf passed. Yes, but that doesn't mean anything about this message, only that SPF passed for _a_ message. > Now, since the i=1 AMS doesn't pass, it is true that the i=1 headers > in both cases could have been either made out of whole cloth (in Set > 2) or copied from an existing message (in Set 1).> > Your formulation also means that who asserted anything in i=1 is now > missing. You could include information in the i=1 aar on who made the > assertion (srv-id?) or not strip the broken AMS for i=1.> > Looking at my whitelist based local policy override code, it > doesn't care about the seal, the seal is only used to verify the > intact arc chain.> > So, assuming some changes to what you're saying, your handling of a > single message is not different based on the two versions above.> > That is not the only utility of the arc chain, however. > > AS allows me to verify that what was asserted was asserted by the > actual service, but not that that assertion applies to this message. > The fact that it applies to this message is based on trusting the > services which handled receipt, yes. But your version allows a > malicious actor to invent the path the message went through. With AS, > they have to copy an existing chain, without it they can just write > whatever they want. Yes, everything BEFORE the last bad actor is entirely untrustworthy in set 2, it can be made out of whole cloth. In the set 1 example, you can tell that _a_ message went through that particular set of servers in that particular order, and they verified particular facts about the message (SPF, DKIM, etc). In my example the bad actor can fake more things about the path beforehand. So the question becomes - is there any value in knowing that mail flows along a particular path between services and that a theoretical bad actor can read that mail (or at least that headers from it)? > This distinction becomes more important when using the information as > training data for learning which paths to trust and which not to > trust. The AS certainly contains more information there, but perhaps > that more information is only useful for the largest actors, and then > maybe only as some small percentage of decreased false positives or > the ability to allow trust further down the long tail. Without > sufficient data and implementation, it's hard to judge whether the > utility of this extra information is useful. I will certainly agree that if you process a large fraction of the world's mail flow, you can ascertain things about a mail flow having been present (and if you have in index of every ARC-Seal that's flowing in the world, you can detect reuse!) I doubt even Google has quite that much ability to correlate the world's mail flow, particularly the bits that never go to a Google server. Maybe there are security agencies with this level of capability, but they're not going to want to tip their hand by helping us identify spam. Regardless, what you're getting here is a cryptographically verifiable log that an email (which may have never been intended for you in the first place) was passed between a set of services and then accessed by a bad actor. You can only tell that the bad actor listened at a particular spot OR LATER, because ARC doesn't protect against truncating. You can read the message at i=8 and truncate back to just the i=1 and i=2 headers then restart the chain yourself. There do exist cryptographic methods for making a non-truncatable chain - but that would require everyone to rewrite older headers at each step - and is not the design we have. If I was a bad actor, I'd probably subscribe to mailing lists or read public archives and slurp up ARC headers from there, then decide whether to truncate back or not. I guess a large enough actor (e.g. Google) could ALSO slurp public mailing lists and blacklist the ARC headers, but that makes it a big challenge for everybody else! I don't know if I like the idea of "Google can create a huge database of cryptographic proof that mail flowed from site X to site Y even if the original message wasn't intended for Google" as a spam prevention measure! In summary - tell me if I'm wrong, but what I'm getting as the difference is: Set 1: * the receiver (site5.com) can verify that an email (not necessarily this one) was sent from site1.com to site2.com. Set 2: * if site3.com is a bad actor, site5.com does not know that any email ever flowed between site1.com and site2.com, that "fact" could be faked as well. Is that it? That an email was sent from site1.com to site2.com? I don't think you can tell from ARC who the sender or recipient was on that email that went from site1.com to site2.com, so you know nothing other than that "an email existed that traveled this path". All you know from ARC-Seals is that there is AN EMAIL that started its life by following that path, and somebody could read it and inject the headers from it to an email generated at site3.com. Since site3.com is "bad", it can falsify all the mail flow after site2.com added its ARC headers, and it can falsify it on any email that followed a different path out of site2 originally. So we don't even know that site2.com sends any email on to site3.com. Just that if site2.com isn't bad, then it receives email from site1.com. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_150284734121623412 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Wed, 16 Aug 2017, at 09:55, Brandon Long wrote:
Since AMS i=1 doesn't pass, the information included in Set 2 only says that site3 claims that site2 said that spf passed, whereas in Set 1, the AS allows you to verify that site2 actually claimed that spf passed.

Yes, but that doesn't mean anything about this message, only that SPF passed for _a_ message.

Now, since the i=1 AMS doesn't pass, it is true that the i=1 headers in both cases could have been either made out of whole cloth (in Set 2) or copied from an existing message (in Set 1).

Your formulation also means that who asserted anything in i=1 is now missing.  You could include information in the i=1 aar on who made the assertion (srv-id?) or not strip the broken AMS for i=1.

Looking at my whitelist based local policy override code, it doesn't care about the seal, the seal is only used to verify the intact arc chain.

So, assuming some changes to what you're saying, your handling of a single message is not different based on the two versions above.

That is not the only utility of the arc chain, however.

AS allows me to verify that what was asserted was asserted by the actual service, but not that that assertion applies to this message.  The fact that it applies to this message is based on trusting the services which handled receipt, yes.  But your version allows a malicious actor to invent the path the message went through.  With AS, they have to copy an existing chain, without it they can just write whatever they want.

Yes, everything BEFORE the last bad actor is entirely untrustworthy in set 2, it can be made out of whole cloth.

In the set 1 example, you can tell that _a_ message went through that particular set of servers in that particular order, and they verified particular facts about the message (SPF, DKIM, etc).  In my example the bad actor can fake more things about the path beforehand.

So the question becomes - is there any value in knowing that mail flows along a particular path between services and that a theoretical bad actor can read that mail (or at least that headers from it)?

This distinction becomes more important when using the information as training data for learning which paths to trust and which not to trust.  The AS certainly contains more information there, but perhaps that more information is only useful for the largest actors, and then maybe only as some small percentage of decreased false positives or the ability to allow trust further down the long tail.  Without sufficient data and implementation, it's hard to judge whether the utility of this extra information is useful.

I will certainly agree that if you process a large fraction of the world's mail flow, you can ascertain things about a mail flow having been present (and if you have in index of every ARC-Seal that's flowing in the world, you can detect reuse!)

I doubt even Google has quite that much ability to correlate the world's mail flow, particularly the bits that never go to a Google server.  Maybe there are security agencies with this level of capability, but they're not going to want to tip their hand by helping us identify spam.

Regardless, what you're getting here is a cryptographically verifiable log that an email (which may have never been intended for you in the first place) was passed between a set of services and then accessed by a bad actor.  You can only tell that the bad actor listened at a particular spot OR LATER, because ARC doesn't protect against truncating.  You can read the message at i=8 and truncate back to just the i=1 and i=2 headers then restart the chain yourself.

There do exist cryptographic methods for making a non-truncatable chain - but that would require everyone to rewrite older headers at each step - and is not the design we have.

If I was a bad actor, I'd probably subscribe to mailing lists or read public archives and slurp up ARC headers from there, then decide whether to truncate back or not.  I guess a large enough actor (e.g. Google) could ALSO slurp public mailing lists and blacklist the ARC headers, but that makes it a big challenge for everybody else!

I don't know if I like the idea of "Google can create a huge database of cryptographic proof that mail flowed from site X to site Y even if the original message wasn't intended for Google" as a spam prevention measure!

In summary - tell me if I'm wrong, but what I'm getting as the difference is:

Set 1:
* the receiver (site5.com) can verify that an email (not necessarily this one) was sent from site1.com to site2.com.

Set 2:
* if site3.com is a bad actor, site5.com does not know that any email ever flowed between site1.com and site2.com, that "fact" could be faked as well.

Is that it?  That an email was sent from site1.com to site2.com?  I don't think you can tell from ARC who the sender or recipient was on that email that went from site1.com to site2.com, so you know nothing other than that "an email existed that traveled this path".

All you know from ARC-Seals is that there is AN EMAIL that started its life by following that path, and somebody could read it and inject the headers from it to an email generated at site3.com.

Since site3.com is "bad", it can falsify all the mail flow after site2.com added its ARC headers, and it can falsify it on any email that followed a different path out of site2 originally.  So we don't even know that site2.com sends any email on to site3.com.  Just that if site2.com isn't bad, then it receives email from site1.com.

Bron.

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


--_----------=_150284734121623412-- From nobody Wed Aug 16 10:46:42 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6A6D13218F for ; Wed, 16 Aug 2017 10:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=EqheXwkx; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=fBlR5mva Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2yuR8vr3YTe for ; Wed, 16 Aug 2017 10:46:39 -0700 (PDT) Received: from ftp.catinthebox.net (news.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id CB82F132357 for ; Wed, 16 Aug 2017 10:46:38 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=723; t=1502905596; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=5p9jr642y3DDvmhGARXpnGhAUgs=; b=EqheXwkxAJOnujYz7Yro9q1Q49Gfx2790SylN+1VXoF1SGIxAZ6FggebB5Mdpn S/zYLI6pPlZrQvIVlJ714WC/3YyFrhLIYGw2MOH+FNXu8eIdDAbBF0gHKjHJL4vD IG5S4KvtagdnzgwS/Q6zZ2qlJ/J6h+jmOrgFDZwPLVGMo= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Wed, 16 Aug 2017 13:46:36 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 2969452191.1.4540; Wed, 16 Aug 2017 13:46:35 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=723; t=1502905557; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=x51+hpl cW1WRzB3LHSQnJ6KghHIVT56sx0FC7BSXu60=; b=fBlR5mva17AFnRbIozazngZ sNggRstPxTihQaFf/ps+lR1rZBSXyPA+2v9/JHjOOldnoNb0QhprfG0hTbtZFDqP DY/85yXoq0JZTVKjiE+L/vK8qDMsT76OxUBH7OxAXjogS+JkO4hkYOb4BeWdyloB I23Mxq94yKeYsVV/t2Bc= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Wed, 16 Aug 2017 13:45:56 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 3511953643.9.490764; Wed, 16 Aug 2017 13:45:55 -0400 Message-ID: <599484FB.9050908@isdg.net> Date: Wed, 16 Aug 2017 13:46:35 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> <166070f0-4ba1-70da-1f73-885b4a7f7640@gmail.com> <1502497178.4103451.1070917304.23DD466D@webmail.messagingengine.com> <598F9484.7020700@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre 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, 16 Aug 2017 17:46:42 -0000 On 8/13/2017 10:28 AM, Kurt Andersen (b) wrote: > On Sat, Aug 12, 2017 at 4:51 PM, Hector Santos wrote: > > If we even have a DMARC ARC Policy concept, than that may be > enough to begin pursuing the high cost of experimentation and > development here. > > > Beyond the protocol and usage specs, what are you looking for? > A practical purpose for supporting (implementing) this work. It appears ARC wants the network to stamp mail "blindly" as the mail travels from point to point. I am trying to grasp how it helps resolve the main issue with "unauthorized" indirect 3rd party signatures, in particular when dealing with strong, exclusive DKIM signature policy models such as DMARC p=reject. -- HLS From nobody Wed Aug 16 17:21:48 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C186C13217D for ; Wed, 16 Aug 2017 17:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=CMSmE0zT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=e5thQFbQ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFufV7SmYOla for ; Wed, 16 Aug 2017 17:21:45 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97087132431 for ; Wed, 16 Aug 2017 17:21:44 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 0FFAC2176A for ; Wed, 16 Aug 2017 20:21:44 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Wed, 16 Aug 2017 20:21:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=pwavbC0jUdJ1urbIp /mDcTqPsEILcNc/CjEeiCPpqeo=; b=CMSmE0zTGpeNoKa9/GztIDUHTDqPLf7Yz +U3ZeS4wpN3N4EMUYE2FHlbuDjhSvrKsY1pxEZ+p+I+fb8S5VWNrtFQW6ID080Dy ncKA7duvA/amMlj0MBhqgTzzYwZLDmG/eYo3O/Li2iZQhuuEYbbt7yrvwnam1va4 h9bpC0hWS+WcuawbrWqpjngYKShcEnmJvyYgMVjVZ4qQZ2+uIpMM01G4NavUnKKY l9ElUrUPBffg6ax0xE90tD+hg6FbvbPgZ6fInh2z4TpJa+Vv7+M1mJO3D6EujUey QPP10KvOVqVl7Q2eTYuizSa03Ezj1LR/kidh/ns07TIzoe6xszYbw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=pwavbC 0jUdJ1urbIp/mDcTqPsEILcNc/CjEeiCPpqeo=; b=e5thQFbQuNuUOIup4cepsz /lRjTQYo36AirK/AOJxI3vvx4EJoOgi/01z1cxortWlL0iUktffBvO7k8NHrLzlF wOuA64AhYmBXWcxpOHdWxWRJ/1Q9B7NGtpbm18aGulJrJrah+NmZmWMWXsH7KzBn ar3e2WwRX4hmrvsycwEaLsEyOVASpAIEdeoJqb3Q0b061oJ8ky2WzINyVjjcxSfM X91VRF+ry/0Yc9fQPJ5Aa1AfZJNwGgCMy3ck4+Xhxqgsh9mHGWTX2gLBQORM4dvU S9kPzTQgooRY1k3R08xJyWaULKWInyz4PGQp3QGi2K80BppTtLkLCt9CkkY77FSw == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id DD1C39E2B5; Wed, 16 Aug 2017 20:21:43 -0400 (EDT) Message-Id: <1502929303.4038704.1075868960.5D80A788@webmail.messagingengine.com> From: Bron Gondwana To: dmarc@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150292930340387040" X-Mailer: MessagingEngine.com Webmail Interface - ajax-42cf1507 References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> <166070f0-4ba1-70da-1f73-885b4a7f7640@gmail.com> <1502497178.4103451.1070917304.23DD466D@webmail.messagingengine.com> <598F9484.7020700@isdg.net> <599484FB.9050908@isdg.net> Date: Thu, 17 Aug 2017 10:21:43 +1000 In-Reply-To: <599484FB.9050908@isdg.net> Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 00:21:47 -0000 This is a multi-part message in MIME format. --_----------=_150292930340387040 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Thu, 17 Aug 2017, at 03:46, Hector Santos wrote: > On 8/13/2017 10:28 AM, Kurt Andersen (b) wrote: >> On Sat, Aug 12, 2017 at 4:51 PM, Hector Santos wrote: >> >> If we even have a DMARC ARC Policy concept, than that may be >> enough to begin pursuing the high cost of experimentation and >> development here. >> >> >> Beyond the protocol and usage specs, what are you looking for? >> > > A practical purpose for supporting (implementing) this work. It > appears ARC wants the network to stamp mail "blindly" as the mail > travels from point to point. I am trying to grasp how it helps > resolve the main issue with "unauthorized" indirect 3rd party > signatures, in particular when dealing with strong, exclusive DKIM > signature policy models such as DMARC p=reject. We spent a while thinking about this (Neil and myself from FastMail) at IETF99 after learning how ARC works, and came to the conclusion that ARC as specified can't help with DMARC p=reject. The only way you could even hope (as a mailing list) to avoid rewriting the sender is for every site that currently has DMARC p=reject to change that to a new policy which explicitly means "only reject if no ARC chain" - otherwise you can't stop rewriting sender until you know that every receiver on your list is ARC-aware. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_150292930340387040 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Thu, 17 Aug 2017, at 03:46, Hector Santos wrote:
On 8/13/2017 10:28 AM, Kurt Andersen (b) wrote:
On Sat, Aug 12, 2017 at 4:51 PM, Hector Santos wrote:

  If we even have a DMARC ARC Policy concept, than that may be
  enough to begin pursuing the high cost of experimentation and
  development here.


Beyond the protocol and usage specs, what are you looking for?


A practical purpose for supporting (implementing) this work.   It
appears ARC wants the network to stamp mail "blindly" as the mail
travels from point to point.  I am trying to grasp how it helps
resolve the main issue with "unauthorized" indirect 3rd party
signatures, in particular when dealing with strong, exclusive DKIM
signature policy models such as DMARC p=reject.

We spent a while thinking about this (Neil and myself from FastMail) at IETF99 after learning how ARC works, and came to the conclusion that ARC as specified can't help with DMARC p=reject.

The only way you could even hope (as a mailing list) to avoid rewriting the sender is for every site that currently has DMARC p=reject to change that to a new policy which explicitly means "only reject if no ARC chain" - otherwise you can't stop rewriting sender until you know that every receiver on your list is ARC-aware.

Bron.

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


--_----------=_150292930340387040-- From nobody Wed Aug 16 17:34:42 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E47313217D for ; Wed, 16 Aug 2017 17:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PduktafpbfW for ; Wed, 16 Aug 2017 17:34:34 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FE22132143 for ; Wed, 16 Aug 2017 17:34:34 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id u133so17607489vke.3 for ; Wed, 16 Aug 2017 17:34:34 -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=kf3KOtiGPSjvqocBXibtZrm2ltfsVXcFULTCrU2AalQ=; b=1hupoj54A7oejXgWbP6I4RLYk5bBRzDBetyeEM4j49KIbZI7gR+GAYUaTyq4nNYI7I VUilB+vaoNjhc1jUotJhYhEB8/2oefC7rdYAILTlsKe15eXjVOvIomQf/YQT/8Dd9ZuO 0V4DgWzz9iffPd9s3zr0MwWI7Gd3LCu31ZajZ959LdcS1Ot/7DBY+mxJiJDhHJSaiZw/ qyd7f7H7+aQvYg7vlks68mUW55dwbLpbgXkDFw0sNtozewvu6RtYINiAu9Hsgt36nPDK ESoqDJqRkPuIz58ZWYX2F/2fvDrpcUWCYGSr2zDd2YYb54IfZ8V58eZZUCKAsdVa+Qho aSLg== 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=kf3KOtiGPSjvqocBXibtZrm2ltfsVXcFULTCrU2AalQ=; b=SiXMqiQzEXCdpHis2npfeg3edc+ZpSta8F2HvNwxRo7lYNPjyfQrmXDy5HjKDn53rP DnSkO/UzZu6gkTFbp0XVUUSgHNVdet8MwQXZZy1X47EY8bcuEoFeUMporEZQmiaPGvTI 0gk1/zqUQSkz6pABAPTh2nJsO/MrPzdQVDGfQM+fBU6mDJvx7n7gAbS+aLzISU4ogPi2 4LhKb3b3XoZW7i61OJCnA6l90mw8EFrGkWBbg8QTLVHNFEX0DnYoWohnK+i4w1XXoSEr uWBxDecFMWaApdMJFWOGvxBSr8uZClSVv4Vdl4rAeTUYMmhM3beGvzw78T5NUrCe8Hwx rSag== X-Gm-Message-State: AHYfb5iBRlcOQdN4Gr/uyrp6+7emFNBnFBmC/UjoCHglFKaIT8U3YDx4 v9zYfg/7mKtpxu7RlkUJRwk+gpx+NO3D8BckxQ== X-Received: by 10.31.133.130 with SMTP id h124mr2247574vkd.14.1502930072372; Wed, 16 Aug 2017 17:34:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.89.22 with HTTP; Wed, 16 Aug 2017 17:34:11 -0700 (PDT) In-Reply-To: <1502929303.4038704.1075868960.5D80A788@webmail.messagingengine.com> References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> <166070f0-4ba1-70da-1f73-885b4a7f7640@gmail.com> <1502497178.4103451.1070917304.23DD466D@webmail.messagingengine.com> <598F9484.7020700@isdg.net> <599484FB.9050908@isdg.net> <1502929303.4038704.1075868960.5D80A788@webmail.messagingengine.com> From: Seth Blank Date: Wed, 16 Aug 2017 17:34:11 -0700 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="001a11440e101623a80556e82d8a" Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 00:34:37 -0000 --001a11440e101623a80556e82d8a Content-Type: text/plain; charset="UTF-8" On Wed, Aug 16, 2017 at 5:21 PM, Bron Gondwana wrote: > > The only way you could even hope (as a mailing list) to avoid rewriting > the sender is for every site that currently has DMARC p=reject to change > that to a new policy which explicitly means "only reject if no ARC chain" - > otherwise you can't stop rewriting sender until you know that every > receiver on your list is ARC-aware. > I don't understand your point. The only way DKIM works is if enough receivers validate it. The only way adding elliptic curve to DKIM works is if enough receivers validate it. The only way a DMARC policy works is if enough receivers validate it. ARC is the explicit solution to mailing list breakage with DMARC. But, as with all other IETF RFCs, only works if enough receivers validate it. Our job is to make sure ARC accomplishes its goals under the DMARC charter, and demonstrate value to receivers that it's worthwhile to implement. There will always be a ramp up and implementation phase, that is a feature, not a bug, and not a reason to say "it won't work." Seth --001a11440e101623a80556e82d8a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Aug 16, 2017 at 5:21 PM, Bron Gondwana <brong@fastmailteam.com> wrote:
The only way you could even hope (as a mai= ling list) to avoid rewriting the sender is for every site that currently h= as DMARC p=3Dreject to change that to a new policy which explicitly means &= quot;only reject if no ARC chain" - otherwise you can't stop rewri= ting sender until you know that every receiver on your list is ARC-aware.

I don't understand your poin= t.

The only way DKIM works is if enough receivers = validate it.

The only way adding elliptic cur= ve to DKIM works is if enough receivers validate it.

The only way a DMARC policy works is if enough receivers validate = it.

ARC is the explicit solution to mailing list b= reakage with DMARC. But, as with all other IETF RFCs, only works if enough = receivers validate it.

Our job is to make sure ARC= accomplishes its goals under the DMARC charter, and demonstrate value to r= eceivers that it's worthwhile to implement.

Th= ere will always be a ramp up and implementation phase, that is a feature, n= ot a bug, and not a reason to say "it won't work."
=
Seth

--001a11440e101623a80556e82d8a-- From nobody Wed Aug 16 17:47:42 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1EC313239E for ; Wed, 16 Aug 2017 17:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=F9IiPZRp; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ca7pOyBu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKRBcIemKjVI for ; Wed, 16 Aug 2017 17:47:39 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1533D132386 for ; Wed, 16 Aug 2017 17:47:39 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 7E10E21236 for ; Wed, 16 Aug 2017 20:47:38 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Wed, 16 Aug 2017 20:47:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=B+6VDPHxLa07LOMLt Q2Lg+hdubQy5viqDjXHBPKdLhY=; b=F9IiPZRplRrSjnl8C+YKvnfr2U7cqbWKH h5Uex0XZlUgbPAe7+8ZJBQwnDOXUEInWO1iAbNk7YB/RP7GF1v5q8G30dM/G2qaS W4euOTX67AHunsBW9u2V6whitwiRGhMzZEJNlFDQLE0lDP52RJZ8be3uzV5SiByd v8BqhdCpsIu2P1sgTnbcrj/QhuHW9lpj408vnzyS6DM/6R7GRSn1i+Sj1ig/90YT uzSXyNq9bAaT0Z3ncLDQDsTnoOYIfOJ3V/VEO1Vse7xmUV8/TkyW62CUrBe+Qr9N kb8BjkqjbOzOCZBd/Q0C0AaI/JiwHbg/Rm2tTJiJk+sxh4aXLYWCA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=B+6VDP HxLa07LOMLtQ2Lg+hdubQy5viqDjXHBPKdLhY=; b=ca7pOyBuGNy2SwYjMQ57FT jMDXwJSSaImG6Cz3KF+9SiH7xa6YRZApUg39Fubg3cmGmMTqBftdHudaD1XKhkt6 h1gtDB+l1v72nug79EZOunQ2fWQ7duYxHL2D3Zx9Be9NRmLCJKluBwLY7v80EtLa ygxU75IMgQLLW5pqPlxXbPnn7f/pPL6Ak9VVuil4fgeHy/mUaYD+M1LjoM7FrG4v 6ArRWXGVvdPcDr+K1E5svkCdjxL1nU8hYBAWGEyFnYzyZXzc4QwlFhTVQ1wO+D2C lx3ohFgSnR69+6zCeeswNT6BrvBZ8NAXJrjAxmBbaSgbSlfuwF0lq4SuiqGhlpvw == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 4BDCB9E2B5; Wed, 16 Aug 2017 20:47:38 -0400 (EDT) Message-Id: <1502930858.4042926.1075890568.5069945B@webmail.messagingengine.com> From: Bron Gondwana To: dmarc@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150293085840429260" X-Mailer: MessagingEngine.com Webmail Interface - ajax-42cf1507 In-Reply-To: Date: Thu, 17 Aug 2017 10:47:38 +1000 References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> <166070f0-4ba1-70da-1f73-885b4a7f7640@gmail.com> <1502497178.4103451.1070917304.23DD466D@webmail.messagingengine.com> <598F9484.7020700@isdg.net> <599484FB.9050908@isdg.net> <1502929303.4038704.1075868960.5D80A788@webmail.messagingengine.com> Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 00:47:41 -0000 This is a multi-part message in MIME format. --_----------=_150293085840429260 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Thu, 17 Aug 2017, at 10:34, Seth Blank wrote: > On Wed, Aug 16, 2017 at 5:21 PM, Bron Gondwana > wrote:>> The only way you could even hope (as a mailing list) to avoid >> rewriting the sender is for every site that currently has DMARC >> p=reject to change that to a new policy which explicitly means "only >> reject if no ARC chain" - otherwise you can't stop rewriting sender >> until you know that every receiver on your list is ARC-aware.> > I don't understand your point. If you are a mailing list and you receive a message from a domain with DMARC p=reject, you can't send that message on to the members of your list without rewriting the sender. > The only way DKIM works is if enough receivers validate it. > > The only way adding elliptic curve to DKIM works is if enough > receivers validate it.> > The only way a DMARC policy works is if enough receivers validate it.> > ARC is the explicit solution to mailing list breakage with DMARC. > But, as with all other IETF RFCs, only works if enough receivers > validate it.> > Our job is to make sure ARC accomplishes its goals under the DMARC > charter, and demonstrate value to receivers that it's worthwhile to > implement.> > There will always be a ramp up and implementation phase, that is a > feature, not a bug, and not a reason to say "it won't work." While there exists A SINGLE SITE which is ARC-unaware and DMARC p=reject aware, you can't use ARC on a DMARC p=reject domain without rewriting the sender. Otherwise that site will bounce the email. You still have to rewrite the sender until there is either full adoption or sufficient adoption that you just don't care about the stragglers. ARC doesn't solve that unless every receiver is either ARC-aware or DMARC- unaware. Hence the suggestion that I think Hector is making - to define a new policy p=rejectnonarc or something, which means that sites which are ARC-unaware accept rather than reject. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_150293085840429260 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Thu, 17 Aug 2017, at 10:34, Seth Blank wrote:
The only way you could even hope (as a mailing list) to avoid rewriting the sender is for every site that currently has DMARC p=reject to change that to a new policy which explicitly means "only reject if no ARC chain" - otherwise you can't stop rewriting sender until you know that every receiver on your list is ARC-aware.

I don't understand your point.

If you are a mailing list and you receive a message from a domain with DMARC p=reject, you can't send that message on to the members of your list without rewriting the sender.

The only way DKIM works is if enough receivers validate it.

The only way adding elliptic curve to DKIM works is if enough receivers validate it.

The only way a DMARC policy works is if enough receivers validate it.

ARC is the explicit solution to mailing list breakage with DMARC. But, as with all other IETF RFCs, only works if enough receivers validate it.

Our job is to make sure ARC accomplishes its goals under the DMARC charter, and demonstrate value to receivers that it's worthwhile to implement.

There will always be a ramp up and implementation phase, that is a feature, not a bug, and not a reason to say "it won't work."

While there exists A SINGLE SITE which is ARC-unaware and DMARC p=reject aware, you can't use ARC on a DMARC p=reject domain without rewriting the sender.  Otherwise that site will bounce the email.

You still have to rewrite the sender until there is either full adoption or sufficient adoption that you just don't care about the stragglers.

ARC doesn't solve that unless every receiver is either ARC-aware or DMARC-unaware.  Hence the suggestion that I think Hector is making - to define a new policy p=rejectnonarc or something, which means that sites which are ARC-unaware accept rather than reject.

Bron.


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


--_----------=_150293085840429260-- From nobody Wed Aug 16 18:33:16 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2FE7132391 for ; Wed, 16 Aug 2017 18:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 aKAVchWV2viq for ; Wed, 16 Aug 2017 18:33:12 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83D1A13226B for ; Wed, 16 Aug 2017 18:33:12 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id r199so17936130vke.4 for ; Wed, 16 Aug 2017 18:33:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=VXg++ur8eJ1jiEWQu8XzzxcWY/C+z8vcz8KxoTd8Gqs=; b=YBovG6GWv1CJAFczCIHZszrBVW6ukm7nIBFOJaaDdek11LaG1z1s3UhYhnR2Psr+BQ uqe7/dt5eE94IxiC2GbxYhzqjlEUjXIt+AgVOs6dXW5kRdnH0KQl/0+Lg9Q9/3cLyT2Y OCqOCTKfIfmCpwlgEbc9AP6rz+PADgK84wVzd7gwFbwifL45+zBXBq17Z9Dkq1kW6HUu JNVmUWU3e7UPii2ADmLeH0vNDsJeGQK0D3QQUA11Eizw2EKxnw+tCafLbiDpj97yYt7x SIrnXwdu8XKR+mmMCm8fAlWX7sk+eLJNbwhp4+qkkQCw9JVE8HnNyBaDsPFPZkkh6x6r 0dTg== 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=VXg++ur8eJ1jiEWQu8XzzxcWY/C+z8vcz8KxoTd8Gqs=; b=M4q9+hky/siczO1KsDDBsdXZjnUD5FFeyC5oBSXkEhsxsSs/E1tB5fEIAQnbwIFrHc ceVE/xqP9WI+MTqTXk9CxYuhHCn4Kt913HlJYxY8vf/otViC0L6sJn4N8J0sAgbN2MVF wDSolgucjT/GLnIgTORSi3VsvgQRY4fEDfpNbU2PqyHIrtWH7+qOWyYC5CqHz5sTm4dh Wi/2cByCYY0t6Bw4FP6URZL56LJcwNcjYSRph0dDYnI/WMlXy8ic5WKP9IcAhhrVKj72 PiEjYWw8ExmoGrwLHXzQvU+WT/i4ufYsQ4Qoo0pw+idwz61bnlAcopGWxijM5EKarTxN Qz0A== X-Gm-Message-State: AHYfb5jnDd8fiA0ouvdOtQXW8wHX/Gv62FVLm7bYvFdPYi5W5MRkKvmU Nd/Js5Z+Iw4sO4jbBrH0wiB66AtN8yfUlIs= X-Received: by 10.31.98.65 with SMTP id w62mr2288619vkb.160.1502933591309; Wed, 16 Aug 2017 18:33:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.89.22 with HTTP; Wed, 16 Aug 2017 18:32:50 -0700 (PDT) In-Reply-To: <1502930858.4042926.1075890568.5069945B@webmail.messagingengine.com> References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> <166070f0-4ba1-70da-1f73-885b4a7f7640@gmail.com> <1502497178.4103451.1070917304.23DD466D@webmail.messagingengine.com> <598F9484.7020700@isdg.net> <599484FB.9050908@isdg.net> <1502929303.4038704.1075868960.5D80A788@webmail.messagingengine.com> <1502930858.4042926.1075890568.5069945B@webmail.messagingengine.com> From: Seth Blank Date: Wed, 16 Aug 2017 18:32:50 -0700 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="94eb2c095a36d4dbd70556e8fe8a" Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 01:33:15 -0000 --94eb2c095a36d4dbd70556e8fe8a Content-Type: text/plain; charset="UTF-8" On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana wrote: > > While there exists A SINGLE SITE which is ARC-unaware and DMARC p=reject > aware, you can't use ARC on a DMARC p=reject domain without rewriting the > sender. Otherwise that site will bounce the email. > > You still have to rewrite the sender until there is either full adoption > or sufficient adoption that you just don't care about the stragglers. > > ARC doesn't solve that unless every receiver is either ARC-aware or > DMARC-unaware. Hence the suggestion that I think Hector is making - to > define a new policy p=rejectnonarc or something, which means that sites > which are ARC-unaware accept rather than reject. > So this is an excellent and crucial point that has been discussed again and again on and off this list. ARC only works if critical mass can be reached - both of intermediaries who break DKIM and receivers who evaluate ARC. Fundamentally, ARC will never reach critical mass if senders now also need to enter into the equation with an additional flag on their DMARC record. This is too high a bar and increases the interoperability problems as opposed to reducing them. For now, there is a clear unanswered question: what coverage of receivers is needed for most mailing lists to achieve stable delivery once ARC is in the mix? Knowing the landscape of receiving domains, I believe this to be a small number. From the above comments, I'm guessing you think this is a large number. We're not going to resolve this difference of opinion in an open forum. However, releasing ARC as an experiment into the wild for major lists like the IETF and M3AAWG will give us very clear data very quickly on what the actual landscape looks like, and what ARC does and does not solve. In its current form, ARC only helps mail flows, it does not harm them. How effective this improvement is remains to be seen, but preliminary information I've been hearing about (which could be totally wrong) makes it seem like the improvements are dramatic. So let's get ARC tied off as an Experiment (thank you, Dave Crocker), collect some data, and see where things stand. Maybe things are great and ARC can move to proposed standard. Maybe it fundamentally needs more receivers in the mix than currently expected, and some fix for that is needed. But we'll know that after the experiment has begun, not before. --94eb2c095a36d4dbd70556e8fe8a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Aug 16, 2017 at 5:47 PM, Bron Gondwana <brong@fastmailteam.com> wrote:
While there exists A SINGLE SITE which is ARC-unaware and DMAR= C p=3Dreject aware, you can't use ARC on a DMARC p=3Dreject domain with= out rewriting the sender.=C2=A0 Otherwise that site will bounce the email.<= br>

You still have to rewrite the sender until= there is either full adoption or sufficient adoption that you just don'= ;t care about the stragglers.

ARC doesn't solve that unless every re= ceiver is either ARC-aware or DMARC-unaware.=C2=A0 Hence the suggestion tha= t I think Hector is making - to define a new policy p=3Drejectnonarc or som= ething, which means that sites which are ARC-unaware accept rather than rej= ect.

So this is an excellent an= d crucial point that has been discussed again and again on and off this lis= t.

ARC only works if critical mass can be reached = - both of intermediaries who break DKIM and receivers who evaluate ARC.

Fundamentally, ARC will never reach critical mass if = senders now also need to enter into the equation with an additional flag on= their DMARC record. This is too high a bar and increases the interoperabil= ity problems as opposed to reducing them.

For now, there is a clear unanswered question: what covera= ge of receivers is needed for most mailing lists to achieve stable delivery= once ARC is in the mix? Knowing the landscape of receiving domains, I beli= eve this to be a small number. From the above comments, I'm guessing yo= u think this is a large number. We're not going to resolve this differe= nce of opinion in an open forum. However, releasing ARC as an experiment in= to the wild for major lists like the IETF and M3AAWG will give us very clea= r data very quickly on what the actual landscape looks like, and what ARC d= oes and does not solve.

--94eb2c095a36d4dbd70556e8fe8a-- From nobody Wed Aug 16 18:48:07 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58BA9132416 for ; Wed, 16 Aug 2017 18:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=HUhR+ezm; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jnwqkfxg Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e13UyAghQCFa for ; Wed, 16 Aug 2017 18:47:59 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3755C13241A for ; Wed, 16 Aug 2017 18:47:59 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id A7BDA20BE9 for ; Wed, 16 Aug 2017 21:47:58 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Wed, 16 Aug 2017 21:47:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=JtCOLB9jtuLiuoIDh viLe7xyZkB63KiDrc2W2mAw3Jw=; b=HUhR+ezmZ3WlS+Zz7/xa+zHew1yj/9j/x wHmY0lXUff4ySHm0u1tialp6bLoJQE/kMJSMak5h8G9XoSJoVZx6MdKb3vG3dRfr DBBwNZN3mMC7u0Z+sFQg/mj3kJmh1U23RsugybP1wEcMgAJt9X2ruXR7RJV3K5rE xWNqTyPA9yd2YaMM3FwxUuRCgEEI/NptSvERg/v0AmHuMxpKkO+dxiaPd2OziK1E IwJjb+eEWEOEFYX9WVCBtZCPvu2Nwspa8Gya+LqZyLxLisIpwmIcBisLcgILVxyg QRMX+/dtdW/RSRopvwG/7UuLxoxIQN+pItxTWz08KQVSFT+tDYcDQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=JtCOLB 9jtuLiuoIDhviLe7xyZkB63KiDrc2W2mAw3Jw=; b=jnwqkfxgHYmUb1epybsL4j AmByH5bGA8mtSgTbV7Xt5F1tDFHtSsFjLjXKvYFuU/leC+eA8QfzrQAXtJy+n/jH 7hvScbDbpN/WQcg9u3aa0sCyCtLYL6gxM3rSS0amEVkaoCDuYYN6dq02vMgYBoRg DHXDG5ORsjg7N6jZRFU/kPsfrn1XWTCeO7oI4Df5hsLNuFSNM+0PecX4QBNePvuk BwmexfXqDHkMdoSQCb142V5I4oTb20TY/iU7waPfapvLLW+3jWmeUmC/sbgY1zUa ZFCIyqXrEgM3e4KldJljcFg9ejpihohpDJ+/zmG5PTI0kbgOuocJso5r8GFBfENg == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 80CBA9E2B5; Wed, 16 Aug 2017 21:47:58 -0400 (EDT) Message-Id: <1502934478.4053636.1075936440.4863007F@webmail.messagingengine.com> From: Bron Gondwana To: dmarc@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150293447840536360" X-Mailer: MessagingEngine.com Webmail Interface - ajax-42cf1507 In-Reply-To: Date: Thu, 17 Aug 2017 11:47:58 +1000 References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> <166070f0-4ba1-70da-1f73-885b4a7f7640@gmail.com> <1502497178.4103451.1070917304.23DD466D@webmail.messagingengine.com> <598F9484.7020700@isdg.net> <599484FB.9050908@isdg.net> <1502929303.4038704.1075868960.5D80A788@webmail.messagingengine.com> <1502930858.4042926.1075890568.5069945B@webmail.messagingengine.com> Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 01:48:05 -0000 This is a multi-part message in MIME format. --_----------=_150293447840536360 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Thu, 17 Aug 2017, at 11:32, Seth Blank wrote: > On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana > wrote:>> While there exists A SINGLE SITE which is ARC-unaware and DMARC >> p=reject aware, you can't use ARC on a DMARC p=reject domain without >> rewriting the sender. Otherwise that site will bounce the email.>> >> You still have to rewrite the sender until there is either full >> adoption or sufficient adoption that you just don't care about the >> stragglers.>> >> ARC doesn't solve that unless every receiver is either ARC-aware or >> DMARC-unaware. Hence the suggestion that I think Hector is making - >> to define a new policy p=rejectnonarc or something, which means that >> sites which are ARC-unaware accept rather than reject.> > So this is an excellent and crucial point that has been discussed > again and again on and off this list.> > ARC only works if critical mass can be reached - both of > intermediaries who break DKIM and receivers who evaluate ARC.> > Fundamentally, ARC will never reach critical mass if senders now also > need to enter into the equation with an additional flag on their DMARC > record. This is too high a bar and increases the interoperability > problems as opposed to reducing them.> For now, there is a clear unanswered question: what coverage of > receivers is needed for most mailing lists to achieve stable delivery > once ARC is in the mix? Knowing the landscape of receiving domains, I > believe this to be a small number. From the above comments, I'm > guessing you think this is a large number. We're not going to resolve > this difference of opinion in an open forum. However, releasing ARC as > an experiment into the wild for major lists like the IETF and M3AAWG > will give us very clear data very quickly on what the actual landscape > looks like, and what ARC does and does not solve.> > In its current form, ARC only helps mail flows, it does not harm them. > How effective this improvement is remains to be seen, but preliminary > information I've been hearing about (which could be totally wrong) > makes it seem like the improvements are dramatic. So let's get ARC > tied off as an Experiment (thank you, Dave Crocker), collect some > data, and see where things stand. Maybe things are great and ARC can > move to proposed standard. Maybe it fundamentally needs more receivers > in the mix than currently expected, and some fix for that is needed. > But we'll know that after the experiment has begun, not before. Seems reasonable. We will deploy it at FastMail for sure and collect data. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_150293447840536360 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Thu, 17 Aug 2017, at 11:32, Seth Blank wrote:
While there exists A SINGLE SITE which is ARC-unaware and DMARC p=reject aware, you can't use ARC on a DMARC p=reject domain without rewriting the sender.  Otherwise that site will bounce the email.

You still have to rewrite the sender until there is either full adoption or sufficient adoption that you just don't care about the stragglers.

ARC doesn't solve that unless every receiver is either ARC-aware or DMARC-unaware.  Hence the suggestion that I think Hector is making - to define a new policy p=rejectnonarc or something, which means that sites which are ARC-unaware accept rather than reject.

So this is an excellent and crucial point that has been discussed again and again on and off this list.

ARC only works if critical mass can be reached - both of intermediaries who break DKIM and receivers who evaluate ARC.

Fundamentally, ARC will never reach critical mass if senders now also need to enter into the equation with an additional flag on their DMARC record. This is too high a bar and increases the interoperability problems as opposed to reducing them.
For now, there is a clear unanswered question: what coverage of receivers is needed for most mailing lists to achieve stable delivery once ARC is in the mix? Knowing the landscape of receiving domains, I believe this to be a small number. From the above comments, I'm guessing you think this is a large number. We're not going to resolve this difference of opinion in an open forum. However, releasing ARC as an experiment into the wild for major lists like the IETF and M3AAWG will give us very clear data very quickly on what the actual landscape looks like, and what ARC does and does not solve.

In its current form, ARC only helps mail flows, it does not harm them. How effective this improvement is remains to be seen, but preliminary information I've been hearing about (which could be totally wrong) makes it seem like the improvements are dramatic. So let's get ARC tied off as an Experiment (thank you, Dave Crocker), collect some data, and see where things stand. Maybe things are great and ARC can move to proposed standard. Maybe it fundamentally needs more receivers in the mix than currently expected, and some fix for that is needed. But we'll know that after the experiment has begun, not before.

Seems reasonable.  We will deploy it at FastMail for sure and collect data.

Bron.

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


--_----------=_150293447840536360-- From nobody Wed Aug 16 22:28:16 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0BDC1323FD for ; Wed, 16 Aug 2017 22:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60cQN8txYP1S for ; Wed, 16 Aug 2017 22:28:12 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1230124E15 for ; Wed, 16 Aug 2017 22:28:11 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id x191so31307292qka.5 for ; Wed, 16 Aug 2017 22:28:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EmLT8vMXWb+3RxRInDYJ+xAjlV4yh6k05sUHoH8oBYE=; b=A09C/b8MnFukucK9NP0ICXOePp5UkyyCbEVqK8dvbtsDQ/A0x8p9tP8gHHZ5SToKbf cnGG6Bo0O97fFkqBVxjpSaCElH1gcAtKkDT97doiuKb/YEjMi79a729SEBWpcGvxMXI1 j0ZrvJbS61Yg7LNjZ1DyCk3hnh/9YSIjX+E/VTstTg7xwem7YlVBbF1rkH2sbQfPgFoI XQwVCKIR2pSMpeon5DYs1QDfhrkeBnAgVCWHXTUtwfX2wqEfqjJO1BNGc6DjTrpbbUUT bPLiDr8hRnRsThucX4OQjQagzuZ9zVaL5G/EOQkzywQMfb6cBUYJPkWzMOpIGYsCrFHn wGTA== 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=EmLT8vMXWb+3RxRInDYJ+xAjlV4yh6k05sUHoH8oBYE=; b=taxJvFvkBcmswVMgIaCdpMQoj7ujhl5PvBRiOkdYwtT5Q6XHOMHSe69XEF2GzSC4AS iRaNLqV//61Iec95hGsam7IbeUgaUKN3iI4HPEw8HYU0zfmuzdUyicMPdbzfT9XAQkKl K20GQIJmfDBJloisc/+dDXSCsS2jl+VrIIyB3UuewhM29sRlqE3vmn4yYIOJfIu7AAPH +MYTHIOximttBUc1A3I0jEhz/08uWQ4th23V4u1NW3f5v4UWZjugTnBBjArsvdpznb4P qfbWZfNIi8LU4Ml85D1Zd/KEEi/xTRSPngqQgrh1XRZgOLxEH7gWhWQHBLd/F7C7fhLi fvcw== X-Gm-Message-State: AHYfb5jqzKuwuzZ65FIgtfj1GRfaH7+rNbS++mEJEXqlFoyCfaFFQUQU zG8L8o2QemDUx9PYqRH3iyT5CvhdUK9U X-Received: by 10.55.47.135 with SMTP id v129mr5616413qkh.13.1502947690942; Wed, 16 Aug 2017 22:28:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.57.34 with HTTP; Wed, 16 Aug 2017 22:28:10 -0700 (PDT) In-Reply-To: <1502930858.4042926.1075890568.5069945B@webmail.messagingengine.com> References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> <166070f0-4ba1-70da-1f73-885b4a7f7640@gmail.com> <1502497178.4103451.1070917304.23DD466D@webmail.messagingengine.com> <598F9484.7020700@isdg.net> <599484FB.9050908@isdg.net> <1502929303.4038704.1075868960.5D80A788@webmail.messagingengine.com> <1502930858.4042926.1075890568.5069945B@webmail.messagingengine.com> From: "Murray S. Kucherawy" Date: Wed, 16 Aug 2017 22:28:10 -0700 Message-ID: To: Bron Gondwana Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a114f40203c15460556ec4701" Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 05:28:14 -0000 --001a114f40203c15460556ec4701 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana wrote: > While there exists A SINGLE SITE which is ARC-unaware and DMARC p=reject > aware, you can't use ARC on a DMARC p=reject domain without rewriting the > sender. Otherwise that site will bounce the email. > > Goodness, it's a wonder that we've ever successfully deployed anything incremental around here. ;-) -MSK --001a114f40203c15460556ec4701 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana <br= ong@fastmailteam.com> wrote:
While there exists A SINGLE SITE which is ARC-unaware and DMARC p= =3Dreject aware, you can't use ARC on a DMARC p=3Dreject domain without= rewriting the sender.=C2=A0 Otherwise that site will bounce the email.


Goodness, it&= #39;s a wonder that we've ever successfully deployed anything increment= al around here.=C2=A0 ;-)

-MSK
<= /div>
--001a114f40203c15460556ec4701-- From nobody Thu Aug 17 01:09:08 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 898F6132397 for ; Thu, 17 Aug 2017 01:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=ijTlmPse; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=get+2NJ4 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqlIr1qkgtUO for ; Thu, 17 Aug 2017 01:09:04 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6639132386 for ; Thu, 17 Aug 2017 01:09:04 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 906D420B48; Thu, 17 Aug 2017 04:09:03 -0400 (EDT) Received: from web1 ([10.202.2.211]) by compute6.internal (MEProxy); Thu, 17 Aug 2017 04:09:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=dkpLaw8ArcBXW6EY7UCNPI1yxPStu c+nV26dz294F1w=; b=ijTlmPse8wEyxqNkb18s3yr0jGHdjpcdt57eo2YQ9I6gA iJHjjy/ZEoUWdrWef0lECWAbsncSydseHRs7V+8CrDH22XEAbBHRkZIXIEYA991m PakKvlhNcUPgAEcuEoD1WfeshFA1EnkmbF0ud5j9kZgrBM9uJqEpNB2BTz+sh2YE h36xPWRaQKV/r6iqLK6yH31Omgwm0Y/84dCjw2VyhIrbi2HnxP0VRFbyPRZEWxfE uLl3ZAribIXJLtx6+XV/rZdkGREF5+ux3FhT+LLLu4k3/gQ3YPsofxySCrHd6sWH pxPBPcrhjPfOWXoHk9zM1UJPaEAaiURO9JnwlTnxg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=dkpLaw8ArcBXW6EY7UCNPI1yxPStu c+nV26dz294F1w=; b=get+2NJ4dwW192UDfk1r/b4IPRkAH9JqabyTHe7ZKTEnB 5EC7c1TE09v/aQ1EYa0SwujljCCuNKEJoZFOUgrv+/1clogo5vkGdETVzykOYb0m 9i4QgTxqO6rqSCPzX8RBEtKlHeFyYs/0+Pxk/efpUS20hGyNeugJ1DSp9u2L06O/ jvQ+MB3nXeetJL3U86qEtlL2s5RlD0K7Gwto6F1s+EB3yFJMs2f3VRdomBj4kMcr iDb/Nj4CLJWLFV8bzoaYroA+hGft1OKSdXQwLUkXCHp4XwvtdzNUzk1i/LzrdQCd SMJfj5si/nU5DF5l9fZav+iEydg5pipdfhl5j7Hjg== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 72BBA9571D; Thu, 17 Aug 2017 04:09:03 -0400 (EDT) Message-Id: <1502957343.3548792.1076152832.1FEB1A8C@webmail.messagingengine.com> From: Bron Gondwana To: "Murray S. Kucherawy" Cc: dmarc@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150295734335487920" X-Mailer: MessagingEngine.com Webmail Interface - ajax-21c69044 Date: Thu, 17 Aug 2017 18:09:03 +1000 Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 08:09:06 -0000 This is a multi-part message in MIME format. --_----------=_150295734335487920 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Thu, 17 Aug 2017, at 15:28, Murray S. Kucherawy wrote: > On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana > wrote:>> While there exists A SINGLE SITE which is ARC-unaware and DMARC >> p=reject aware, you can't use ARC on a DMARC p=reject domain without >> rewriting the sender. Otherwise that site will bounce the email.>> >> > Goodness, it's a wonder that we've ever successfully deployed anything > incremental around here. ;-)> -MSK I laugh as well, but it's more than p=reject isn't enough in the ARC world, because it doesn't distinguish between:a) I'm OK with email from my domain being sent via mailing lists; and b) no, this domain is only ever used for direct messages, it should never appear in ARC chains that don't also pass DKIM. The existing behaviour of p=reject is (b) for receivers that don't support ARC - so the question becomes: are we defining ARC to changing the behaviour of p=reject to (a)? If so, will we define a different (b) later, when we could instead havedefined a different p= for (a). The interesting question is what happens at non-updated sites in each case, because the answer is either "valid emails that should have been accepted are rejected by old policy engine" or "spoofed emails that should have been rejected are accepted by old policy engine" That's a worthwhile question. Maybe it's already been asked and answered and I just missed that. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_150295734335487920 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Thu, 17 Aug 2017, at 15:28, Murray S. Kucherawy wrote:
On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana <brong@fastmailteam.com> wrote:
While there exists A SINGLE SITE which is ARC-unaware and DMARC p=reject aware, you can't use ARC on a DMARC p=reject domain without rewriting the sender.  Otherwise that site will bounce the email.


Goodness, it's a wonder that we've ever successfully deployed anything incremental around here.  ;-)
-MSK

I laugh as well, but it's more than p=reject isn't enough in the ARC world, because it doesn't distinguish between:
a) I'm OK with email from my domain being sent via mailing lists; and
b) no, this domain is only ever used for direct messages, it should never appear in ARC chains that don't also pass DKIM.

The existing behaviour of p=reject is (b) for receivers that don't support ARC - so the question becomes:  are we defining ARC to changing the behaviour of p=reject to (a)?  If so, will we define a different (b) later, when we could instead have
defined a different p= for (a).

The interesting question is what happens at non-updated sites in each case, because the answer is either "valid emails that should have been accepted are rejected by old policy engine" or "spoofed emails that should have been rejected are accepted by old policy engine"

That's a worthwhile question.  Maybe it's already been asked and answered and I just missed that.

Bron.

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


--_----------=_150295734335487920-- From nobody Thu Aug 17 07:18:32 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE3E8132196 for ; Thu, 17 Aug 2017 07:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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=americangreetings.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6JenBDJP2ZE for ; Thu, 17 Aug 2017 07:18:28 -0700 (PDT) Received: from mailer1.americangreetings.com (mailer1.americangreetings.com [66.119.43.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05C2513244F for ; Thu, 17 Aug 2017 07:18:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=americangreetings.com; s=q42010; c=relaxed/relaxed; q=dns/txt; i=@americangreetings.com; t=1502979506; x=1534515506; h=From:Subject:Date:To:Cc:Reply-To:Message-ID:MIME-Version:Content-Type; bh=pSNSrFCkkIYCL+auNNPCkWLlg9zNyJPhjsvaJrXI2dc=; b=EEhVDLuG95pyf1M4fVJslguT/Rq+L35WmL5EuSdaEyq72auFsWzx7Of3gzAc6E2R Zz8LSLwxGTVq3vpMYLXlbv5J0N2ki+KTKVbicBu1NqdFePEN5wMuTfbsGDAZNjH1 H/Z5o/ZlvdrtHY9qm5yqj1iAKviijNrJsAGTzbffAw8=; Received: from [66.119.43.83] ([66.119.43.83:2695] helo=dc3-mbox.ops.ag.com) by momentum7 (envelope-from ) (ecelerity 3.6.18.52357 r(Core:3.6.18.0)) with ESMTP id 5C/AC-11320-2B5A5995; Thu, 17 Aug 2017 10:18:26 -0400 Received: from [10.210.42.24] ([10.210.42.24]) by dc3-mbox.ops.ag.com (8.14.4/8.14.4) with ESMTP id v7HEIQkt019519 for ; Thu, 17 Aug 2017 10:18:26 -0400 To: dmarc@ietf.org References: <1502957343.3548792.1076152832.1FEB1A8C@webmail.messagingengine.com> From: "mhammer@americangreetings.com" Message-ID: Date: Thu, 17 Aug 2017 10:18:25 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <1502957343.3548792.1076152832.1FEB1A8C@webmail.messagingengine.com> Content-Type: multipart/alternative; boundary="------------2392CA09522D04071A7642CA" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 14:18:31 -0000 This is a multi-part message in MIME format. --------------2392CA09522D04071A7642CA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 8/17/2017 4:09 AM, Bron Gondwana wrote: > On Thu, 17 Aug 2017, at 15:28, Murray S. Kucherawy wrote: >> On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana >> > wrote: >> >> While there exists A SINGLE SITE which is ARC-unaware and DMARC >> p=reject aware, you can't use ARC on a DMARC p=reject domain >> without rewriting the sender. Otherwise that site will bounce the >> email. >> >> >> Goodness, it's a wonder that we've ever successfully deployed >> anything incremental around here. ;-) >> -MSK > > I laugh as well, but it's more than p=reject isn't enough in the ARC > world, because it doesn't distinguish between: > a) I'm OK with email from my domain being sent via mailing lists; and > b) no, this domain is only ever used for direct messages, it should > never appear in ARC chains that don't also pass DKIM. > You assume that mailing lists are the only corner case that ARC might address. It’s quite possible that this is not true. It's also not clear what you mean by "direct messages". When an agent does an MX lookup, it has no way of knowing whether the indicated MX host is the final destination or whether there are additional internal (to the administrative domain) or external hops beyond the initially indicated MX host. That's one of the things that makes the wonderful wacky world of email so interesting. While mailing lists are important to many, they are the tail and not the dog in the email world. > The existing behaviour of p=reject is (b) for receivers that don't > support ARC - so the question becomes: are we defining ARC to > changing the behaviour of p=reject to (a)? If so, will we define a > different (b) later, when we could instead have > defined a different p= for (a). > This is absolutely an incorrect statement. Policy within DMARC, as expressed by p=, is a request by the sending domain and can always be ignored or overridden by local policy. Using ARC as an input is no different than any other input that a mailbox provider/validator considers in making delivery decisions. > The interesting question is what happens at non-updated sites in each > case, because the answer is either "valid emails that should have been > accepted are rejected by old policy engine" or "spoofed emails that > should have been rejected are accepted by old policy engine" > In the DMARC world, emails are only valid in the sense that they pass either SPF or DKIM validation. A decision to accept or reject any given email involves many choices beyond simply passing DMARC validation for a given from domain. Spoofing may involve emails which pass DMARC validation but contain spoofing in the From display name, or any number of other ways. Mike --------------2392CA09522D04071A7642CA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 8/17/2017 4:09 AM, Bron Gondwana wrote:
On Thu, 17 Aug 2017, at 15:28, Murray S. Kucherawy wrote:
On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana <brong@fastmailteam.com> wrote:
While there exists A SINGLE SITE which is ARC-unaware and DMARC p=reject aware, you can't use ARC on a DMARC p=reject domain without rewriting the sender.  Otherwise that site will bounce the email.


Goodness, it's a wonder that we've ever successfully deployed anything incremental around here.  ;-)
-MSK

I laugh as well, but it's more than p=reject isn't enough in the ARC world, because it doesn't distinguish between:
a) I'm OK with email from my domain being sent via mailing lists; and
b) no, this domain is only ever used for direct messages, it should never appear in ARC chains that don't also pass DKIM.

You assume that mailing lists are the only corner case that ARC might address. It’s quite possible that this is not true. It's also not clear what you mean by "direct messages". When an agent does an MX lookup, it has no way of knowing whether the indicated MX host is the final destination or whether there are additional internal (to the administrative domain) or external hops beyond the initially indicated MX host. That's one of the things that makes the wonderful wacky world of email so interesting. While mailing lists are important to many, they are the tail and not the dog in the email world.

The existing behaviour of p=reject is (b) for receivers that don't support ARC - so the question becomes:  are we defining ARC to changing the behaviour of p=reject to (a)?  If so, will we define a different (b) later, when we could instead have
defined a different p= for (a).


This is absolutely an incorrect statement. Policy within DMARC, as expressed by p=, is a request by the sending domain and can always be ignored or overridden by local policy. Using ARC as an input is no different than any other input that a mailbox provider/validator considers in making delivery decisions.

The interesting question is what happens at non-updated sites in each case, because the answer is either "valid emails that should have been accepted are rejected by old policy engine" or "spoofed emails that should have been rejected are accepted by old policy engine"


In the DMARC world, emails are only valid in the sense that they pass either SPF or DKIM validation. A decision to accept or reject any given email involves many choices beyond simply passing DMARC validation for a given from domain. Spoofing may involve emails which pass DMARC validation but contain spoofing in the From display name, or any number of other ways.

Mike

--------------2392CA09522D04071A7642CA-- From nobody Thu Aug 17 11:44:53 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1901323CE for ; Thu, 17 Aug 2017 11:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0owwM1GGd3vz for ; Thu, 17 Aug 2017 11:44:49 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AEA31323A7 for ; Thu, 17 Aug 2017 11:44:49 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id u133so25340794vke.3 for ; Thu, 17 Aug 2017 11:44:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CZvoGPfK8ttLaqXaGnxkAh9CLGLLYNQ6aYjPw9cadUk=; b=BmAqg2dL0ldTEypmyh3MdnsFdg+sA0eong/uJy05nyZXe6dtjuap8S5iOFLXt7hBx+ yZJotMaiV3wKDNl0naAmCwEsu0tzPNEiljsrIdierK5NiWsbSILXP8BhrM5P5dsc3I5Z HEz3ktDp2wdzausFlt9TNIBYcddjouPxqQWdSN2DtPlQKylSyYEMmA3NcSXvlhe9sNnX l7rhxNlmPXAatmbeqCJMOSg8wf+KaDyACKXIN+qaKSFNY/hzH0Kf0OcDJnmZQwKshl9p Vzrh0OKqixfiHCOIyEWr1YU7Kxw0uI/Gvx88Y6uuZpf2u2UYqLoRvumlWBzmfWmRZ2Ln kDhQ== 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=CZvoGPfK8ttLaqXaGnxkAh9CLGLLYNQ6aYjPw9cadUk=; b=Cybw61RaCPjZ6wSmBhEa2O8T25HH+kIpYapOR+qZsf7zqDTUuJgk/ONh3KBy0fnWrN uIUYLscS/fh1gcaJNH6LQP1i6v9lBV4axBQ/vwhrobaGeU3x37E1gfUrntX9aHXuq+fD xcmYEXvwXXYm9JUx73Bt0RN/6SGrQo1us4Cb1ES365BNKgV+jSqOqhoSqCnvYIh8ikIG AfmaGekXeWK8aJZBRNYNzpnXvvhW9A4o2dfNbHW0boVjVrzhoaOBq/jaYbve82SnkuQw B2FZXsPUD6NjCnUHYtIdxzOPdN6cwf9H27cf7DxPzTW2MMkFZzvCXfwOKqd6slZDZtYY 9cnA== X-Gm-Message-State: AHYfb5h7QHS9STU3mfcUcJ7AoE7tqS2dPtkqvRZpL0kKKRNkIyt9U6bv 3U7PTsMa8F0qekPn9IOPdoyfFFVx7qbtD94= X-Received: by 10.31.120.12 with SMTP id t12mr3990413vkc.29.1502995488040; Thu, 17 Aug 2017 11:44:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.135.139 with HTTP; Thu, 17 Aug 2017 11:44:47 -0700 (PDT) In-Reply-To: <1502930858.4042926.1075890568.5069945B@webmail.messagingengine.com> References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> <166070f0-4ba1-70da-1f73-885b4a7f7640@gmail.com> <1502497178.4103451.1070917304.23DD466D@webmail.messagingengine.com> <598F9484.7020700@isdg.net> <599484FB.9050908@isdg.net> <1502929303.4038704.1075868960.5D80A788@webmail.messagingengine.com> <1502930858.4042926.1075890568.5069945B@webmail.messagingengine.com> From: Brandon Long Date: Thu, 17 Aug 2017 11:44:47 -0700 Message-ID: To: Bron Gondwana Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c1495962a9cd40556f768b0" Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 18:44:52 -0000 --94eb2c1495962a9cd40556f768b0 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana wrote: > On Thu, 17 Aug 2017, at 10:34, Seth Blank wrote: > > On Wed, Aug 16, 2017 at 5:21 PM, Bron Gondwana > wrote: > > The only way you could even hope (as a mailing list) to avoid rewriting > the sender is for every site that currently has DMARC p=reject to change > that to a new policy which explicitly means "only reject if no ARC chain" - > otherwise you can't stop rewriting sender until you know that every > receiver on your list is ARC-aware. > > > I don't understand your point. > > > If you are a mailing list and you receive a message from a domain with > DMARC p=reject, you can't send that message on to the members of your list > without rewriting the sender. > > The only way DKIM works is if enough receivers validate it. > > The only way adding elliptic curve to DKIM works is if enough receivers > validate it. > > The only way a DMARC policy works is if enough receivers validate it. > > ARC is the explicit solution to mailing list breakage with DMARC. But, as > with all other IETF RFCs, only works if enough receivers validate it. > > Our job is to make sure ARC accomplishes its goals under the DMARC > charter, and demonstrate value to receivers that it's worthwhile to > implement. > > There will always be a ramp up and implementation phase, that is a > feature, not a bug, and not a reason to say "it won't work." > > > While there exists A SINGLE SITE which is ARC-unaware and DMARC p=reject > aware, you can't use ARC on a DMARC p=reject domain without rewriting the > sender. Otherwise that site will bounce the email. > > You still have to rewrite the sender until there is either full adoption > or sufficient adoption that you just don't care about the stragglers. > > ARC doesn't solve that unless every receiver is either ARC-aware or > DMARC-unaware. Hence the suggestion that I think Hector is making - to > define a new policy p=rejectnonarc or something, which means that sites > which are ARC-unaware accept rather than reject. > Theoretically, if rewriting the from header had been the "approved" way to work around DMARC issues for mailing ilsts, one could imagine that something like ARC could have explicitly allowed for that concept and making it so receivers could back-sub the original From or something. That way, ARC implementers would get immediate benefits over from rewriting. OTOH, if you ignore from header rewriting as a solution (which many have), then ARC implementation theoretically adds immediate benefit (or the potential for immediate benefit, since it requires participation from both the mailing list and receivers) ARC definitely solves more than from header rewriting does, but from header rewriting is certainly a much simpler solution for mailing lists... even as it makes them slightly worse to use. Brandon --94eb2c1495962a9cd40556f768b0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana <brong@fastmailtea= m.com> wrote:
On Thu, 17 Aug 2017,= at 10:34, Seth Blank wrote:
On Wed, Aug 16, 2017 at 5:21 PM, Bron Gondwana <brong@fast= mailteam.com> wrote:
The only way you could even hope (as a mailing list) to avoid rewriting th= e sender is for every site that currently has DMARC p=3Dreject to change th= at to a new policy which explicitly means "only reject if no ARC chain= " - otherwise you can't stop rewriting sender until you know that = every receiver on your list is ARC-aware.

I don't understand your point.

If you are a mailing list and you r= eceive a message from a domain with DMARC p=3Dreject, you can't send th= at message on to the members of your list without rewriting the sender.
=

The only way DKIM= works is if enough receivers validate it.

The only way adding elliptic curve to DKIM works is if enough rec= eivers validate it.

The only way a DMARC policy works is if enough receivers validate it.<= br>

ARC is the explicit solution to mailing list breakage with DMARC. But,= as with all other IETF RFCs, only works if enough receivers validate it.

Our job is to make sure ARC accomplishes its goals under the DMARC cha= rter, and demonstrate value to receivers that it's worthwhile to implem= ent.

There will always be a ramp up and implementation phase, that is a fea= ture, not a bug, and not a reason to say "it won't work."
=

While there exists A SINGLE SITE wh= ich is ARC-unaware and DMARC p=3Dreject aware, you can't use ARC on a D= MARC p=3Dreject domain without rewriting the sender.=C2=A0 Otherwise that s= ite will bounce the email.

You still have to rewrite the sender until= there is either full adoption or sufficient adoption that you just don'= ;t care about the stragglers.

ARC doesn't solve that unless every re= ceiver is either ARC-aware or DMARC-unaware.=C2=A0 Hence the suggestion tha= t I think Hector is making - to define a new policy p=3Drejectnonarc or som= ething, which means that sites which are ARC-unaware accept rather than rej= ect.

Theoretically, if rewritin= g the from header had been the "approved" way to work around DMAR= C issues for mailing ilsts, one could imagine that something like ARC could= have explicitly allowed for that concept and making it so receivers could = back-sub the original From or something. That way, ARC implementers would g= et immediate benefits over from rewriting.

OTOH, i= f you ignore from header rewriting as a solution (which many have), then AR= C implementation theoretically adds immediate benefit (or the potential for= immediate benefit, since it requires participation from both the mailing l= ist and receivers)

ARC definitely solves more than= from header rewriting does, but from header rewriting is certainly a much = simpler solution for mailing lists... even as it makes them slightly worse = to use.

Brandon

--94eb2c1495962a9cd40556f768b0-- From nobody Thu Aug 17 11:49:23 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE4231325EE for ; Thu, 17 Aug 2017 11:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 A8QQM4JV-jrr for ; Thu, 17 Aug 2017 11:49:20 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B1A413236D for ; Thu, 17 Aug 2017 11:49:20 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id d124so25420538vkf.2 for ; Thu, 17 Aug 2017 11:49:19 -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=PYwOqViLy9N2dr6KWlrxWJmLWM1WEaxMbYWV9NeeU14=; b=XiUFPuWlCWr/fukdGRzSAOD4taLEJYGS9geZgQ86HlF8ecsFvRitOMZDmzsjj37nYq ThOjo9vzViUK/3mNKRfzLnLfWbahKnB8PX1tV/zSIqBJ3ZSavxiAz08D/OXhV8ho3lqG 3L91e6dE1tSCQPxZbYpEKJDDPldRXWlhpwRLdpRdOY7XevOFdh2fM13xYnDxU6x4oo61 i2FWSOPEUhcMDkr3YIuuPqJmM1LTZrJzMluat1EFp0yydQQgh98tVSqU1VUNaDP0UIBP Kr+qH3YaMZon88u46OfkymqCogV3ZVxz1oPVCojOtH4bfly0LzM4nc5IBGGSYzwEiORT Di+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=PYwOqViLy9N2dr6KWlrxWJmLWM1WEaxMbYWV9NeeU14=; b=Ff5Xm49v96Dm9DEnJR7gma3Fz1dbVLbfg0Fs0Zz588tObnVJmZvHEK2aZAHovmp6zT Xz/tk7o/2CEhEn48BgktiWVRcLuf6jAsW5ywJg/1UJKu9OHwfgbX1g6pB7P/kQWBDFEs 5mwjO11iTUdBPtq6kwQNNCmBYBoJDvB+KpglcBVKB/j+n75BgRMeEITMMO18d+GvhHuz vA5C7Ne7vX+JQTLwzD1Ps8VkwtBBB/+vBG+PmAGBg76MCHeJoJTAiIl88OuP3oGlnajE HbFbLK5SQKAoYILN3CcRIFKqJAgarqd30jhYALTaW8DzkhORIm6+TdOSraPjUa8HIN51 Z3fw== X-Gm-Message-State: AHYfb5h4wqrmA7s0I7jVRvzy5noDZdOL0qhK3CV5RD/4bSxjvINn3vOn 5QgZ33/X64Yyw8305aXGhL9t819AwZw6L02eWA== X-Received: by 10.31.87.132 with SMTP id l126mr3866343vkb.81.1502995758765; Thu, 17 Aug 2017 11:49:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.89.22 with HTTP; Thu, 17 Aug 2017 11:48:58 -0700 (PDT) In-Reply-To: <1502957343.3548792.1076152832.1FEB1A8C@webmail.messagingengine.com> References: <1502957343.3548792.1076152832.1FEB1A8C@webmail.messagingengine.com> From: Seth Blank Date: Thu, 17 Aug 2017 11:48:58 -0700 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="001a114e59f44cf70e0556f778d5" Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 18:49:22 -0000 --001a114e59f44cf70e0556f778d5 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 17, 2017 at 1:09 AM, Bron Gondwana wrote: > > I laugh as well, but it's more than p=reject isn't enough in the ARC > world, because it doesn't distinguish between: > a) I'm OK with email from my domain being sent via mailing lists; and > b) no, this domain is only ever used for direct messages, it should never > appear in ARC chains that don't also pass DKIM. > The DMARC WG charter directly addresses this: https://datatracker.ietf.org/wg/dmarc/charter/ Our stated goal is to fix indirect mail flows so that they do not break under DMARC. To me, that's an explicit requirement of a), with b) being out of scope. Seth --001a114e59f44cf70e0556f778d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Our stated goal is to fix indirect mail flows so that they do not = break under DMARC. To me, that's an explicit requirement of a), with b)= being out of scope.

Seth=C2=A0
<= /div> --001a114e59f44cf70e0556f778d5-- From nobody Thu Aug 17 11:56:16 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 574051324D2 for ; Thu, 17 Aug 2017 11:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHS3RrGWxpLd for ; Thu, 17 Aug 2017 11:56:13 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1409B1325DD for ; Thu, 17 Aug 2017 11:56:13 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id a77so41857000qkb.0 for ; Thu, 17 Aug 2017 11:56:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bCWRSzEQNWzDHkLRlLdJ7wBJi8GcyJm4642+MMd67V0=; b=QaMC08z7swc3cnF1A0gld+QHaYQlYHNVrJTLrmGO4tJ8Jh+I9N+xjjgxpkLlzXfVh4 Px/Gwg3vdO7BYlFlOqA0jOKoxjdv7gt9plCwdYEPvYDLMd3BCLWmgd3sRbFxQgRRP3D9 lkWthI/fwAaeoGTUs0wvYpcpqX2+KBpCbaL2rM1JDZzE9vlUbw3tzUSjtFXnoZoPDDSg TzDuqwnN5bb0j+XusOX9Hl1UzDJxWLsMQF4WZobweUKYjgTU0vItqxoUtrqhYaUtVOF4 dD/g5WBBv7LxEyvINUeK9uXcDiO16R2CkpdAgnreejx3WlyvOer0bYCmNpIY19Wt5OSw LNzw== 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=bCWRSzEQNWzDHkLRlLdJ7wBJi8GcyJm4642+MMd67V0=; b=m9I0RIcXyeuHWb76AgVMXB7mn1ssx8G/IxetbpxKw/Tdzpna2NWYhHZU4PSH/VwI8/ PgiOinm3AMl0vQtEMwk0T4Q+/P2MYPZhMr0DPAM2wSX6U+ia/gtC8EzVjD+7MPLHQo4i w5CZ98YaH5+o6sWphvh+7Sza+SQkerZVEj5RT96Sl9SN9c+bwV7xkpplVO5k99zl3u36 cHljSYixjx0iCsxhhC1XjIYj2BMYyAn2xSX6/F1B1Rz6MA1iSdSkJW9HAEiXJ0Vsjrb8 JcvB82QDTzYcXA02Pi4z8XLjFUlgsBBUeg+DeJmsJlKAN4t1t42bVoqZXlETWFb5RvIr LTmg== X-Gm-Message-State: AHYfb5g6lZClEhqlj4UU7BFU6ohDtL3w77KDIn84O7Bkceh3C7OIFf3Y KC+zORwjsFJMf22mTWA0WJGQ5muEE/Ex X-Received: by 10.55.118.71 with SMTP id r68mr8116015qkc.234.1502996172127; Thu, 17 Aug 2017 11:56:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.57.34 with HTTP; Thu, 17 Aug 2017 11:56:11 -0700 (PDT) In-Reply-To: <1502957343.3548792.1076152832.1FEB1A8C@webmail.messagingengine.com> References: <1502957343.3548792.1076152832.1FEB1A8C@webmail.messagingengine.com> From: "Murray S. Kucherawy" Date: Thu, 17 Aug 2017 11:56:11 -0700 Message-ID: To: Bron Gondwana Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c05f7e6f045bf0556f790a3" Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 18:56:15 -0000 --94eb2c05f7e6f045bf0556f790a3 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 17, 2017 at 1:09 AM, Bron Gondwana wrote: > On Thu, 17 Aug 2017, at 15:28, Murray S. Kucherawy wrote: > > On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana > wrote: > > While there exists A SINGLE SITE which is ARC-unaware and DMARC p=reject > aware, you can't use ARC on a DMARC p=reject domain without rewriting the > sender. Otherwise that site will bounce the email. > > > Goodness, it's a wonder that we've ever successfully deployed anything > incremental around here. ;-) > -MSK > > > I laugh as well, but it's more than p=reject isn't enough in the ARC > world, because it doesn't distinguish between: > a) I'm OK with email from my domain being sent via mailing lists; and > b) no, this domain is only ever used for direct messages, it should never > appear in ARC chains that don't also pass DKIM. > > The existing behaviour of p=reject is (b) for receivers that don't support > ARC - so the question becomes: are we defining ARC to changing the > behaviour of p=reject to (a)? If so, will we define a different (b) later, > when we could instead have > defined a different p= for (a). > My point is that the "SINGLE SITE" posture is absurd. In all likelihood there are still some MTAs out there that don't implement ESMTP and nothing has melted. We should fully expect things to roll out gradually, as they always have. Anyone planning for a flag day should speak up now so we can disabuse them (and, of course, abuse them). If the success of DMARC depends on 100% deployment of ARC, we may as well pack up and go home now. It'll never happen. I support the idea of trying ARC even in the form you claim includes superfluous operations. (For the record, I find your technical argument compelling.) If after a period of experimentation and data collecting we find that the seal is not itself useful, we can negotiate a reduced form and try that. If you really want to prove your point sooner, implement both, run them for a while, and publish the results. But given that there are interoperating implementations now, I think there's enough to be learned from the experiment to continue from here rather than reset. -MSK --94eb2c05f7e6f045bf0556f790a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Aug 17, 2017 at 1:09 AM, Bron Gondwana <br= ong@fastmailteam.com> wrote:
On Thu, 17 Aug= 2017, at 15:28, Murray S. Kucherawy wrote:
On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana <brong@fastmailteam.c= om> wrote:
While there exists A SINGLE SITE which is ARC-unawa= re and DMARC p=3Dreject aware, you can't use ARC on a DMARC p=3Dreject = domain without rewriting the sender.=C2=A0 Otherwise that site will bounce = the email.


Goodness, it's a wonder that we&#= 39;ve ever successfully deployed anything incremental around here.=C2=A0 ;-= )
-MSK

I laugh as well, but it's = more than p=3Dreject isn't enough in the ARC world, because it doesn= 9;t distinguish between:
a) I'm OK with email from my domain be= ing sent via mailing lists; and
b) no, this domain is only ever used for d= irect messages, it should never appear in ARC chains that don't also pa= ss DKIM.

The existing behaviour of p=3Dreject is (b= ) for receivers that don't support ARC - so the question becomes: =C2= =A0are we defining ARC to changing the behaviour of p=3Dreject to (a)?=C2= =A0 If so, will we define a different (b) later, when we could instead have=
defined a different p=3D for (a).

My point is that the "SINGLE S= ITE" posture is absurd.=C2=A0 In all likelihood there are still some M= TAs out there that don't implement ESMTP and nothing has melted.=C2=A0 = We should fully expect things to roll out gradually, as they always have.= =C2=A0 Anyone planning for a flag day should speak up now so we can disabus= e them (and, of course, abuse them).

If the succes= s of DMARC depends on 100% deployment of ARC, we may as well pack up and go= home now.=C2=A0 It'll never happen.

I sup= port the idea of trying ARC even in the form you claim includes superfluous= operations.=C2=A0 (For the record, I find your technical argument compelli= ng.)=C2=A0 If after a period of experimentation and data collecting we find= that the seal is not itself useful, we can negotiate a reduced form and tr= y that.

If you really want to prove your point soo= ner, implement both, run them for a while, and publish the results.=C2=A0 B= ut given that there are interoperating implementations now, I think there&#= 39;s enough to be learned from the experiment to continue from here rather = than reset.

-MSK
--94eb2c05f7e6f045bf0556f790a3-- From nobody Thu Aug 17 12:11:15 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F95213237B for ; Thu, 17 Aug 2017 12:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, 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=fiction.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 hxnO1_zFiLkY for ; Thu, 17 Aug 2017 12:11:11 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 669EC13214D for ; Thu, 17 Aug 2017 12:11:10 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id d124so25613730vkf.2 for ; Thu, 17 Aug 2017 12:11:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fiction.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lgG69PeYJI4Vk+E+ssPEPx6UI/xlY9Yx7JY+NDan2Bg=; b=fblD7MZfY//jtPMn2QcGqGUe3tVI5NC8tyFMsP5oAdY51W0yBUolN00O0uPTNDL5gu FSFxzncwqqTJ7uIsnTIfWcsJyiDE3jtcqAZ3Y4VjkLqb1aI6kIaujO95C3gWNHuicxWb O/629JJRm2mLrh6KoTZtL0+FeExqZ1hKVuDzYsQpclEvcnsHDM1gmIVp/c74mEPFqbnJ igBi1JqIVfx8romYCwfnwqJm/WaOSzYyXtSMV23HxuJwYEXrUfEMhUCVJ+EvBXF8ybjz 6ewHHC0kFFM22+THN/y2qb+6BgXCgCxRtbCM29CWwRiekgs0tl8DodZ1ntklAoZ/oWtS CTCQ== 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=lgG69PeYJI4Vk+E+ssPEPx6UI/xlY9Yx7JY+NDan2Bg=; b=iWPQdnNVCLX/91r7YFd5SDeXyiVM8K8SWeeacoJF4n5G3oWMmP91o/fveh+W9OKI9Z Xc9U6dcRjswBMaz/E6aIQzlZc58OkdYs7+1aPR951msvuGJlON1vJ4rTbxfRXlpWVik1 gTeRu+9Y6mHPePPYLoI7Cgy4Zx9Mm9g690MWEVlom4zDTTuNwR07hgm3Cm83ssEALj6a 1wGEAhB3INGl93WWouh0xBUxc6bvZJ7AiDTN6yFDM7+j5DnayvxCYtH0cmAnmpBfQZ+g 7ZygB+KmHXDp302dCtYg97wgeQOvlqFGt+GoCL8qBGjiU2NHUVab6y+dqa6wJpAvXLN0 IZMw== X-Gm-Message-State: AHYfb5iOc+tzJzYxdZuBkjs/aFOzq3qikSBDboCSAzxw8xeVT8oQEB30 bMZTrkePA4z7VGBJBvo= X-Received: by 10.31.242.73 with SMTP id q70mr1267330vkh.60.1502997069408; Thu, 17 Aug 2017 12:11:09 -0700 (PDT) Received: from mail-vk0-f44.google.com (mail-vk0-f44.google.com. [209.85.213.44]) by smtp.gmail.com with ESMTPSA id 195sm824604vkv.33.2017.08.17.12.11.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Aug 2017 12:11:08 -0700 (PDT) Received: by mail-vk0-f44.google.com with SMTP id j189so25590399vka.0 for ; Thu, 17 Aug 2017 12:11:08 -0700 (PDT) X-Received: by 10.31.89.195 with SMTP id n186mr4075680vkb.5.1502997067943; Thu, 17 Aug 2017 12:11:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.135.139 with HTTP; Thu, 17 Aug 2017 12:11:07 -0700 (PDT) In-Reply-To: <1502930858.4042926.1075890568.5069945B@webmail.messagingengine.com> References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> <166070f0-4ba1-70da-1f73-885b4a7f7640@gmail.com> <1502497178.4103451.1070917304.23DD466D@webmail.messagingengine.com> <598F9484.7020700@isdg.net> <599484FB.9050908@isdg.net> <1502929303.4038704.1075868960.5D80A788@webmail.messagingengine.com> <1502930858.4042926.1075890568.5069945B@webmail.messagingengine.com> From: Brandon Long Date: Thu, 17 Aug 2017 12:11:07 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Bron Gondwana Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a114e1ff256093f0556f7c675" Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 19:11:14 -0000 --001a114e1ff256093f0556f7c675 Content-Type: text/plain; charset="UTF-8" dammit, posted from the wrong address again... On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana wrote: > On Thu, 17 Aug 2017, at 10:34, Seth Blank wrote: > > On Wed, Aug 16, 2017 at 5:21 PM, Bron Gondwana > wrote: > > The only way you could even hope (as a mailing list) to avoid rewriting > the sender is for every site that currently has DMARC p=reject to change > that to a new policy which explicitly means "only reject if no ARC chain" - > otherwise you can't stop rewriting sender until you know that every > receiver on your list is ARC-aware. > > > I don't understand your point. > > > If you are a mailing list and you receive a message from a domain with > DMARC p=reject, you can't send that message on to the members of your list > without rewriting the sender. > > The only way DKIM works is if enough receivers validate it. > > The only way adding elliptic curve to DKIM works is if enough receivers > validate it. > > The only way a DMARC policy works is if enough receivers validate it. > > ARC is the explicit solution to mailing list breakage with DMARC. But, as > with all other IETF RFCs, only works if enough receivers validate it. > > Our job is to make sure ARC accomplishes its goals under the DMARC > charter, and demonstrate value to receivers that it's worthwhile to > implement. > > There will always be a ramp up and implementation phase, that is a > feature, not a bug, and not a reason to say "it won't work." > > > While there exists A SINGLE SITE which is ARC-unaware and DMARC p=reject > aware, you can't use ARC on a DMARC p=reject domain without rewriting the > sender. Otherwise that site will bounce the email. > > You still have to rewrite the sender until there is either full adoption > or sufficient adoption that you just don't care about the stragglers. > > ARC doesn't solve that unless every receiver is either ARC-aware or > DMARC-unaware. Hence the suggestion that I think Hector is making - to > define a new policy p=rejectnonarc or something, which means that sites > which are ARC-unaware accept rather than reject. > Theoretically, if rewriting the from header had been the "approved" way to work around DMARC issues for mailing ilsts, one could imagine that something like ARC could have explicitly allowed for that concept and making it so receivers could back-sub the original From or something. That way, ARC implementers would get immediate benefits over from rewriting. OTOH, if you ignore from header rewriting as a solution (which many have), then ARC implementation theoretically adds immediate benefit (or the potential for immediate benefit, since it requires participation from both the mailing list and receivers) ARC definitely solves more than from header rewriting does, but from header rewriting is certainly a much simpler solution for mailing lists... even as it makes them slightly worse to use. Brandon --001a114e1ff256093f0556f7c675 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
dammit, posted from the wrong address again...

On Wed, Aug 16, 2017 at 5= :47 PM, Bron Gondwana <brong@fastmailteam.com> wrote:
On Thu, 17 Aug= 2017, at 10:34, Seth Blank wrote:
On Wed, Aug 16, 2017 at 5:21 PM, Bron Gondwana <brong@fast= mailteam.com> wrote:
The only = way you could even hope (as a mailing list) to avoid rewriting the sender i= s for every site that currently has DMARC p=3Dreject to change that to a ne= w policy which explicitly means "only reject if no ARC chain" - o= therwise you can't stop rewriting sender until you know that every rece= iver on your list is ARC-aware.

I don't understand your point.

If you are a mailing list and you r= eceive a message from a domain with DMARC p=3Dreject, you can't send th= at message on to the members of your list without rewriting the sender.
=

The only way DKIM= works is if enough receivers validate it.

The only way adding elliptic curve to DKIM works is if enough rec= eivers validate it.

The only way a DMARC policy works is if enough receivers validate it.<= br>

ARC is the explicit solution to mailing list breakage with DMARC. But,= as with all other IETF RFCs, only works if enough receivers validate it.

Our job is to make sure ARC accomplishes its goals under the DMARC cha= rter, and demonstrate value to receivers that it's worthwhile to implem= ent.

There will always be a ramp up and implementation phase, that is a fea= ture, not a bug, and not a reason to say "it won't work."
=

While there exists A SINGLE SITE wh= ich is ARC-unaware and DMARC p=3Dreject aware, you can't use ARC on a D= MARC p=3Dreject domain without rewriting the sender.=C2=A0 Otherwise that s= ite will bounce the email.

You still have to rewrite the sender until= there is either full adoption or sufficient adoption that you just don'= ;t care about the stragglers.

ARC doesn't solve that unless every re= ceiver is either ARC-aware or DMARC-unaware.=C2=A0 Hence the suggestion tha= t I think Hector is making - to define a new policy p=3Drejectnonarc or som= ething, which means that sites which are ARC-unaware accept rather than rej= ect.

Theoretically, if rewriting the from header had= been the "approved" way to work around DMARC issues for mailing = ilsts, one could imagine that something like ARC could have explicitly allo= wed for that concept and making it so receivers could back-sub the original= From or something. That way, ARC implementers would get immediate benefits= over from rewriting.

OTOH, if you ignore from header rewriting as a so= lution (which many have), then ARC implementation theoretically adds immedi= ate benefit (or the potential for immediate benefit, since it requires part= icipation from both the mailing list and receivers)

ARC definitely solv= es more than from header rewriting does, but from header rewriting is certa= inly a much simpler solution for mailing lists... even as it makes them sli= ghtly worse to use.

Brandon
--001a114e1ff256093f0556f7c675-- From nobody Thu Aug 17 12:12:50 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0432C13261F for ; Thu, 17 Aug 2017 12:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cg7OxCVx16Y for ; Thu, 17 Aug 2017 12:12:47 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C712413214D for ; Thu, 17 Aug 2017 12:12:46 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id o124so33605174qke.3 for ; Thu, 17 Aug 2017 12:12:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MoCeG7K/RRv3rJQcNpnvf36EjKQCwn3GxbXc1u1FT7M=; b=ZGiP2nCIoHHA8DmD2icqB0P5ecKKOb5Oz9vbDJxmTLcDm4RwimrPgnxoIdjny+xL/7 tnMP50gHCESAgEAgOQ4BCQvXWdm8FYDgSJ9UQV5EAROYuuiIdzDmjjQZ56v516+8Ggzp jTgNAIGgqjjDxRhEI8B0uk760FML1q8HIOqaMKDKkLUvF1vJjazZKozQDCicQPF7XWw+ 7KzEHowl6B3pnf7NLLt9xAtmbEHBnRzNONr3Zyfk1bFt/GNdVACEzlDfaNDZ59wwc8p7 3PYidNm3fw0VDWEgIgPdnXbXrrtnc0oSf2WTVlXbX7uJVKdeOVdeuEbuMbEVVogm6vdg Cyuw== 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=MoCeG7K/RRv3rJQcNpnvf36EjKQCwn3GxbXc1u1FT7M=; b=bFJJM9rXfGnou2jLD2FbXBznmB4R1FHP0M1fJ1AoGHC2PilR3TE5yGEnA6QrTH+Ji6 w+XstfgN5szP1WBhgXCmLje6Fv3OlTwMp9B4E2Lf++BNlnKrzoagPqHVhvde8YZkcHh/ uhB++LTljxCg3wx59gFFJkXr9ZBn2c5nEgMggnjyCo9vwm5XPk0dHZLXEaxeTGQOZh8N FoCB/VIvb2EkL3cARK99+rpxepMbTiGIz1B6jVccAPCvFC4X+Ld5vHyl2EMfvvhbMkSR 7bt/3yeTSqrC/oN2vRuQ/3/92zDKVuADOo7ZHovhAM7wNaPUqDIhEb4X1me0n36ZtG9k j0/w== X-Gm-Message-State: AHYfb5jIklgfOXB8tCM4m4ENVeQ/6wGc6AGG7v6jKoX2Ocp/s4nfaRm1 zSmZKy1C7jfHFEcEOPVb+tUueNpTHDIG X-Received: by 10.55.121.6 with SMTP id u6mr8923722qkc.111.1502997165863; Thu, 17 Aug 2017 12:12:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.57.34 with HTTP; Thu, 17 Aug 2017 12:12:45 -0700 (PDT) In-Reply-To: References: <1502957343.3548792.1076152832.1FEB1A8C@webmail.messagingengine.com> From: "Murray S. Kucherawy" Date: Thu, 17 Aug 2017 12:12:45 -0700 Message-ID: To: Seth Blank Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c06275e2b78e50556f7cc36" Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 19:12:49 -0000 --94eb2c06275e2b78e50556f7cc36 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 17, 2017 at 11:48 AM, Seth Blank wrote: > On Thu, Aug 17, 2017 at 1:09 AM, Bron Gondwana > wrote: >> >> I laugh as well, but it's more than p=reject isn't enough in the ARC >> world, because it doesn't distinguish between: >> a) I'm OK with email from my domain being sent via mailing lists; and >> b) no, this domain is only ever used for direct messages, it should never >> appear in ARC chains that don't also pass DKIM. >> > > The DMARC WG charter directly addresses this: > https://datatracker.ietf.org/wg/dmarc/charter/ > > Our stated goal is to fix indirect mail flows so that they do not break > under DMARC. To me, that's an explicit requirement of a), with b) being out > of scope. > +1. My understanding is that altering DMARC is off the table right now. We have to try to move forward. I'm particularly opposed to adding a new "p=" value without a great deal of thought put into it, lest the set of values there become hopelessly polluted with things representing every conceivable combination of authentication results and header field values, many of which will end up being ephemeral. -MSK --94eb2c06275e2b78e50556f7cc36 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Aug 17, 2017 at 11:48 AM, Seth Blank <seth@sethb= lank.com> wrote:
On Thu, Aug 17, 20= 17 at 1:09 AM, Bron Gondwana <brong@fastmailteam.com> w= rote:
I laugh as well, but it's more than p=3Dreject isn= 9;t enough in the ARC world, because it doesn't distinguish between:
a) I'm OK with email from my domain be= ing sent via mailing lists; and
b) no, this domain is only ever used for d= irect messages, it should never appear in ARC chains that don't also pa= ss DKIM.

The DMARC WG ch= arter directly addresses this: https://datatracker.ietf.org/wg/dmarc= /charter/

Our stated goal is to fix indirect m= ail flows so that they do not break under DMARC. To me, that's an expli= cit requirement of a), with b) being out of scope.
<= /blockquote>

+1.=C2=A0 My understanding is that altering= DMARC is off the table right now.=C2=A0 We have to try to move forward.

I'm particularly opposed to adding a new "p= =3D" value without a great deal of thought put into it, lest the set o= f values there become hopelessly polluted with things representing every co= nceivable combination of authentication results and header field values, ma= ny of which will end up being ephemeral.

-MSK<= br>
--94eb2c06275e2b78e50556f7cc36-- From nobody Thu Aug 17 14:46:43 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07924132645 for ; Thu, 17 Aug 2017 14:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=nr5BuYZ8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Q6DdvfFg Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asPGiQcKpJwx for ; Thu, 17 Aug 2017 14:46:39 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CE441321B7 for ; Thu, 17 Aug 2017 14:46:39 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 104CE210A5 for ; Thu, 17 Aug 2017 17:46:38 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Thu, 17 Aug 2017 17:46:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=srAky1XDoa6daSJt3 fXmEIrLw8aFuD8LshROtx5UcYA=; b=nr5BuYZ8lSK4VsU3DudZEug0h0J9PPsOu KN8edFTL8opzzcNsLQ0cLVyidXK4rJaAhjNRnYPBVPLcXJ7nqSgYYyZqCyOFTb9C E0nbEmzhp/jgHWItK9DbbYVjVwzTLUY+tCx0FalurrSaYOSk3kFCtwdAgdbdcOxZ m7uUikO5BfuU1BQNiaX8RiVFD8yuTNO+KTbZfCMq1Y3txJ3hGEcX2DB2PsRO6rt5 jtewFgeGxMyDSp+8v2Aincaop/FnjEZ7E2/IS7jZ/d7pP21TVoEzRfUWVr/ghVOz CgrHMcF5qb7tJCnNDw/T+7W2fbIIRyAmgo4qIOBbL35yoG+3KFnhg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=srAky1 XDoa6daSJt3fXmEIrLw8aFuD8LshROtx5UcYA=; b=Q6DdvfFgVfAJXUrPoNVCxu PnHISyD4GCOS2nIyGvj0vGYm/lm6PanY5U/oQRtPUfrKRW1Nl+V9No2zfH5n/ydj 0Xj2GF0AqoYz0cdu9UXnPFuZY/NWVc9tMyg3643xO2fCO6BAhV+4BVxgmnfBz+Gb N3Vib/WrgXXpeqF39TqFL704WphIzNDAdXDCGvlgebJiUecHSVBRD4Awccdi/FCq CT86cKny7v4sdbL+Hw64f/odi9s9HJ9UKh3r6MEOXpPSZQm9Ca5vXPFuWr9gi7YG jv4dVQ65webPBhNrrEkG3S1K32DronFMSvV7PJ2DIciqMnl8cT/cfR7m5/rUVKZA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id CE1BABAB71; Thu, 17 Aug 2017 17:46:37 -0400 (EDT) Message-Id: <1503006397.1306110.1076933224.154E25D6@webmail.messagingengine.com> From: Bron Gondwana To: dmarc@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150300639713061103" X-Mailer: MessagingEngine.com Webmail Interface - ajax-21c69044 In-Reply-To: References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> <166070f0-4ba1-70da-1f73-885b4a7f7640@gmail.com> <1502497178.4103451.1070917304.23DD466D@webmail.messagingengine.com> <598F9484.7020700@isdg.net> <599484FB.9050908@isdg.net> <1502929303.4038704.1075868960.5D80A788@webmail.messagingengine.com> <1502930858.4042926.1075890568.5069945B@webmail.messagingengine.com> Date: Fri, 18 Aug 2017 07:46:37 +1000 Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 21:46:42 -0000 This is a multi-part message in MIME format. --_----------=_150300639713061103 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Fri, 18 Aug 2017, at 05:11, Brandon Long wrote: > dammit, posted from the wrong address again... You'll be dealing with this until the bulk of mailing lists AND receivers have become ARC aware, so you've got a while to get used to changing which address you post from :p > On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana > wrote:>> __ >> >> On Thu, 17 Aug 2017, at 10:34, Seth Blank wrote: >>> On Wed, Aug 16, 2017 at 5:21 PM, Bron Gondwana >>> wrote:>>>> The only way you could even hope (as a mailing list) to avoid >>>> rewriting the sender is for every site that currently has DMARC >>>> p=reject to change that to a new policy which explicitly means >>>> "only reject if no ARC chain" - otherwise you can't stop rewriting >>>> sender until you know that every receiver on your list is ARC- >>>> aware.>>> >>> I don't understand your point. >> >> >> If you are a mailing list and you receive a message from a domain >> with DMARC p=reject, you can't send that message on to the members of >> your list without rewriting the sender.>> >> >>> The only way DKIM works is if enough receivers validate it. >>> >>> The only way adding elliptic curve to DKIM works is if enough >>> receivers validate it.>>> >>> The only way a DMARC policy works is if enough receivers >>> validate it.>>> >>> ARC is the explicit solution to mailing list breakage with DMARC. >>> But, as with all other IETF RFCs, only works if enough receivers >>> validate it.>>> >>> Our job is to make sure ARC accomplishes its goals under the DMARC >>> charter, and demonstrate value to receivers that it's worthwhile to >>> implement.>>> >>> There will always be a ramp up and implementation phase, that is a >>> feature, not a bug, and not a reason to say "it won't work.">> >> >> While there exists A SINGLE SITE which is ARC-unaware and DMARC >> p=reject aware, you can't use ARC on a DMARC p=reject domain without >> rewriting the sender. Otherwise that site will bounce the email.>> >> You still have to rewrite the sender until there is either full >> adoption or sufficient adoption that you just don't care about the >> stragglers.>> >> ARC doesn't solve that unless every receiver is either ARC-aware or >> DMARC-unaware. Hence the suggestion that I think Hector is making - >> to define a new policy p=rejectnonarc or something, which means that >> sites which are ARC-unaware accept rather than reject.> > Theoretically, if rewriting the from header had been the "approved" > way to work around DMARC issues for mailing ilsts, one could imagine > that something like ARC could have explicitly allowed for that concept > and making it so receivers could back-sub the original From or > something. That way, ARC implementers would get immediate benefits > over from rewriting. I've thought quite a lot about that as well. I would love if most mailing lists included enough data to reconstruct the original DKIM- passing message again, so the receiver could actually know the diff from the original message and scan it separately. That way you could very easily know whether the source of any objectionable content was the mailing list or the original sender. > OTOH, if you ignore from header rewriting as a solution (which many > have), then ARC implementation theoretically adds immediate benefit > (or the potential for immediate benefit, since it requires > participation from both the mailing list and receivers) I kind of buy that. I'll be interested to see how it pans out in practice. > ARC definitely solves more than from header rewriting does, but from > header rewriting is certainly a much simpler solution for mailing > lists... even as it makes them slightly worse to use. As someone just about to launch a new mailing list product, we will be from-header rewriting for DMARC p=reject domains for at least a little while, and likely building something horrible which attempts not rewriting for individual recipients and keeping a whilelist to see if they don't reject. Though if someone is just dropping messages, we would never know - it's a horrible uncertain situation as the site in the middle, because you don't know how the message will be handled downstream - it depends on whether the recipient supports ARC, and you can't know that for sure. That's the big that makes me uncomfortable - ARC is defined in such a way that certain participants are unsure of whether they can safely keep sending legitimate email and have it accepted, because the interaction with DMARC is defined in such a way that ARC *changes the behaviour of DMARC* in a non-backwards-compatible way, and we will be running, for at least a while, in a world in which some recipients treat DMARC the old way (non-ARC-aware) and some treat it the new way. So your only possible mitigation as the middleman, if you want full deliverability, is to modify the message in such a way that DMARC no longer applies to it. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_150300639713061103 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Fri, 18 Aug 2017, at 05:11, Brandon Long wrote:
dammit, posted from the wrong address again...

You'll be dealing with this until the bulk of mailing lists AND receivers have become ARC aware, so you've got a while to get used to changing which address you post from :p

On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana <brong@fastmailteam.com> wrote:


On Thu, 17 Aug 2017, at 10:34, Seth Blank wrote:
On Wed, Aug 16, 2017 at 5:21 PM, Bron Gondwana <brong@fastmailteam.com> wrote:
The only way you could even hope (as a mailing list) to avoid rewriting the sender is for every site that currently has DMARC p=reject to change that to a new policy which explicitly means "only reject if no ARC chain" - otherwise you can't stop rewriting sender until you know that every receiver on your list is ARC-aware.

I don't understand your point.


If you are a mailing list and you receive a message from a domain with DMARC p=reject, you can't send that message on to the members of your list without rewriting the sender.


The only way DKIM works is if enough receivers validate it.

The only way adding elliptic curve to DKIM works is if enough receivers validate it.

The only way a DMARC policy works is if enough receivers validate it.

ARC is the explicit solution to mailing list breakage with DMARC. But, as with all other IETF RFCs, only works if enough receivers validate it.

Our job is to make sure ARC accomplishes its goals under the DMARC charter, and demonstrate value to receivers that it's worthwhile to implement.

There will always be a ramp up and implementation phase, that is a feature, not a bug, and not a reason to say "it won't work."


While there exists A SINGLE SITE which is ARC-unaware and DMARC p=reject aware, you can't use ARC on a DMARC p=reject domain without rewriting the sender.  Otherwise that site will bounce the email.

You still have to rewrite the sender until there is either full adoption or sufficient adoption that you just don't care about the stragglers.

ARC doesn't solve that unless every receiver is either ARC-aware or DMARC-unaware.  Hence the suggestion that I think Hector is making - to define a new policy p=rejectnonarc or something, which means that sites which are ARC-unaware accept rather than reject.

Theoretically, if rewriting the from header had been the "approved" way to work around DMARC issues for mailing ilsts, one could imagine that something like ARC could have explicitly allowed for that concept and making it so receivers could back-sub the original From or something. That way, ARC implementers would get immediate benefits over from rewriting.

I've thought quite a lot about that as well.  I would love if most mailing lists included enough data to reconstruct the original DKIM-passing message again, so the receiver could actually know the diff from the original message and scan it separately.  That way you could very easily know whether the source of any objectionable content was the mailing list or the original sender.

OTOH, if you ignore from header rewriting as a solution (which many have), then ARC implementation theoretically adds immediate benefit (or the potential for immediate benefit, since it requires participation from both the mailing list and receivers)

I kind of buy that.  I'll be interested to see how it pans out in practice.

ARC definitely solves more than from header rewriting does, but from header rewriting is certainly a much simpler solution for mailing lists... even as it makes them slightly worse to use.

As someone just about to launch a new mailing list product, we will be from-header rewriting for DMARC p=reject domains for at least a little while, and likely building something horrible which attempts not rewriting for individual recipients and keeping a whilelist to see if they don't reject.  Though if someone is just dropping messages, we would never know - it's a horrible uncertain situation as the site in the middle, because you don't know how the message will be handled downstream - it depends on whether the recipient supports ARC, and you can't know that for sure.

That's the big that makes me uncomfortable - ARC is defined in such a way that certain participants are unsure of whether they can safely keep sending legitimate email and have it accepted, because the interaction with DMARC is defined in such a way that ARC changes the behaviour of DMARC in a non-backwards-compatible way, and we will be running, for at least a while, in a world in which some recipients treat DMARC the old way (non-ARC-aware) and some treat it the new way.

So your only possible mitigation as the middleman, if you want full deliverability, is to modify the message in such a way that DMARC no longer applies to it.

Bron.

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


--_----------=_150300639713061103-- From nobody Thu Aug 17 15:46:10 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9530E1323AA for ; Thu, 17 Aug 2017 15:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=F7SpRLsj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=r0T++TDA Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zs2OlVTIPnMo for ; Thu, 17 Aug 2017 15:46:07 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7872132649 for ; Thu, 17 Aug 2017 15:46:07 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 1299D21002 for ; Thu, 17 Aug 2017 18:46:07 -0400 (EDT) Received: from web6 ([10.202.2.216]) by compute6.internal (MEProxy); Thu, 17 Aug 2017 18:46:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=ZPK+jeIA9z5Rarft9 I1ftbHz+QbB0+7fygXGnjoe1ZI=; b=F7SpRLsjtW2K6CiDbkguToCAf3sH3ZuBh lRlg3cb/TwxhlN2WRra+MjfZCyr6agmhf8qdbkLxn1AFgGyJDB9fA6bTg7jysWsE ID1tx/qS62IZ5OjNFjnPatfDd+OHKuVgviCOjJS4UlUKhQihMneeGAOClvQL9d2G ctB7kkowaDyRDFHo7ayKgKKQk0q8HQs+yDAT1jVv/vd+584bpLmDAMdziQL/15ys MjojrcE71XcQOhd9QFwHnB96Q1Jl5rVAj4JMdURW9aoSf6BTBMyDzLXxKAluH1RR J9f7CxiOYX7nqy8kF8UBOvTJZhKNxAyvSZxM837ho6F8uLn1nUT0g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=ZPK+je IA9z5Rarft9I1ftbHz+QbB0+7fygXGnjoe1ZI=; b=r0T++TDAjP2rcZXbSupZZ3 c3wB3bvHZRIEqYVs1OVJky+DNRNwk47WsBIKX7wPHLHKY/ygptC18y5RzECABOiZ A8pqhI4WmXykzFCcwgHcFH4TKIcq7MvrpcLKgdusWwIHliOUDtqW0+4zkLRmUG1F UrixQAzTWoBHT3NMyy9UZVIUcYXTLf2RuOJaWf+lpm4l6ibeNmoVB1FlUB4iiMMf gYHqJ690p+u3E9vhn2BsmtyE0Psit3lFgZ9TqN4PSdZQDaR1LS4YU31z71AV5D85 lRnr6fJrUHlFwlRjrUxANsqezP2FF2IPJQRFpHND8ihm4r7rFImTQxu4hkca1IbA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id D6EA548001; Thu, 17 Aug 2017 18:46:06 -0400 (EDT) Message-Id: <1503009966.777131.1076940784.1D7A65AB@webmail.messagingengine.com> From: Bron Gondwana To: dmarc@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15030099667771310" X-Mailer: MessagingEngine.com Webmail Interface - ajax-21c69044 In-Reply-To: References: <1502957343.3548792.1076152832.1FEB1A8C@webmail.messagingengine.com> Date: Fri, 18 Aug 2017 08:46:06 +1000 Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 22:46:10 -0000 This is a multi-part message in MIME format. --_----------=_15030099667771310 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Fri, 18 Aug 2017, at 04:48, Seth Blank wrote: > On Thu, Aug 17, 2017 at 1:09 AM, Bron Gondwana > wrote:>> I laugh as well, but it's more than p=reject isn't enough in the ARC >> world, because it doesn't distinguish between:>> a) I'm OK with email from my domain being sent via mailing lists; and>> b) no, this domain is only ever used for direct messages, it should >> never appear in ARC chains that don't also pass DKIM.> > The DMARC WG charter directly addresses this: > https://datatracker.ietf.org/wg/dmarc/charter/> > Our stated goal is to fix indirect mail flows so that they do not > break under DMARC. To me, that's an explicit requirement of a), with > b) being out of scope. OK, so case (a) means that we are explicitly redefining the behaviour of a DMARC receiver. It should now accept messages that it used to reject, because they have additional new headers. Which means what - until it's updated it now no longer compliant, or else it means (as I have just responded to Brandon in what appears to be a split of this same thread) that intermediate sites which modify messages are left in a limbo where they have to guess what happens. In one respect, that's no different than the situation now where intermediate modifiers KNOW that they can't send on messages for p=reject domains (or at least, they would know if they were DMARC- aware). But it does mean that workarounds for DMARC (like modifying the from header) are needed for some time yet. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_15030099667771310 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"



On Fri, 18 Aug 2017, at 04:48, Seth Blank wrote:
On Thu, Aug 17, 2017 at 1:09 AM, Bron Gondwana <brong@fastmailteam.com> wrote:
I laugh as well, but it's more than p=reject isn't enough in the ARC world, because it doesn't distinguish between:
a) I'm OK with email from my domain being sent via mailing lists; and
b) no, this domain is only ever used for direct messages, it should never appear in ARC chains that don't also pass DKIM.

The DMARC WG charter directly addresses this: https://datatracker.ietf.org/wg/dmarc/charter/

Our stated goal is to fix indirect mail flows so that they do not break under DMARC. To me, that's an explicit requirement of a), with b) being out of scope.

OK, so case (a) means that we are explicitly redefining the behaviour of a DMARC receiver.  It should now accept messages that it used to reject, because they have additional new headers.  Which means what - until it's updated it now no longer compliant, or else it means (as I have just responded to Brandon in what appears to be a split of this same thread) that intermediate sites which modify messages are left in a limbo where they have to guess what happens.

In one respect, that's no different than the situation now where intermediate modifiers KNOW that they can't send on messages for p=reject domains (or at least, they would know if they were DMARC-aware).  But it does mean that workarounds for DMARC (like modifying the from header) are needed for some time yet.

Bron.

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


--_----------=_15030099667771310-- From nobody Thu Aug 17 17:22:56 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64CCD1323A0 for ; Thu, 17 Aug 2017 17:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fiction.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 NkK7heRIA6aV for ; Thu, 17 Aug 2017 17:22:52 -0700 (PDT) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B866D132396 for ; Thu, 17 Aug 2017 17:22:51 -0700 (PDT) Received: by mail-ua0-x234.google.com with SMTP id f9so30419486uaf.4 for ; Thu, 17 Aug 2017 17:22:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fiction.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=K4Yheyqi00PcRFe2WVsFATjqqlQB+PjqhwUKThxNtQM=; b=DRpY4B2N8RNV+ot0b/xDS766KyfY1aQOwNMBB8WKY/JUrh5ccPbU5un8Bz+hKjzG3o 2rWlUY0kQL6iW2YhjHcgBPaDcNsKwxtB7y/HwQ6UVPmSEHIjbkrVJTVo8TN7wdgBgSCW GJhDefi1mHVV7FOe+GgnxtMMwr7cynki2fidzNGOTpnRINGy5depUc11SKtCxPb/5Nzh NJ1ASZ9QnjZgwm2IKQDbSTCUzS/wpGIx3LF7TFQJpsQAYlmh9cXrI04LaM/+K3DhrPaE OCLew21OEAGCcn78AAbTWDfLjT3XW9oh9ATLbvS5fw4dLqzbZsAic5SqLnrHtwL4fmqe jXTg== 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=K4Yheyqi00PcRFe2WVsFATjqqlQB+PjqhwUKThxNtQM=; b=QOn69nOP3ycPelk6f3CzBj5TZX1J1HhBvmxDYtWzR+XGxQ83484fBsoOah0//6RtRD iHBovcwVcFEQ/3xf/ojY6AJ8Oys2lW2HqOyvtyqtv3R6Wn3w2a+xoROvGh/QbvvSIXnk IRBKMZgaU7bIsvSohR4Upgv17KzlnbQxx/8/pAUfV+FXYEQaFlQYVtUHywe18tKIS+lB 2zYiHrs9oGx+ozLuLwQgdIWmzlHXKoBs+THQBn+gsy5BYMSVED45mTD3zj7L+f48JJII fqgbeWKUvLwijCI79qRXNDX6ne+swlNzT4XXqvi9DtmGaKlOc02xpaghwVYehbI7y0Ce 2YAw== X-Gm-Message-State: AHYfb5iFzZ9CGnXC5k5CNM9DTr2Fq7xQtqt+6qLdr7J1pCbTjo4Y5MaI iEyZSpE1hprF3OyWaT0= X-Received: by 10.176.2.68 with SMTP id 62mr4904780uas.202.1503015770695; Thu, 17 Aug 2017 17:22:50 -0700 (PDT) Received: from mail-vk0-f52.google.com (mail-vk0-f52.google.com. [209.85.213.52]) by smtp.gmail.com with ESMTPSA id d16sm1020334uag.10.2017.08.17.17.22.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Aug 2017 17:22:49 -0700 (PDT) Received: by mail-vk0-f52.google.com with SMTP id j189so27702539vka.0 for ; Thu, 17 Aug 2017 17:22:49 -0700 (PDT) X-Received: by 10.31.120.12 with SMTP id t12mr4610979vkc.29.1503015769381; Thu, 17 Aug 2017 17:22:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.135.139 with HTTP; Thu, 17 Aug 2017 17:22:48 -0700 (PDT) In-Reply-To: <1503006397.1306110.1076933224.154E25D6@webmail.messagingengine.com> References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> <166070f0-4ba1-70da-1f73-885b4a7f7640@gmail.com> <1502497178.4103451.1070917304.23DD466D@webmail.messagingengine.com> <598F9484.7020700@isdg.net> <599484FB.9050908@isdg.net> <1502929303.4038704.1075868960.5D80A788@webmail.messagingengine.com> <1502930858.4042926.1075890568.5069945B@webmail.messagingengine.com> <1503006397.1306110.1076933224.154E25D6@webmail.messagingengine.com> From: Brandon Long Date: Thu, 17 Aug 2017 17:22:48 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Bron Gondwana Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c1495960745c70556fc21b0" Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre 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 Aug 2017 00:22:55 -0000 --94eb2c1495960745c70556fc21b0 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 17, 2017 at 2:46 PM, Bron Gondwana wrote: > On Fri, 18 Aug 2017, at 05:11, Brandon Long wrote: > > dammit, posted from the wrong address again... > > > You'll be dealing with this until the bulk of mailing lists AND receivers > have become ARC aware, so you've got a while to get used to changing which > address you post from :p > The bulk of mailing lists I deal with are rewriting From headers, IETF is a special case. > On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana > wrote: > > > > On Thu, 17 Aug 2017, at 10:34, Seth Blank wrote: > > On Wed, Aug 16, 2017 at 5:21 PM, Bron Gondwana > wrote: > > The only way you could even hope (as a mailing list) to avoid rewriting > the sender is for every site that currently has DMARC p=reject to change > that to a new policy which explicitly means "only reject if no ARC chain" - > otherwise you can't stop rewriting sender until you know that every > receiver on your list is ARC-aware. > > > I don't understand your point. > > > > If you are a mailing list and you receive a message from a domain with > DMARC p=reject, you can't send that message on to the members of your list > without rewriting the sender. > > > The only way DKIM works is if enough receivers validate it. > > The only way adding elliptic curve to DKIM works is if enough receivers > validate it. > > The only way a DMARC policy works is if enough receivers validate it. > > ARC is the explicit solution to mailing list breakage with DMARC. But, as > with all other IETF RFCs, only works if enough receivers validate it. > > Our job is to make sure ARC accomplishes its goals under the DMARC > charter, and demonstrate value to receivers that it's worthwhile to > implement. > > There will always be a ramp up and implementation phase, that is a > feature, not a bug, and not a reason to say "it won't work." > > > > While there exists A SINGLE SITE which is ARC-unaware and DMARC p=reject > aware, you can't use ARC on a DMARC p=reject domain without rewriting the > sender. Otherwise that site will bounce the email. > > You still have to rewrite the sender until there is either full adoption > or sufficient adoption that you just don't care about the stragglers. > > ARC doesn't solve that unless every receiver is either ARC-aware or > DMARC-unaware. Hence the suggestion that I think Hector is making - to > define a new policy p=rejectnonarc or something, which means that sites > which are ARC-unaware accept rather than reject. > > > Theoretically, if rewriting the from header had been the "approved" way to > work around DMARC issues for mailing ilsts, one could imagine that > something like ARC could have explicitly allowed for that concept and > making it so receivers could back-sub the original From or something. That > way, ARC implementers would get immediate benefits over from rewriting. > > > I've thought quite a lot about that as well. I would love if most mailing > lists included enough data to reconstruct the original DKIM-passing message > again, so the receiver could actually know the diff from the original > message and scan it separately. That way you could very easily know > whether the source of any objectionable content was the mailing list or the > original sender. > We went down the path of including a diff of the message in the headers, but you run up against more complicated changes that make that challenging. Ie, mailing lists which strip attachments. If all we cared about were subject munging and footers, there probably would have been a practical solution there. > OTOH, if you ignore from header rewriting as a solution (which many have), > then ARC implementation theoretically adds immediate benefit (or the > potential for immediate benefit, since it requires participation from both > the mailing list and receivers) > > > I kind of buy that. I'll be interested to see how it pans out in practice. > > ARC definitely solves more than from header rewriting does, but from > header rewriting is certainly a much simpler solution for mailing lists... > even as it makes them slightly worse to use. > > > As someone just about to launch a new mailing list product, we will be > from-header rewriting for DMARC p=reject domains for at least a little > while, and likely building something horrible which attempts not rewriting > for individual recipients and keeping a whilelist to see if they don't > reject. Though if someone is just dropping messages, we would never know - > it's a horrible uncertain situation as the site in the middle, because you > don't know how the message will be handled downstream - it depends on > whether the recipient supports ARC, and you can't know that for sure. > > That's the big that makes me uncomfortable - ARC is defined in such a way > that certain participants are unsure of whether they can safely keep > sending legitimate email and have it accepted, because the interaction with > DMARC is defined in such a way that ARC *changes the behaviour of DMARC* > in a non-backwards-compatible way, and we will be running, for at least a > while, in a world in which some recipients treat DMARC the old way > (non-ARC-aware) and some treat it the new way. > > So your only possible mitigation as the middleman, if you want full > deliverability, is to modify the message in such a way that DMARC no longer > applies to it. > Yes. Brandon --94eb2c1495960745c70556fc21b0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Aug 17, 2017 at 2:46 PM, Bron Gondwana <brong@fastmailtea= m.com> wrote:
On Fri, 18 Aug 2017,= at 05:11, Brandon Long wrote:
dammit, posted from the wrong address again...

You'll be dealing with this unt= il the bulk of mailing lists AND receivers have become ARC aware, so you= 9;ve got a while to get used to changing which address you post from :p
=

The bulk of mailing lists I de= al with are rewriting From headers, IETF is a special case.=C2=A0
On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana <brong@fast= mailteam.com> wrote:
<= /u>

On Thu, 17 Aug 2017, at 10:34, Seth = Blank wrote:
On Wed, Aug 16, 2017 at 5:21 PM, Bron Gondwana <br= ong@fastmailteam.com> wrote:
The only way you could even hope (as a mailing list) to avoid rewrit= ing the sender is for every site that currently has DMARC p=3Dreject to cha= nge that to a new policy which explicitly means "only reject if no ARC= chain" - otherwise you can't stop rewriting sender until you know= that every receiver on your list is ARC-aware.

I don't understand your point.


If you are a mailing list and you receive = a message from a domain with DMARC p=3Dreject, you can't send that mess= age on to the members of your list without rewriting the sender.


The only wa= y DKIM works is if enough receivers validate it.

The only way adding elliptic curve to DKIM works is if enou= gh receivers validate it.

The only way a DMARC policy works is if enough receivers validat= e it.

ARC is the explicit solution to mailing list breakage with DMARC= . But, as with all other IETF RFCs, only works if enough receivers validate= it.

Our job is to make sure ARC accomplishes its goals under the DMA= RC charter, and demonstrate value to receivers that it's worthwhile to = implement.

There will always be a ramp up and implementation phase, that is= a feature, not a bug, and not a reason to say "it won't work.&quo= t;


While there exists A SINGLE SITE which is = ARC-unaware and DMARC p=3Dreject aware, you can't use ARC on a DMARC p= =3Dreject domain without rewriting the sender.=C2=A0 Otherwise that site wi= ll bounce the email.

You still have to rewrite the sender until= there is either full adoption or sufficient adoption that you just don'= ;t care about the stragglers.

ARC doesn't solve that unless every re= ceiver is either ARC-aware or DMARC-unaware.=C2=A0 Hence the suggestion tha= t I think Hector is making - to define a new policy p=3Drejectnonarc or som= ething, which means that sites which are ARC-unaware accept rather than rej= ect.

Theoretically, if rewriting the from header= had been the "approved" way to work around DMARC issues for mail= ing ilsts, one could imagine that something like ARC could have explicitly = allowed for that concept and making it so receivers could back-sub the orig= inal From or something. That way, ARC implementers would get immediate bene= fits over from rewriting.

I've thought quite a lot about = that as well.=C2=A0 I would love if most mailing lists included enough data= to reconstruct the original DKIM-passing message again, so the receiver co= uld actually know the diff from the original message and scan it separately= .=C2=A0 That way you could very easily know whether the source of any objec= tionable content was the mailing list or the original sender.

We went down the path of including a dif= f of the message in the headers, but you run up against more complicated ch= anges that make that challenging.=C2=A0 Ie, mailing lists which strip attac= hments.=C2=A0 If all we cared about were subject munging and footers, there= probably would have been a practical solution there.=C2=A0
OTOH, if you ignore from header rewriting as a solution (which ma= ny have), then ARC implementation theoretically adds immediate benefit (or = the potential for immediate benefit, since it requires participation from b= oth the mailing list and receivers)

I kind of buy that.=C2=A0 I'll = be interested to see how it pans out in practice.

ARC definitely solves more than from header rewriting does, but f= rom header rewriting is certainly a much simpler solution for mailing lists= ... even as it makes them slightly worse to use.

As someone just about to launch a new mail= ing list product, we will be from-header rewriting for DMARC p=3Dreject dom= ains for at least a little while, and likely building something horrible wh= ich attempts not rewriting for individual recipients and keeping a whilelis= t to see if they don't reject.=C2=A0 Though if someone is just dropping= messages, we would never know - it's a horrible uncertain situation as= the site in the middle, because you don't know how the message will be= handled downstream - it depends on whether the recipient supports ARC, and= you can't know that for sure.

That's the big that makes me uncomfort= able - ARC is defined in such a way that certain participants are unsure of= whether they can safely keep sending legitimate email and have it accepted= , because the interaction with DMARC is defined in such a way that ARC c= hanges the behaviour of DMARC in a non-backwards-compatible way, and we= will be running, for at least a while, in a world in which some recipients= treat DMARC the old way (non-ARC-aware) and some treat it the new way.
=

So your only possible mitigation as the mi= ddleman, if you want full deliverability, is to modify the message in such = a way that DMARC no longer applies to it.

Yes.

Brandon=C2=A0
--94eb2c1495960745c70556fc21b0-- From nobody Thu Aug 17 23:46:54 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9829412009C for ; Thu, 17 Aug 2017 23:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tORio6lNbk6q for ; Thu, 17 Aug 2017 23:46:51 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::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 EDFE91323CB for ; Thu, 17 Aug 2017 23:46:48 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id 49so53196343wrw.2 for ; Thu, 17 Aug 2017 23:46:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UPsaaZ8QHNyB9me+jCqGRokY8qOvDoVB9xIQ2HyP4iA=; b=Z8lCJoeFXJGXHN+6g0J+ngtnvMEnEdIL64keMjRG7mkOe+bf2EUwvCDK+shVPq3hzZ +qEn9DEza7HcVyDeMfD22KLLRKDV0PbP4XHJACnR3LUVJacfvRi966H8j4o7Z2NjAyIw Sx3x5aM9u15yErYGVyNkADe1KJ1syOQ144DKY= 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=UPsaaZ8QHNyB9me+jCqGRokY8qOvDoVB9xIQ2HyP4iA=; b=jGQlSk13TQkzT+19LFSocUbbs5SvuPPbj5dmF5CW0jK+n8IRBZWDVh/0pTqlQtVxQ8 FrcMIcIKUeqIqd1UzJSFnwbj6QYxKuWjQfDX26r5gTWeThV4zW3KEJH+Z91SJdgdrRGc otMcELQNFEpQXa951OF6T/Q4kYFMCg4VCA2sn5mKe4wJN87BBe+obkMEZjy8xEFqpBIk EeJg2fOVbhGTC+8oQ7ckC1QSexvLFAd6XoW5xU0cfy9DV8ftY+f0/oX/c/kvJJYyms9T oQNN1EhkqkmyS6jyvBaK3k3nC/0lwI+Hz7Qo4SQ4jK6vjFwtWyOPU+98usvkJdW4n2G+ Q11A== X-Gm-Message-State: AHYfb5jvpCnmBjhCguYD29WRicu5B5HOEGfuiggb80Bg0QTrpk6PZytM hX1LextoRUM1h1qfnrXoBi4ept1BSaWW/pc= X-Received: by 10.80.137.131 with SMTP id g3mr3789335edg.125.1503038807365; Thu, 17 Aug 2017 23:46:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.178.229 with HTTP; Thu, 17 Aug 2017 23:46:46 -0700 (PDT) In-Reply-To: <1502930858.4042926.1075890568.5069945B@webmail.messagingengine.com> References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> <166070f0-4ba1-70da-1f73-885b4a7f7640@gmail.com> <1502497178.4103451.1070917304.23DD466D@webmail.messagingengine.com> <598F9484.7020700@isdg.net> <599484FB.9050908@isdg.net> <1502929303.4038704.1075868960.5D80A788@webmail.messagingengine.com> <1502930858.4042926.1075890568.5069945B@webmail.messagingengine.com> From: Kurt Andersen Date: Thu, 17 Aug 2017 23:46:46 -0700 Message-ID: To: Bron Gondwana Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="f403045c2952326e480557017e44" Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre 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 Aug 2017 06:46:53 -0000 --f403045c2952326e480557017e44 Content-Type: text/plain; charset="UTF-8" So I was able to retrace our design steps which led to the 3-piece model (AAR + AMS + AS) and the reasoning for the AS, signing just the ARC header sequence was to provide the verifiable chain of custody trace (though, of course, only from participating intermediaries). Some of the recent tweaks to the spec to deal with malformed sets of ARC header fields have weakened that original idea. In keeping with Bron's general idea to simplify, I'd suggest that having an AAR + [optional AMS] + AS would be a close approach for handling steps which do not break the ingress signature. Skipping the AMS would be a sign to downstream intermediaries that the prior DKIM or AMS was still valid upon egress. (certain details would have to be worked out) Does that help the conversation? --Kurt --f403045c2952326e480557017e44 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So I was able to retrace our design steps which led to the= 3-piece model (AAR + AMS + AS) and the reasoning for the AS, signing just = the ARC header sequence was to provide the verifiable chain of custody trac= e (though, of course, only from participating intermediaries). Some of the = recent tweaks to the spec to deal with malformed sets of ARC header fields = have weakened that original idea.

In keeping with Bron&#= 39;s general idea to simplify, I'd suggest that having an AAR + [option= al AMS] + AS would be a close approach for handling steps which do not brea= k the ingress signature. Skipping the AMS would be a sign to downstream int= ermediaries that the prior DKIM or AMS was still valid upon egress. (certai= n details would have to be worked out)

Does that h= elp the conversation?

--Kurt
--f403045c2952326e480557017e44-- From nobody Fri Aug 18 10:00:52 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD8EE13231E for ; Fri, 18 Aug 2017 10:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 vFlCEcx21aID for ; Fri, 18 Aug 2017 10:00:49 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD9EF1321EA for ; Fri, 18 Aug 2017 10:00:49 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id r199so34148902vke.4 for ; Fri, 18 Aug 2017 10:00:49 -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=6+NWSJoag3Eg70L7mqFjQ6hkpehKLVzMwA8+ls+4B/Q=; b=DRfkoAzNrQ7KEaGO+FvgA07dHm9/jQlCtd0rquDIgSkrQyoubpSs9x5ZiPK41Dwvj3 txNBpJgA/e6pET1dEgob9MTjKPcqubEYDkt5PkPzlNdVeEZ+llx+xpyw6qrFxzZg7kH3 QZpfByySXzXHnoyyK/IIP4YD2VHJtHOZb/4qzzLN115DorQsRDmf6yGx1Um7yWAmn/M+ 2CT+jK8EUZcw8zP2d+TliQZBrbtwPfJQYkyF+OKWqnw1t4jCc+pEfGCK3Jfdak0lyNpD ssICyhdRjs+B/sRQSZeHyRosIomV1uD9CAsONYbNwGp/cWZwOiWOBJxsLRgoc2eLvGxb LoBA== 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=6+NWSJoag3Eg70L7mqFjQ6hkpehKLVzMwA8+ls+4B/Q=; b=A2bo6phNA0tk6PUslIlwzF4jFFDxbtlku20L8qjste6euN5ZmpMmCXlVDrBUtTYXz7 Ou/3Vqr343fcfwsZc2MsWojjXdgOSmyUi95CStq3lobr41det9WEOOxCfQan+df3BGaf Y8TGG6s0rQTZMCFMDJCfEFRx5A2s4/Ok2mfzLQUk2KZ7MWgHcFxkqJEmvGqiPJ1MiUxB 0VJ/6Ryck57mDzyHSx8qwWMQg8g+FxoMVwGpGa2qxsn6g6jfIikHhRauWMDQl6LVLdx9 hS5g2s+ezdCChXpQIyHMI7VHLru1pLg3L1Y7Dsb2oE6MTumtlfpMXy8obpqqLmHqQ8em dQbg== X-Gm-Message-State: AHYfb5gYgjMUjAWjmKhY3at+d4Qd9Fem5dIpvLyHTZ5L7TyqDNsm9jvw 0auG6x370XPVELQ1ZUv6AYinOYF6PCwaCDw= X-Received: by 10.31.3.205 with SMTP id f74mr263186vki.163.1503075648537; Fri, 18 Aug 2017 10:00:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.89.22 with HTTP; Fri, 18 Aug 2017 10:00:27 -0700 (PDT) In-Reply-To: References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> <166070f0-4ba1-70da-1f73-885b4a7f7640@gmail.com> <1502497178.4103451.1070917304.23DD466D@webmail.messagingengine.com> <598F9484.7020700@isdg.net> <599484FB.9050908@isdg.net> <1502929303.4038704.1075868960.5D80A788@webmail.messagingengine.com> <1502930858.4042926.1075890568.5069945B@webmail.messagingengine.com> From: Seth Blank Date: Fri, 18 Aug 2017 10:00:27 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a1142870c1a1c5105570a121d" Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre 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 Aug 2017 17:00:52 -0000 --001a1142870c1a1c5105570a121d Content-Type: text/plain; charset="UTF-8" On Thu, Aug 17, 2017 at 11:46 PM, Kurt Andersen wrote: > So I was able to retrace our design steps which led to the 3-piece model > (AAR + AMS + AS) and the reasoning for the AS, signing just the ARC header > sequence was to provide the verifiable chain of custody trace (though, of > course, only from participating intermediaries). Some of the recent tweaks > to the spec to deal with malformed sets of ARC header fields have weakened > that original idea. > > In keeping with Bron's general idea to simplify, I'd suggest that having > an AAR + [optional AMS] + AS would be a close approach for handling steps > which do not break the ingress signature. Skipping the AMS would be a sign > to downstream intermediaries that the prior DKIM or AMS was still valid > upon egress. (certain details would have to be worked out) > > Does that help the conversation? > No, I think this is a huge step in the wrong direction. Right now, we've got deployed code that we know works and improves the landscape. Everything else is - rightly or wrongly - conjecture. Let's keep the tech stable and move to experimentation. If anything, this is an excellent question for receivers - when evaluating AMS/AS, were there any situations where you required both signatures to truly validate a chain and make a delivery decision, or with the added ARC payload is now just having one sufficient? Seth --001a1142870c1a1c5105570a121d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Aug 17, 2017 at 11:46 PM, Kurt Andersen <kurta@drkurt.com> wrote:
So I was able= to retrace our design steps which led to the 3-piece model (AAR + AMS + AS= ) and the reasoning for the AS, signing just the ARC header sequence was to= provide the verifiable chain of custody trace (though, of course, only fro= m participating intermediaries). Some of the recent tweaks to the spec to d= eal with malformed sets of ARC header fields have weakened that original id= ea.

In keeping with Bron's general idea to simplify,= I'd suggest that having an AAR + [optional AMS] + AS would be a close = approach for handling steps which do not break the ingress signature. Skipp= ing the AMS would be a sign to downstream intermediaries that the prior DKI= M or AMS was still valid upon egress. (certain details would have to be wor= ked out)

Does that help the conversation?

No, I think this is a huge step in the = wrong direction.

Right now, we've got deployed= code that we know works and improves the landscape. Everything else is - r= ightly or wrongly - conjecture.

Let's keep the= tech stable and move to experimentation.

If anyth= ing, this is an excellent question for receivers - when evaluating AMS/AS, = were there any situations where you required both signatures to truly valid= ate a chain and make a delivery decision, or with the added ARC payload is = now just having one sufficient?

Seth=C2=A0
--001a1142870c1a1c5105570a121d-- From nobody Fri Aug 18 10:08:35 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D699D132386 for ; Fri, 18 Aug 2017 10:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtR7Wd0-tHVZ for ; Fri, 18 Aug 2017 10:08:32 -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 517C71321EA for ; Fri, 18 Aug 2017 10:08:32 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id f11so102670219oic.0 for ; Fri, 18 Aug 2017 10:08:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=eFxfCR0FTUJI7Yu5GpEn2eWNdCQH8+KLz28zjpN9ESA=; b=p9AjH4vJwJ8uvlGKFfwOShXhl2yF6va/tYeJL2cTmlkPdh2xo91AUSN5txZHPJHBIT QewoMPniwJpvG8lf17v48MWB4uQDpN9pbu8bivjD6NAC5CE7VB0Hi6d0nW+aR3GiTMEH 0ojdKRNdfQ0BtHlVkp+x4lPBFw8+02KduhrvV8zyuZBdtGBvDkjng2gC2NknMLFxy71X IdSiu99tdvCmzWZLMypWNT15VIwYDVIZzxA0SdrXuBo/hVABEvpQhVTWIBi0te5/kiuo i1sygFW5rWEMnIUNODFav7mztOF8YSVUvYbciAX7t0xRiSSdjzkGKdvj6T8LzXL+6Nk8 4hyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=eFxfCR0FTUJI7Yu5GpEn2eWNdCQH8+KLz28zjpN9ESA=; b=NoyMNmpemJuJu6jk6qbJ/5mJS9AAPgnsjRYsi/ig9Q1nrh3lz3bv5dvT1dN5E2CiJ1 A+oWmXLzVIKIXN814evWcHUJklESiCgy+oO7U16JDC/tgbrsoCntzJ2+uXyA3hCgzWrc sdxGpo9qB4KUwkUEGSbu6P68mx+9mtSUZbtfpBuHkD5nIbKTEdKg+o40+kZ2jwqR/g4x eUmoE9obVjn4qxZ6esExrXCYrWAhoI6cPBn8JgDknMBpLKXZZSJH+UiMDEIKywuW4/q8 RWgIy/klUKDJjg1QsOINjhWEkgTQlyWSMrWMNJ76ml8ZZHkOf4lT1hQpQjyPWVUQcYCB /EwA== X-Gm-Message-State: AHYfb5h1WfgXVynsDcllZPDeKnlhTc+jsGz62AmpcAyEdNRVAlkQaC4D eaPddNGH8mSxA9oMEHI= X-Received: by 10.202.184.215 with SMTP id i206mr11432127oif.117.1503076111099; Fri, 18 Aug 2017 10:08:31 -0700 (PDT) Received: from ?IPv6:2602:304:cda0:8800:d17e:7fe3:9cb7:7c98? ([2602:304:cda0:8800:d17e:7fe3:9cb7:7c98]) by smtp.gmail.com with ESMTPSA id o11sm6544388oig.23.2017.08.18.10.08.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Aug 2017 10:08:29 -0700 (PDT) To: Seth Blank References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> <166070f0-4ba1-70da-1f73-885b4a7f7640@gmail.com> <1502497178.4103451.1070917304.23DD466D@webmail.messagingengine.com> <598F9484.7020700@isdg.net> <599484FB.9050908@isdg.net> <1502929303.4038704.1075868960.5D80A788@webmail.messagingengine.com> <1502930858.4042926.1075890568.5069945B@webmail.messagingengine.com> Cc: "dmarc@ietf.org" From: Dave Crocker Message-ID: Date: Fri, 18 Aug 2017 10:08:26 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre 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 Aug 2017 17:08:34 -0000 On 8/18/2017 10:00 AM, Seth Blank wrote: > > Right now, we've got deployed code that we know works and improves the > landscape. Everything else is - rightly or wrongly - conjecture. Personal Point of order: Using an 'installed base' argument for a brand new specification that is still in development and has minuscule deployment is not appropriate, in spite of having a long and storied history of being used to resist a proposal. What's supposed to happen with a proposal is an evaluation of its technical and functional merits. The entire point behind bringing a nascent specification to the IETF is to get review and suggestions from a wider audience. d/ ps. Note that I haven't commented on the merits of this particular proposal. I like the intent quite a bit, but haven't thought about the technical or operational aspects yet. -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Aug 18 10:18:12 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6356213219A for ; Fri, 18 Aug 2017 10:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 uA0f9dHPTcZs for ; Fri, 18 Aug 2017 10:18:04 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FBBE120721 for ; Fri, 18 Aug 2017 10:18:04 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id g189so34283415vke.5 for ; Fri, 18 Aug 2017 10:18:04 -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=SDRilE9ISirGEZ6MExQxftuf+8B9bh9z6Qd1nhxut1E=; b=TUeOvsD7zZ43jnsIq9g0aLsZOby0ntwLwhHHgKuAkOTkDp6xLzxWygvFNDN0XKrZcq LLY3178ZXJ4hc+cAaFQtqHDhdlZVnmcFGpFiEP4CG7sYHoWPxe3dabk+oXkSDRHkOOAX CzjB4b96XE7x6xAZI/Uj6BPjzveau2ZEFhXNHFb+LDvIJ2F2TJ9iSQRb8as2MOElRA1D zvjn0I+s8jlAlhtftoBb1WPaOz7y6ay5aTifLV/LUnRtVd10Abz8xiVfIMsNt23M76uD Jz0jh9SGHqryl57uEebkK74NWQAlv4YdbKvymd5QbIdsSyuH+uSUSG+Euejj/axH1ebC 0htQ== 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=SDRilE9ISirGEZ6MExQxftuf+8B9bh9z6Qd1nhxut1E=; b=fbVK9tBL/wiQfWfkDjWKPDwM96YSFPodoCHkiHBd+Rsr0TqOk7uCl62WM2azmcCTmc DNP9fcZ2jN5HD/pJGpdwV+siQ3A/6XAjQdS4C91QqdZ4FkJSKTgGj+0VVzcRQSP3Xnw5 ITaHFLr7bWDqMvD/ClvO3MAhvLlqxKl34JmYFV+ddtxuX8w8IRuroPuWkRWpLOLEoQAM 2EWyOC6fqsS9DCVYEi+ihE1UGPCu5K+F1dfPMlCCRO+Enn/Jv7pR4Rbh4L3b2ZThAbTf QSi99HFgXCBuelzxSXX9LV+ZdI1a/9X02eC3yeqrzQej+vCTs6VJnRsZrz+AupWFEOZn 23/g== X-Gm-Message-State: AHYfb5gTF8dxdQ/n+EIOYS5dxeRiMzhT6a8KwJwCanKi6K00E+Z8Saok LtH6478702VAXPNcjfi4lTtU1u7zq+xw5Gk= X-Received: by 10.31.3.205 with SMTP id f74mr300137vki.163.1503076683391; Fri, 18 Aug 2017 10:18:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.89.22 with HTTP; Fri, 18 Aug 2017 10:17:42 -0700 (PDT) In-Reply-To: References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> <166070f0-4ba1-70da-1f73-885b4a7f7640@gmail.com> <1502497178.4103451.1070917304.23DD466D@webmail.messagingengine.com> <598F9484.7020700@isdg.net> <599484FB.9050908@isdg.net> <1502929303.4038704.1075868960.5D80A788@webmail.messagingengine.com> <1502930858.4042926.1075890568.5069945B@webmail.messagingengine.com> From: Seth Blank Date: Fri, 18 Aug 2017 10:17:42 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a1142870cc8b47c05570a4f08" Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre 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 Aug 2017 17:18:10 -0000 --001a1142870cc8b47c05570a4f08 Content-Type: text/plain; charset="UTF-8" On Fri, Aug 18, 2017 at 10:08 AM, Dave Crocker wrote: > On 8/18/2017 10:00 AM, Seth Blank wrote: > >> >> Right now, we've got deployed code that we know works and improves the >> landscape. Everything else is - rightly or wrongly - conjecture. >> > > > Personal Point of order: > > Using an 'installed base' argument for a brand new specification that > is still in development and has minuscule deployment is not appropriate, in > spite of having a long and storied history of being used to resist a > proposal. > > What's supposed to happen with a proposal is an evaluation of its > technical and functional merits. > So let me be very clear, because I wasn't rehashing earlier conversations from this thread: Right now, everything in ARC serves a purpose, and the AS, AMS, and AAR are all defensible. As we've clarified ARC and dug into putting appropriate data into the AAR, the usefulness of the AS has gotten less apparent - but it still serves several purposes and has been explicitly asked for by several members of the working group. Right now, there is one person - with a valid concern - asking if we really need the AS. That conversation was dug into on list, and the consensus (which that person agreed to) was that his concerns might be right, but the point could be argued over forever with valid stances from both sides, or determined on its merits quite quickly once the ARC experiment begins. My point is, we can actually begin the experiment now. The open technical concerns are around "will this piece matter?" and they're more philosophical than technical (except for the AS concern, which might be practical) - but the data to answer them is at our fingertips, so let's go get the data. Seth > > > The entire point behind bringing a nascent specification to the IETF is to > get review and suggestions from a wider audience. > > > d/ > > > ps. Note that I haven't commented on the merits of this particular > proposal. I like the intent quite a bit, but haven't thought about the > technical or operational aspects yet. > > > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > --001a1142870cc8b47c05570a4f08 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Aug 18, 2017 at 10:08 AM, Dave Crocker <dcrocker@gmail.com> wrote:
On 8/18/2017= 10:00 AM, Seth Blank wrote:

Right now, we've got deployed code that we know works and improves the = landscape. Everything else is - rightly or wrongly - conjecture.


 Personal Point of order:

=C2=A0 =C2=A0Using an 'installed base' argument for a brand new spe= cification that is still in development and has minuscule deployment is not= appropriate, in spite of having a long and storied history of being used t= o resist a proposal.

=C2=A0 =C2=A0What's supposed to happen with a proposal is an evaluation= of its technical and functional merits.


So let me be very clear, because I wasn't rehashing ea= rlier conversations from this thread:

Right now, e= verything in ARC serves a purpose, and the AS, AMS, and AAR are all defensi= ble.

As we've clarified ARC and dug into putti= ng appropriate data into the AAR, the usefulness of the AS has gotten less = apparent - but it still serves several purposes and has been explicitly ask= ed for by several members of the working group.

Ri= ght now, there is one person - with a valid concern - asking if we really n= eed the AS. That conversation was dug into on list, and the consensus (whic= h that person agreed to) was that his concerns might be right, but the poin= t could be argued over forever with valid stances from both sides, or deter= mined on its merits quite quickly once the ARC experiment begins.

My point is, we can actually begin the experiment now. The = open technical concerns are around "will this piece matter?" and = they're more philosophical than technical (except for the AS concern, w= hich might be practical) - but the data to answer them is at our fingertips= , so let's go get the data.

Seth
=C2=A0


The entire point behind bringing a nascent specification to the IETF is to = get review and suggestions from a wider audience.


d/


ps. Note that I haven't commented on the merits of this particular prop= osal.=C2=A0 I like the intent quite a bit, but haven't thought about th= e technical or operational aspects yet.



--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

--001a1142870cc8b47c05570a4f08-- From nobody Fri Aug 18 11:10:24 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F5D126B71 for ; Fri, 18 Aug 2017 11:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkK5XiXVkvgD for ; Fri, 18 Aug 2017 11:10:21 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CA50120727 for ; Fri, 18 Aug 2017 11:10:21 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id a18so57944632qta.0 for ; Fri, 18 Aug 2017 11:10:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fzxnHC8KMLr3FzaO/Cw+6zlqzf/029C1e2smaUattQ4=; b=BxwNjBW/qMv8i8pcy9J8oS5A5o/mDMeem60I0mrY1Ey+NHmvQKGTBw4nputKZwB+NJ lW/Eq1dTeEzizi2uzf35SyxVDp5ApRXhdt1HcKzGXGdsa4YYq3VL/EaMze35R3tf7Kgn gyzfqmFU2mC2710+jvoDZqMtFM9OhRIVShMfz6wIiGl5qUDSxc7F/qzb9t8Z9vmsCTyb 8DUCmCM7ZUg7CE7zhsAQTSeNBVy9Aruyfw1hrD6eA8TiiSEe7TjFEDGbKFKfMWoe+p/B b6WsiwIz8JYOPKeJ4Ico1XfNJs4dpGYEjDsKRk1KBy3j6HBoKQZIKZ04jU0vv6J9aPxk ABog== 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=fzxnHC8KMLr3FzaO/Cw+6zlqzf/029C1e2smaUattQ4=; b=oyIHM4OMEIDVNzJHkFNPqrG1QkN4CGUiotsG5jCU+4Q5xDynYAdy22DnHdXFcuGZVb hNfvGvazqd9nH8VVrZzYLnSffyCoJcXmKUmPxxo3ZUueV6sNjB5ZE28C8AeCkRD9cDQl m/DcLtJ5Nm8KyXQ/yIdcZplAHRj0n31+I1rw4SNIFrJYEEp3NUamDPJWTjsSCY1zKuN5 ElBenNz1i8XaQourr9EL86F3p5yOMJPdjwNVDPU0FsZJhne9rEhU9IIvKmm81wUXJPPU 0JJxJWYTO02D7DyTErp7IXPiaplB6IrQjbNpWQYip3/DvRmrm6F+cJzRAxO1CB2XmUIT LI7w== X-Gm-Message-State: AHYfb5jdHYWnz55Ghz8BdlCMDF/k39YoicLFUbTiwRFM/bm65BHTwr4x 6T8s70kA/55C8lZ6/CsZpblx6EHV0w== X-Received: by 10.200.51.244 with SMTP id d49mr13306700qtb.32.1503079820382; Fri, 18 Aug 2017 11:10:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.57.34 with HTTP; Fri, 18 Aug 2017 11:10:19 -0700 (PDT) In-Reply-To: References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> <166070f0-4ba1-70da-1f73-885b4a7f7640@gmail.com> <1502497178.4103451.1070917304.23DD466D@webmail.messagingengine.com> <598F9484.7020700@isdg.net> <599484FB.9050908@isdg.net> <1502929303.4038704.1075868960.5D80A788@webmail.messagingengine.com> <1502930858.4042926.1075890568.5069945B@webmail.messagingengine.com> From: "Murray S. Kucherawy" Date: Fri, 18 Aug 2017 11:10:19 -0700 Message-ID: To: Dave Crocker Cc: Seth Blank , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a11c160e6c3594005570b0a7e" Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre 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 Aug 2017 18:10:23 -0000 --001a11c160e6c3594005570b0a7e Content-Type: text/plain; charset="UTF-8" On Fri, Aug 18, 2017 at 10:08 AM, Dave Crocker wrote: > On 8/18/2017 10:00 AM, Seth Blank wrote: > >> >> Right now, we've got deployed code that we know works and improves the >> landscape. Everything else is - rightly or wrongly - conjecture. >> > > > Personal Point of order: > > Using an 'installed base' argument for a brand new specification that > is still in development and has minuscule deployment is not appropriate, in > spite of having a long and storied history of being used to resist a > proposal. > > What's supposed to happen with a proposal is an evaluation of its > technical and functional merits. > > > The entire point behind bringing a nascent specification to the IETF is to > get review and suggestions from a wider audience. While I would normally agree firmly with that position, my view in this case is softer given what I believe was consensus (I'm not the chair, so that's not my call officially) that we're going to go for Experimental status. I submit that our primary mission here per our charter is to come up with a mechanism that mitigates DMARC's damage to mailing lists. The claim that ARC as designed over-engineers a solution seems secondary to me; the question we need to answer is "Can this mitigate the damage?" With or without Bron's reduced design, that's the question before us. The "snake oil" claim may be true but it's orthogonal to that core question, and moreover points to the way we describe what exactly ARC provides ("chain of custody" is clearly not appropriate given that we are no longer sure what that actually covers), independent of whether it tells us enough to solve the question at hand. Accordingly, I would suggest we continue to deploy and experiment with the specification as-is, because there are implementations now, until we've determined that ARC as currently defined does or does not address DMARC's mailing list issues. I also suggest that an appendix be added acknowledging that the super-crypto of ARC-Seal may be superfluous, and at the conclusion of the experiment we can make a decision about removing it and moving more toward what Bron's suggesting. Of course, the danger of proceeding along that line is that we do establish a deployed base, however small, that will be difficult to change later. I don't know the answer to that question immediately, and admittedly I'm only going to be on the periphery of cleaning up whatever mess results. -MSK --001a11c160e6c3594005570b0a7e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Aug 18, 2017 at 10:08 AM, Dave Crocker <dcrock= er@gmail.com> wrote:
On 8/18/20= 17 10:00 AM, Seth Blank wrote:

Right now, we've got deployed code that we know works and improves the = landscape. Everything else is - rightly or wrongly - conjecture.


 Personal Point of order:

=C2=A0 =C2=A0Using an 'installed base' argument for a brand new spe= cification that is still in development and has minuscule deployment is not= appropriate, in spite of having a long and storied history of being used t= o resist a proposal.

=C2=A0 =C2=A0What's supposed to happen with a proposal is an evaluation= of its technical and functional merits.


The entire point behind bringing a nascent specification to the IETF is to = get review and suggestions from a wider audience.

While I would normally agree firmly with that position, my view in t= his case is softer given what I believe was consensus (I'm not the chai= r, so that's not my call officially) that we're going to go for Exp= erimental status.=C2=A0

I submit that our pri= mary mission here per our charter is to come up with a mechanism that mitig= ates DMARC's damage to mailing lists.=C2=A0 The claim that ARC as desig= ned over-engineers a solution seems secondary to me; the question we need t= o answer is "Can this mitigate the damage?"=C2=A0 With or without= Bron's reduced design, that's the question before us.
The "snake oil" claim may be true but it's ortho= gonal to that core question, and moreover points to the way we describe wha= t exactly ARC provides ("chain of custody" is clearly not appropr= iate given that we are no longer sure what that actually covers), independe= nt of whether it tells us enough to solve the question at hand.

Accordingly, I would suggest we continue to deploy and ex= periment with the specification as-is, because there are implementations no= w, until we've determined that ARC as currently defined does or does no= t address DMARC's mailing list issues.=C2=A0 I also suggest that an app= endix be added acknowledging that the super-crypto of ARC-Seal may be super= fluous, and at the conclusion of the experiment we can make a decision abou= t removing it and moving more toward what Bron's suggesting.
=
Of course, the danger of proceeding along that line is that = we do establish a deployed base, however small, that will be difficult to c= hange later.=C2=A0 I don't know the answer to that question immediately= , and admittedly I'm only going to be on the periphery of cleaning up w= hatever mess results.

-MSK

--001a11c160e6c3594005570b0a7e-- From nobody Fri Aug 18 11:51:48 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7CE81321A1 for ; Fri, 18 Aug 2017 11:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fiction.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 A0dmbt-HoDII for ; Fri, 18 Aug 2017 11:51:43 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6E09126CB6 for ; Fri, 18 Aug 2017 11:51:42 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id r199so35058619vke.4 for ; Fri, 18 Aug 2017 11:51:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fiction.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wijAY5HgF6TtlfpCzWG5TdkPIRIFUJychXLSS1ilC2E=; b=J+ZgCMBQbDmGX+/n+dv4cbs3rf+ygMs0xFKMeaGJVyjLC23nnALCVym/tNccuP7hfn Mhaf62fRLI0su43UySO6kSsQMq96AWbykIAtyB80mG6vw3N1UVmCc6DzM+tf+E7GVg3O QjJ5aCXyl41n/vj8xwQx+f/tGTPLJGBUaja1/hNKNzp34OiztQeudDLL3I6P3dm6uNU/ hGvMPt9mJnDir7CcQaS1++mpRjffQxB8Fx4xZH+lMkEE6BAZ4ZTnikhULG7+PZpmaor0 t0ebZWClQZM3oDvx7hlTTkczco65tm2qN7/YeC5b/YjbDdJkDvTlyScrecapUhAwKeJA kZdA== 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=wijAY5HgF6TtlfpCzWG5TdkPIRIFUJychXLSS1ilC2E=; b=Xayhz1UYJtmOCsoO2ULbuoTHQtRmNtOscVPwn2KlWOuMuNvT0h66BBtIgOa6aCLthR 4sew2rcA1RRjJ+F2LpvoFSaTkqkm8F/aKsPpOd/tE5L/Mlfx+K2cagrfD7A4PEjB8kFt PnkcZAwunf27/mUh5SnErswGQOBF0v+nr9XZGvO29bLV+/b/x5BJm7Pou4bSUsDcC29+ aFtn8Xqg6sZE6w32Abc61KSMq2T1LWjMOxSH8qmSDgUe7eQ4k2Zg1arYp7Js78IGmh5+ uEdzqKSEEr1eOqbUuor/MsU/3MRVzcKW6lBISZuDpsiXi5Tc7iihKeCzkBJ3w+rZ2UA0 Qblg== X-Gm-Message-State: AHYfb5gXfVPVWTSd7tThN/EE1MOSqn4EFzYI7dORmWPIK8uENWPXahRs cJ7QtT2DejXiqMqQ+dM= X-Received: by 10.31.58.138 with SMTP id h132mr6109074vka.105.1503082301791; Fri, 18 Aug 2017 11:51:41 -0700 (PDT) Received: from mail-vk0-f41.google.com (mail-vk0-f41.google.com. [209.85.213.41]) by smtp.gmail.com with ESMTPSA id o85sm1312414vkd.24.2017.08.18.11.51.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Aug 2017 11:51:41 -0700 (PDT) Received: by mail-vk0-f41.google.com with SMTP id j189so35058257vka.0 for ; Fri, 18 Aug 2017 11:51:40 -0700 (PDT) X-Received: by 10.31.14.146 with SMTP id 140mr5980890vko.69.1503082300652; Fri, 18 Aug 2017 11:51:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.135.139 with HTTP; Fri, 18 Aug 2017 11:51:39 -0700 (PDT) In-Reply-To: References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> <166070f0-4ba1-70da-1f73-885b4a7f7640@gmail.com> <1502497178.4103451.1070917304.23DD466D@webmail.messagingengine.com> <598F9484.7020700@isdg.net> <599484FB.9050908@isdg.net> <1502929303.4038704.1075868960.5D80A788@webmail.messagingengine.com> <1502930858.4042926.1075890568.5069945B@webmail.messagingengine.com> From: Brandon Long Date: Fri, 18 Aug 2017 11:51:39 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Seth Blank Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a1145512099e25605570b9e42" Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre 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 Aug 2017 18:51:46 -0000 --001a1145512099e25605570b9e42 Content-Type: text/plain; charset="UTF-8" On Fri, Aug 18, 2017 at 10:00 AM, Seth Blank wrote: > On Thu, Aug 17, 2017 at 11:46 PM, Kurt Andersen wrote: > >> So I was able to retrace our design steps which led to the 3-piece model >> (AAR + AMS + AS) and the reasoning for the AS, signing just the ARC header >> sequence was to provide the verifiable chain of custody trace (though, of >> course, only from participating intermediaries). Some of the recent tweaks >> to the spec to deal with malformed sets of ARC header fields have weakened >> that original idea. >> >> In keeping with Bron's general idea to simplify, I'd suggest that having >> an AAR + [optional AMS] + AS would be a close approach for handling steps >> which do not break the ingress signature. Skipping the AMS would be a sign >> to downstream intermediaries that the prior DKIM or AMS was still valid >> upon egress. (certain details would have to be worked out) >> >> Does that help the conversation? >> > > No, I think this is a huge step in the wrong direction. > > Right now, we've got deployed code that we know works and improves the > landscape. Everything else is - rightly or wrongly - conjecture. > > Let's keep the tech stable and move to experimentation. > > If anything, this is an excellent question for receivers - when evaluating > AMS/AS, were there any situations where you required both signatures to > truly validate a chain and make a delivery decision, or with the added ARC > payload is now just having one sufficient? > I'm leary that removing the AMS on certain hops is the right choice, here. Without the AMS, the extra AAR/AS is not tied to this message directly, so I'm unsure how to handle any assertions made in the AAR. This also feels like the opposite of what Bron is asking for. I also proposed a month or so back some simplifying changes which were largely met with radio silence, that would have partially mitigated some of Bron's operational concerns, notably to either require the s/d be the same on AS/AMS or to eliminate the signature and s/d on AMS completely, switching the AMS to a hash that would then be covered by the AS. That doesn't reduce the number of crypto ops as much as his AMS only based proposal (which presumably would halt at the first broken AMS). Another option would be to change our expectations, that is to say that signing by non-modifying hops is optional. Brandon --001a1145512099e25605570b9e42 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Aug 18, 2017 at 10:00 AM, Seth Blank <seth@sethblank.com&= gt; wrote:
On Thu, Au= g 17, 2017 at 11:46 PM, Kurt Andersen <kurta@drkurt.com> wrot= e:
So I was able to retr= ace our design steps which led to the 3-piece model (AAR + AMS + AS) and th= e reasoning for the AS, signing just the ARC header sequence was to provide= the verifiable chain of custody trace (though, of course, only from partic= ipating intermediaries). Some of the recent tweaks to the spec to deal with= malformed sets of ARC header fields have weakened that original idea.
=
In keeping with Bron's general idea to simplify, I'd= suggest that having an AAR + [optional AMS] + AS would be a close approach= for handling steps which do not break the ingress signature. Skipping the = AMS would be a sign to downstream intermediaries that the prior DKIM or AMS= was still valid upon egress. (certain details would have to be worked out)=

Does that help the conversation?

No, I think this is a huge step in the w= rong direction.

Right now, we've got deployed = code that we know works and improves the landscape. Everything else is - ri= ghtly or wrongly - conjecture.

Let's keep the = tech stable and move to experimentation.

If anythi= ng, this is an excellent question for receivers - when evaluating AMS/AS, w= ere there any situations where you required both signatures to truly valida= te a chain and make a delivery decision, or with the added ARC payload is n= ow just having one sufficient?
I'm leary that removing the AMS on certain hops is the righ= t choice, here.=C2=A0 Without the AMS, the extra AAR/AS is not tied to this= message directly, so I'm unsure how to handle any assertions made in t= he AAR.=C2=A0 This also feels like the opposite of what Bron is asking for.=

I also proposed a month or so back some simplifying changes = which were largely met with radio silence, that would have partially mitiga= ted some of Bron's operational concerns, notably to either require the = s/d be the same on AS/AMS or to eliminate the signature and s/d on AMS comp= letely, switching the AMS to a hash that would then be covered by the AS.= =C2=A0 That doesn't reduce the number of crypto ops as much as his AMS = only based proposal (which presumably would halt at the first broken AMS).= =C2=A0

Another option would be to change our expec= tations, that is to say that signing by non-modifying hops is optional.

Brandon
--001a1145512099e25605570b9e42-- From nobody Fri Aug 18 16:00:29 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E8A13214D for ; Fri, 18 Aug 2017 16:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=h5U3jiFH; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=F1r/E8WH Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNCIOJ44qetR for ; Fri, 18 Aug 2017 16:00:26 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6979C1321EF for ; Fri, 18 Aug 2017 16:00:23 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id EC6A821A15 for ; Fri, 18 Aug 2017 19:00:11 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Fri, 18 Aug 2017 19:00:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=rdTYmgcIlcQYn/oAb 6dohBdejV7DWcmOhvSfOnkljEk=; b=h5U3jiFHamXlfKfb7Vd8M/Q6kx/xNAQ26 5kigh0fKZ/B7jmaNTCCX/DEKa0a4lQLJzqpUChF9yWQteJs2OC7zZ1d3ePKaaBgI 2SAVZhDaNWlBNUcKipc+aAEGCnTUgY0evWyUmbBfyHijSJfpJj6BFqAc4lS91pR5 yEJ9oE/lCf6DecugK7DvmG8GfSe8elEgjCVQJ3j6svkFuZuIhjixvAFyD7v9VCqB LAjVFApeAvt4VLe8W6XhhSdvhBkpKio9B8Gt05rQVjXoAj1HNeOCgVhTbIMBJv+/ ogvTZJ0RtZK376SN5Jb711MAxq+7fvvMQOlC+PDbK4NTkRZuMkNmA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=rdTYmg cIlcQYn/oAb6dohBdejV7DWcmOhvSfOnkljEk=; b=F1r/E8WHsPehfi4ONc7f/M UF7AM+G72wv5ersZoP7tfenR7tGUZLs5UGd94czgjE8yfmiQ09yRR1JDtNVH3QEM fYE1Zl3loJrWlJJLNCtSYi2a/mpLLROQ/6Y/EQXzqPo6Tb4nwO4iEljI+0Nic7La u6aRlLGicILvNI88zf5PYC2jTB+VC6YSCQrKzkojoeCS0+WWmJWxwLpio3oVi1dR DQ1r3qLcudKPifVLPpBykCWK1L+pCHZW3/+tnUf8J3FcQMFxwKsaNOMQ3BjiR19K JsKPDgwTlgUSBqklovvgymKlOv7nCjAzZcOnfqyScpkZskdm59ahBpyQ47iJLr3w == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id B5051BAB71; Fri, 18 Aug 2017 19:00:11 -0400 (EDT) Message-Id: <1503097211.2660113.1078081592.5E09F4F1@webmail.messagingengine.com> From: Bron Gondwana To: dmarc@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150309721126601131" X-Mailer: MessagingEngine.com Webmail Interface - ajax-21c69044 Date: Sat, 19 Aug 2017 09:00:11 +1000 References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> <166070f0-4ba1-70da-1f73-885b4a7f7640@gmail.com> <1502497178.4103451.1070917304.23DD466D@webmail.messagingengine.com> <598F9484.7020700@isdg.net> <599484FB.9050908@isdg.net> <1502929303.4038704.1075868960.5D80A788@webmail.messagingengine.com> <1502930858.4042926.1075890568.5069945B@webmail.messagingengine.com> In-Reply-To: Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre 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 Aug 2017 23:00:29 -0000 This is a multi-part message in MIME format. --_----------=_150309721126601131 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Fri, 18 Aug 2017, at 16:46, Kurt Andersen wrote: > So I was able to retrace our design steps which led to the 3-piece > model (AAR + AMS + AS) and the reasoning for the AS, signing just the > ARC header sequence was to provide the verifiable chain of custody > trace (though, of course, only from participating intermediaries). > Some of the recent tweaks to the spec to deal with malformed sets of > ARC header fields have weakened that original idea. The problem with the verifiable chain of custody trace is that isn't actually verifiable, because anybody can break an old chain at any point and mint a new link that looks as if the message was sent to them. You can take an email that went A => B => C => D => E with an intact ARC chain and chop the top off, edit everything and create: A => B => X => Y If you're X, and there's no way to tell from the ARC headers that B didn't originally send a message to X. > In keeping with Bron's general idea to simplify, I'd suggest that > having an AAR + [optional AMS] + AS would be a close approach for > handling steps which do not break the ingress signature. Skipping the > AMS would be a sign to downstream intermediaries that the prior DKIM > or AMS was still valid upon egress. (certain details would have to be > worked out)> > Does that help the conversation? On this I agree with Seth. removing AMS breaks AS, and I see even less value in keeping AS if it doesn't even keep verifying all the way back to the start. Bron.-- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_150309721126601131 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Fri, 18 Aug 2017, at 16:46, Kurt Andersen wrote:
So I was able to retrace our design steps which led to the 3-piece model (AAR + AMS + AS) and the reasoning for the AS, signing just the ARC header sequence was to provide the verifiable chain of custody trace (though, of course, only from participating intermediaries). Some of the recent tweaks to the spec to deal with malformed sets of ARC header fields have weakened that original idea.

The problem with the verifiable chain of custody trace is that isn't actually verifiable, because anybody can break an old chain at any point and mint a new link that looks as if the message was sent to them.

You can take an email that went

A => B => C => D => E with an intact ARC chain and chop the top off, edit everything and create:

A => B => X => Y

If you're X, and there's no way to tell from the ARC headers that B didn't originally send a message to X.

In keeping with Bron's general idea to simplify, I'd suggest that having an AAR + [optional AMS] + AS would be a close approach for handling steps which do not break the ingress signature. Skipping the AMS would be a sign to downstream intermediaries that the prior DKIM or AMS was still valid upon egress. (certain details would have to be worked out)

Does that help the conversation?

On this I agree with Seth.  removing AMS breaks AS, and I see even less value in keeping AS if it doesn't even keep verifying all the way back to the start.

Bron.

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


--_----------=_150309721126601131-- From nobody Fri Aug 18 16:20:46 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5701113214D for ; Fri, 18 Aug 2017 16:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVp-y_JVgibW for ; Fri, 18 Aug 2017 16:20:43 -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 3E064132064 for ; Fri, 18 Aug 2017 16:20:43 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id x3so110754133oia.1 for ; Fri, 18 Aug 2017 16:20:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=BDiO+TvGhA96paPAULw4BP44wpO1lO4XGKdW2oGxfTU=; b=i8r6R1WcdjCYqs9XjZkWkfj90L7e4nvmGybxH0KuKc7g5N/pLWdCun3R2Qq2GXwjTU UbLfuihatuSmbw9WHXSt6msXy28GCBpTbmucCICILhtJvWqWoXcjO7jfRu12DltRnI0s bRguvXB3HQKqvG6SaBCNmHnUivnM5xdTHFHXuxMJ+0wk8PSQl1cUmoQ0woDQjcwMRYPB lUceME3ePDTKzYDb7if/RAN5BJY6puKpOulV9tJc5tu09xLsRcBz+34TL1sdnxMdm4Cx 1KEnbAUZzGW0WCGGhbYpNsX5dC+NjXBe+nhq4hD6XT+gfnmgreR4hAUvpUyBWJJ9Aapd hQGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=BDiO+TvGhA96paPAULw4BP44wpO1lO4XGKdW2oGxfTU=; b=Xc+k/oB33wYN/+5rnEvWgr5wIm2AnxLk6EwYVr245t3LA7sOBzvEi1Vu9mGn/hyPPh dZT9/Nycqbs/cm5bXBKJh/u9GovE+6GL7E0LvVF9wkioRfIL8Yv2+E9HS1On95UgN+t0 EKBfqy4l6UfCfyct8eJkZFDPXn5UmNECog89Pd+u+AOL/jf/Mg9QHuIwY0QkSa5Oehlh uZEJK6jblihgfWJl7QqgrL2NL4RRRC5VQ813ou6+/ytPHQwyuHu4PnLa+KUsJiMUUo0A hUjlWsqkI+25/DxbZbZFhoSiz7dX5sMnnRjckGtUnulCFlnh1UugQkXmol+2s1oMnFA6 Vx1w== X-Gm-Message-State: AHYfb5hwnqI5+3zT3/JqhO2+EXTR/q5OGD4GMSM1SQREuXL+r/7vrAAK ZpTVu/vFjnUf8zKG9O0= X-Received: by 10.202.235.140 with SMTP id j134mr12943539oih.281.1503098442016; Fri, 18 Aug 2017 16:20:42 -0700 (PDT) Received: from ?IPv6:2602:304:cda0:8800:d17e:7fe3:9cb7:7c98? ([2602:304:cda0:8800:d17e:7fe3:9cb7:7c98]) by smtp.gmail.com with ESMTPSA id h138sm4964513oic.43.2017.08.18.16.20.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Aug 2017 16:20:40 -0700 (PDT) To: "Murray S. Kucherawy" Cc: Seth Blank , "dmarc@ietf.org" References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> <166070f0-4ba1-70da-1f73-885b4a7f7640@gmail.com> <1502497178.4103451.1070917304.23DD466D@webmail.messagingengine.com> <598F9484.7020700@isdg.net> <599484FB.9050908@isdg.net> <1502929303.4038704.1075868960.5D80A788@webmail.messagingengine.com> <1502930858.4042926.1075890568.5069945B@webmail.messagingengine.com> From: Dave Crocker Message-ID: <74033d99-6425-3676-e39e-64e1c947fb16@gmail.com> Date: Fri, 18 Aug 2017 16:20:37 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre 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 Aug 2017 23:20:45 -0000 On 8/18/2017 11:10 AM, Murray S. Kucherawy wrote: > > While I would normally agree firmly with that position, my view in this > case is softer given what I believe was consensus (I'm not the chair, so > that's not my call officially) that we're going to go for Experimental > status. > > I submit that our primary mission here per our charter is to come up > with a mechanism that mitigates DMARC's damage to mailing lists.  The > claim that ARC as designed over-engineers a solution seems secondary to > me; the question we need to answer is "Can this mitigate the damage?" > With or without Bron's reduced design, that's the question before us. Going for Experimental does not relieve the working group from trying to do careful engineering. I'm sure you didn't mean to suggest otherwise, but fear that the result will be publishing a spec for something that is more complicated than it needs to be or less well understood than it needs to be. Or both. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Aug 18 17:26:41 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 365241323F9 for ; Fri, 18 Aug 2017 17:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=TQx638bm; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZdTkArek Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZueH_5HbZbp4 for ; Fri, 18 Aug 2017 17:26:37 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00E011323AA for ; Fri, 18 Aug 2017 17:26:36 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 4AA5D22120 for ; Fri, 18 Aug 2017 20:26:36 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Fri, 18 Aug 2017 20:26:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=IXNXEmOTen5d84vYs J+rjNNPBQcJzLew2aVlzK9fRLk=; b=TQx638bmh3rLNRiyw2wq3w5V03R+JOFKa +44WiTN8fK8OxcZamcUdCrvfDg7NaHE5KhSSRwdf7t1bk5XTfP8ztXiIeKamSipy I8PU1OCrbjymyS4Vz5CHhpRcIIho/rAqwn639WhP+PKhL1WYIBwy7QpeS/7VkAta vwDj8XDHmsbiEhk7BpGF06HQ28gWzjRfwQLFt6X6xYET6y/LMTtI0gJJKT+FjyHZ hF5jfVPj0d/HKJR6cKuUf47YAP6uYk71GkBvu4pXkRq50Yr5mBSblTUd99O+uvdu wUOzw0TdmCUNmy8qWq4TffegGkzwAU813txMK50OZMoa97oBudOIA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=IXNXEm OTen5d84vYsJ+rjNNPBQcJzLew2aVlzK9fRLk=; b=ZdTkArekYsI7bE1FX53O8f RkMXf03sNjdiOXXGV1e72WZUugDg8kOc1M2CGrWaH68aReq6Ih5Wp22mMLx0wRjS EYvjbRuSHQLt8wUPkC4Ll+oDUxvNgx53w+dlzgGejYk35Yevnv9ZI4fFlAJaTevV n7blI+VELc9qN/GhbGXP2pzd7VFYfLE24cTG2j5As2uggOFlGfN8mlUJA6alKE+z yX8/LwhJhpZx/+c21o4oK0zJt+nF9zompaqOBop7stkQH2DiYEDJpoRPwKTGdd2+ BmkWqCgoFIcV9Kzh7tdeXRdI7HQ9g5TcoS6I5fl7CV7LnzAppCfo/dU/h2ryQNiQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 0D3F1BAB71; Fri, 18 Aug 2017 20:26:36 -0400 (EDT) Message-Id: <1503102395.2676097.1078114248.6DB98C8B@webmail.messagingengine.com> From: Bron Gondwana To: dmarc@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/mixed; boundary="_----------=_150310239526760975" X-Mailer: MessagingEngine.com Webmail Interface - ajax-21c69044 References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> <166070f0-4ba1-70da-1f73-885b4a7f7640@gmail.com> <1502497178.4103451.1070917304.23DD466D@webmail.messagingengine.com> <598F9484.7020700@isdg.net> <599484FB.9050908@isdg.net> <1502929303.4038704.1075868960.5D80A788@webmail.messagingengine.com> <1502930858.4042926.1075890568.5069945B@webmail.messagingengine.com> Date: Sat, 19 Aug 2017 10:26:35 +1000 In-Reply-To: Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Aug 2017 00:26:40 -0000 This is a multi-part message in MIME format. --_----------=_150310239526760975 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150310239526760974" This is a multi-part message in MIME format. --_----------=_150310239526760974 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Sat, 19 Aug 2017, at 04:10, Murray S. Kucherawy wrote: > On Fri, Aug 18, 2017 at 10:08 AM, Dave Crocker > wrote:>> On 8/18/2017 10:00 AM, Seth Blank wrote: >>> >>> Right now, we've got deployed code that we know works and improves >>> the landscape. Everything else is - rightly or wrongly - conjecture.>> >> >> Personal Point of order: >> >> Using an 'installed base' argument for a brand new specification >> that is still in development and has minuscule deployment is not >> appropriate, in spite of having a long and storied history of >> being used to resist a proposal.>> >> What's supposed to happen with a proposal is an evaluation of its >> technical and functional merits.>> >> >> The entire point behind bringing a nascent specification to the IETF >> is to get review and suggestions from a wider audience.> > While I would normally agree firmly with that position, my view in > this case is softer given what I believe was consensus (I'm not the > chair, so that's not my call officially) that we're going to go for > Experimental status.> > I submit that our primary mission here per our charter is to come up > with a mechanism that mitigates DMARC's damage to mailing lists. The > claim that ARC as designed over-engineers a solution seems secondary > to me; the question we need to answer is "Can this mitigate the > damage?" With or without Bron's reduced design, that's the question > before us. Yes, this is the crux of the question. > The "snake oil" claim may be true but it's orthogonal to that core > question, and moreover points to the way we describe what exactly ARC > provides ("chain of custody" is clearly not appropriate given that we > are no longer sure what that actually covers), independent of whether > it tells us enough to solve the question at hand.> > Accordingly, I would suggest we continue to deploy and experiment with > the specification as-is, because there are implementations now, until > we've determined that ARC as currently defined does or does not > address DMARC's mailing list issues. I also suggest that an appendix > be added acknowledging that the super-crypto of ARC-Seal may be > superfluous, and at the conclusion of the experiment we can make a > decision about removing it and moving more toward what Bron's > suggesting.> > Of course, the danger of proceeding along that line is that we do > establish a deployed base, however small, that will be difficult to > change later. I don't know the answer to that question immediately, > and admittedly I'm only going to be on the periphery of cleaning up > whatever mess results. Well, let's have a look at the question - can ARC mitigate the damage? It depends what p=reject means. Right now Brandon can't email this list with his blong@google.com address, because google.com publishes a p=reject record. If the list supported ARC, he could email this list and receivers which supported ARC would accept the email from the list despite the p=reject record. Yay. I could also take a message from the list, rewrite the subject and content to be my own, sign it with my own key from my own domain, send that to somebody as it if had come from Brandon, and assuming they supported ARC, they would also accept that email, depite the p=reject record. Boo. p=reject no longer stopped me sending a fraudulent email claiming to be from Brandon with a "From:" of his official work address. The receving site now needs to run heuristics including content analysis and trust metrics on every hop in the ARC chain to determine whether to accept the message. That's fine, but we've basically mitigated DMARC breakage of mailing lists by rolling back the meaning of DMARC p=reject. Anyone can create an ARC seal on any email. It doesn't even have to have an original ARC seal on it. Attached is an email which purports to be from Brandon and has a valid ARC-Seal on it (assuming my code works correctly - it adds the c= parameter now after Seth pointed out that opendkim doesn't handle leaving it out). Somebody from Google might be able to tell which email I based this on (an email on Aug 9th to this list and CCd to me which then got resent from a different address) This will be accepted by an ARC-aware receiver unless I'm on a blacklist, despite the p=reject. Creating a new domain and putting a key in its DNS is pretty trivial - so I guess the question is, what is ARC doing other than rolling back DMARC p=reject entirely? We'd better think about that deeply, because spammers/scammers sure will be. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_150310239526760974 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Sat, 19 Aug 2017, at 04:10, Murray S. Kucherawy wrote:
On Fri, Aug 18, 2017 at 10:08 AM, Dave Crocker <dcrocker@gmail.com> wrote:
On 8/18/2017 10:00 AM, Seth Blank wrote:

Right now, we've got deployed code that we know works and improves the landscape. Everything else is - rightly or wrongly - conjecture.


Personal Point of order:

   Using an 'installed base' argument for a brand new specification that is still in development and has minuscule deployment is not appropriate, in spite of having a long and storied history of being used to resist a proposal.

   What's supposed to happen with a proposal is an evaluation of its technical and functional merits.


The entire point behind bringing a nascent specification to the IETF is to get review and suggestions from a wider audience.

While I would normally agree firmly with that position, my view in this case is softer given what I believe was consensus (I'm not the chair, so that's not my call officially) that we're going to go for Experimental status. 

I submit that our primary mission here per our charter is to come up with a mechanism that mitigates DMARC's damage to mailing lists.  The claim that ARC as designed over-engineers a solution seems secondary to me; the question we need to answer is "Can this mitigate the damage?"  With or without Bron's reduced design, that's the question before us.

Yes, this is the crux of the question.

The "snake oil" claim may be true but it's orthogonal to that core question, and moreover points to the way we describe what exactly ARC provides ("chain of custody" is clearly not appropriate given that we are no longer sure what that actually covers), independent of whether it tells us enough to solve the question at hand.

Accordingly, I would suggest we continue to deploy and experiment with the specification as-is, because there are implementations now, until we've determined that ARC as currently defined does or does not address DMARC's mailing list issues.  I also suggest that an appendix be added acknowledging that the super-crypto of ARC-Seal may be superfluous, and at the conclusion of the experiment we can make a decision about removing it and moving more toward what Bron's suggesting.

Of course, the danger of proceeding along that line is that we do establish a deployed base, however small, that will be difficult to change later.  I don't know the answer to that question immediately, and admittedly I'm only going to be on the periphery of cleaning up whatever mess results.

Well, let's have a look at the question - can ARC mitigate the damage?  It depends what p=reject means.

Right now Brandon can't email this list with his blong@google.com address, because google.com publishes a p=reject record.  If the list supported ARC, he could email this list and receivers which supported ARC would accept the email from the list despite the p=reject record.  Yay.

I could also take a message from the list, rewrite the subject and content to be my own, sign it with my own key from my own domain, send that to somebody as it if had come from Brandon, and assuming they supported ARC, they would also accept that email, depite the p=reject record.  Boo.

p=reject no longer stopped me sending a fraudulent email claiming to be from Brandon with a "From:" of his official work address.

The receving site now needs to run heuristics including content analysis and trust metrics on every hop in the ARC chain to determine whether to accept the message.  That's fine, but we've basically mitigated DMARC breakage of mailing lists by rolling back the meaning of DMARC p=reject.  Anyone can create an ARC seal on any email.  It doesn't even have to have an original ARC seal on it.  Attached is an email which purports to be from Brandon and has a valid ARC-Seal on it (assuming my code works correctly - it adds the c= parameter now after Seth pointed out that opendkim doesn't handle leaving it out).  Somebody from Google might be able to tell which email I based this on (an email on Aug 9th to this list and CCd to me which then got resent from a different address)

This will be accepted by an ARC-aware receiver unless I'm on a blacklist, despite the p=reject.

Creating a new domain and putting a key in its DNS is pretty trivial - so I guess the question is, what is ARC doing other than rolling back DMARC p=reject entirely?  We'd better think about that deeply, because spammers/scammers sure will be.

Bron.

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


--_----------=_150310239526760974-- --_----------=_150310239526760975 Content-Disposition: attachment; filename="onearc.txt" Content-Id: <1503102086.2675254.73398242b54caf79df66a2a37e792f0adf8d28a8.7B15B94B@content.messagingengine.com> Content-Transfer-Encoding: base64 Content-Type: text/plain; name="onearc.txt" QVJDLVNlYWw6IGk9MTsgYT1yc2Etc2hhMjU2OyBjdj1wYXNzOyBkPWJyb25n Lm5ldDsgcz1mbTE7IGJoPTQ3REVRcGo4SEJTDQoJYSsvVEltVys1SkNldVFl UmttNU5NcEpXWkczaFN1RlU9OyBiPXkwSWo3NExzV2U3ZFlzZFNTOTVpd1c2 VDhYbg0KCXc3YnMvVzhVMmR2dEtOdEszbEppK0lCaVMwZWx1RmJSRytPNlJS ck5JOW9PWGlUTjlzWTFzSWJMamptdjU0aHYNCglLOXdiS2VQQ01WeGxIejBK L094Qm1td3hnTGtpaktZOUo5V3htVzZJL04rQlRlVlpDQ2tKUFlkSmtuUmVT d0NBDQoJZVFWOWVzTVE4RjM3VlBidzV2NnYxV1dnV0pjMUVrOFF3REp0cC84 SGlVMEVGeUUwcWhzRzZKMWl5Y1JCbFFESg0KCUM5MjJtUFhhYWlBaXB5YVB6 OFErOEF6TFBoWnVSaHVmNHRva0IvRjFQeG9PRkV2d2hmV01laS9uc3VRc21n YW8NCglXR0tkZ0xuRlZGcXJtYWIrRkcyTHRSSnVWUjVUM2N2ajdtd3M2Q0h5 R01QVGtGN3dhU2tjWVpWNk1EZz09DQpBUkMtTWVzc2FnZS1TaWduYXR1cmU6 IGk9MTsgYT1yc2Etc2hhMjU2OyBjPXJlbGF4ZWQvcmVsYXhlZDsgZD0NCgli cm9uZy5uZXQ7IGg9bWltZS12ZXJzaW9uOmZyb206ZGF0ZTptZXNzYWdlLWlk OnN1YmplY3Q6dG8NCgk6Y29udGVudC10eXBlOyBzPWZtMTsgYmg9eWMvV3pK a2oySmViaC9za1krc2pZazZXZGdLSkc5SUwwWHJqVmk5DQoJQ2NCST07IGI9 YWdwQTMzZFJQbExCSjdCcmk1LzkycGllS1pwWEhROUhrT2FlVEZGSlozeUg4 TURxWmJrUWtWdQ0KCUtBWmtIN2dFMmVMV1lMUU0rSlp2YVJTamRFRDFFck5i OXJ3d1RHbVJaV3dxUk1acjl2WEZpTnVzTFRZN1VEeUwNCglRM0c2Q0V1aXlk TGlYMDZXOHFjV1dTb09kbU5DL1NteGJvNTlvYkhrTVNCdFFObnNQZ2g0OEw4 dGlSbmhlNjFvDQoJb2FEcklmQUtyZlo4ZnFQZDY3cE9JZUhEQW13K3hrK0Nl aTFua1Y0MmhQZjd3d2pzalVsTWx1Tlo1SDl0YnltQQ0KCUtDdk85MTAvNlI2 bjdPQ20zc251MlhDTGViVUNRR2F2NERsYzg2RWRKZ1Q2RHZKZmhWd3IvM1pV UDhJRi9wL0ENCgl2bXRvOXF0d3p5WVQwNitSSlVFVE96QnpuYjZsRkd3PT0N CkFSQy1BdXRoZW50aWNhdGlvbi1SZXN1bHRzOiBpPTE7IG14Mi5tZXNzYWdp bmdlbmdpbmUuY29tOw0KICAgIGRraW09cGFzcyAoMjA0OC1iaXQgcnNhIGtl eSBzaGEyNTYpIGhlYWRlci5kPWdvb2dsZS5jb20gaGVhZGVyLmk9QGdvb2ds ZS5jb20gaGVhZGVyLmI9RzNDSlNOT0M7DQogICAgZG1hcmM9cGFzcyBoZWFk ZXIuZnJvbT1nb29nbGUuY29tOw0KICAgIHNwZj1wYXNzIHNtdHAubWFpbGZy b209YmxvbmdAZ29vZ2xlLmNvbSBzbXRwLmhlbG89bWFpbC1vaTAtZjUyLmdv b2dsZS5jb207DQogICAgeC1nb29nbGUtZGtpbT1wYXNzICgyMDQ4LWJpdCBy c2Ega2V5KSBoZWFkZXIuZD0xZTEwMC5uZXQgaGVhZGVyLmk9QDFlMTAwLm5l dCBoZWFkZXIuYj1KelBiQjl4RQ0KQXV0aGVudGljYXRpb24tUmVzdWx0czog bXgyLm1lc3NhZ2luZ2VuZ2luZS5jb207DQogICAgZGtpbT1wYXNzICgyMDQ4 LWJpdCByc2Ega2V5IHNoYTI1NikgaGVhZGVyLmQ9Z29vZ2xlLmNvbSBoZWFk ZXIuaT1AZ29vZ2xlLmNvbSBoZWFkZXIuYj1HM0NKU05PQzsNCiAgICBkbWFy Yz1wYXNzIGhlYWRlci5mcm9tPWdvb2dsZS5jb207DQogICAgc3BmPXBhc3Mg c210cC5tYWlsZnJvbT1ibG9uZ0Bnb29nbGUuY29tIHNtdHAuaGVsbz1tYWls LW9pMC1mNTIuZ29vZ2xlLmNvbTsNCiAgICB4LWdvb2dsZS1ka2ltPXBhc3Mg KDIwNDgtYml0IHJzYSBrZXkpIGhlYWRlci5kPTFlMTAwLm5ldCBoZWFkZXIu aT1AMWUxMDAubmV0IGhlYWRlci5iPUp6UGJCOXhFDQpSZWNlaXZlZC1TUEY6 IHBhc3MNCiAgICAoZ29vZ2xlLmNvbTogU2VuZGVyIGlzIGF1dGhvcml6ZWQg dG8gdXNlICdibG9uZ0Bnb29nbGUuY29tJyBpbiAnbWZyb20nIGlkZW50aXR5 IChtZWNoYW5pc20gJ2luY2x1ZGU6X3NwZi5nb29nbGUuY29tJyBtYXRjaGVk KSkNCiAgICByZWNlaXZlcj1teDIubWVzc2FnaW5nZW5naW5lLmNvbTsNCiAg ICBpZGVudGl0eT1tYWlsZnJvbTsNCiAgICBlbnZlbG9wZS1mcm9tPSJibG9u Z0Bnb29nbGUuY29tIjsNCiAgICBoZWxvPW1haWwtb2kwLWY1Mi5nb29nbGUu Y29tOw0KICAgIGNsaWVudC1pcD0yMDkuODUuMjE4LjUyDQpSZWNlaXZlZDog ZnJvbSBtYWlsLW9pMC1mNTIuZ29vZ2xlLmNvbSAobWFpbC1vaTAtZjUyLmdv b2dsZS5jb20gWzIwOS44NS4yMTguNTJdKQ0KICAgICh1c2luZyBUTFN2MS4y IHdpdGggY2lwaGVyIEVDREhFLVJTQS1BRVMxMjgtR0NNLVNIQTI1NiAoMTI4 LzEyOCBiaXRzKSkNCiAgICAoTm8gY2xpZW50IGNlcnRpZmljYXRlIHJlcXVl c3RlZCkNCiAgICBieSBteDIubWVzc2FnaW5nZW5naW5lLmNvbSAoUG9zdGZp eCkgd2l0aCBFU01UUFMNCiAgICBmb3IgPGJyb25nQGZhc3RtYWlsdGVhbS5j b20+OyBXZWQsICA5IEF1ZyAyMDE3IDIwOjQxOjMzIC0wNDAwIChFRFQpDQpS ZWNlaXZlZDogYnkgbWFpbC1vaTAtZjUyLmdvb2dsZS5jb20gd2l0aCBTTVRQ IGlkIGYxMXNvNjE3NTAyOTBvaWMuMA0KICAgICAgICBmb3IgPGJyb25nQGZh c3RtYWlsdGVhbS5jb20+OyBXZWQsIDA5IEF1ZyAyMDE3IDE3OjQxOjMzIC0w NzAwIChQRFQpDQpES0lNLVNpZ25hdHVyZTogdj0xOyBhPXJzYS1zaGEyNTY7 IGM9cmVsYXhlZC9yZWxheGVkOw0KICAgICAgICBkPWdvb2dsZS5jb207IHM9 MjAxNjEwMjU7DQogICAgICAgIGg9bWltZS12ZXJzaW9uOmluLXJlcGx5LXRv OnJlZmVyZW5jZXM6ZnJvbTpkYXRlOm1lc3NhZ2UtaWQ6c3ViamVjdDp0bw0K ICAgICAgICAgOmNjOw0KICAgICAgICBiaD16WTZkT2VQM2xMLzhtQ3dVQXE5 WkVVNkVhTWZScno5ZWlzYjVqRk5Da0F3PTsNCiAgICAgICAgYj1HM0NKU05P Q0c5c0xmbm5HbXJ5MEpBczExVFJwQXFhZnZoaDdqUEdobCtWaDJQcUdUenVj N3c2cFJ2THlkZ0hVN0UNCiAgICAgICAgIENydW1vZDR1eFIzTERNS1Z1a3NX S0F6RGJobnpHTlNoYTB2b3hrNEV5VENXbXB1dDhVQllRWCtsWUlkc1dmY0Nh YVI0DQogICAgICAgICB5UFZpUFAxUnNJaGpBRUZmbGdSYm55THZpdlN6SWtK NlBiRXNVSDBObElKZGZ4VUlJMVJwbG9oYXQ0dTlVSHloUTdiQw0KICAgICAg ICAgOE1XTnhqdkZaYTQ3Rmo5dkRPYWU4b252UjhCekRXRE9TcnpRYjJGL2x2 c3BiOU9MOHYxcGdad25zemRCbGdSb3FjNEQNCiAgICAgICAgIElLRUtLRmlt NkJ6VldlVWR0VTY5Ky9jd0VQZnVkUGRod2YrQXlFQVQya1hST1lRZVREUlF5 SzB6eElmWFlNbUE3aE40DQogICAgICAgICB6L2RBPT0NClgtR29vZ2xlLURL SU0tU2lnbmF0dXJlOiB2PTE7IGE9cnNhLXNoYTI1NjsgYz1yZWxheGVkL3Jl bGF4ZWQ7DQogICAgICAgIGQ9MWUxMDAubmV0OyBzPTIwMTYxMDI1Ow0KICAg ICAgICBoPXgtZ20tbWVzc2FnZS1zdGF0ZTptaW1lLXZlcnNpb246aW4tcmVw bHktdG86cmVmZXJlbmNlczpmcm9tOmRhdGUNCiAgICAgICAgIDptZXNzYWdl LWlkOnN1YmplY3Q6dG86Y2M7DQogICAgICAgIGJoPXpZNmRPZVAzbEwvOG1D d1VBcTlaRVU2RWFNZlJyejllaXNiNWpGTkNrQXc9Ow0KICAgICAgICBiPUp6 UGJCOXhFSytMekFhdmE4ZWZMdmswa1FXU2ptOURveVJPYXpwbk5Kd2xwV2E2 THFHWmFCdE10VVdjbmc0WUtwTw0KICAgICAgICAgbnB5YllPMDZLdDYvYzN1 bWVBcjFGbzZYUEpGaHlVU0sxQmQxN0prdVM2KzlxTFNlRlJmN3FpVnRjbkNx UnFnNXVHVjENCiAgICAgICAgIFpUb2h5VHRpcGpKTWZBUnRFVWZCckpVbStU QVlnQWgvYTAvL09xRzFRY0dHZjczbU9meHpjVXIrUiszYW9lQmVKTDV6DQog ICAgICAgICB5WjgrQ1ArWmhnYUg5VTZIYzhqa0ZsMnIrbkdEWStqcE1UWkpX ckhmcC9ES0thelZMc1p2cTRvVEV2cWpBZ2oySy8ycw0KICAgICAgICAganNu V0JESng3RllIYWhkRmxTazhMZWZpWmFTd1hOR0NVQU9wL3YvYlo2QXM4bzZi QVRleDFTcDVUdnJCYzhNUTVPV1UNCiAgICAgICAgIFNjc2c9PQ0KWC1HbS1N ZXNzYWdlLVN0YXRlOiBBSFlmYjVoYWtNbmFlK21MRlFJbGhzUHAyUFVTM2dU Nk5YWllKTjZQUXhRMFRwYTE2UXEvT01LRA0KICAgIDFIbEJvK1g3c205cGxX UWxUcDlEdnZseVdiNkFWVWFOcWFVPQ0KWC1SZWNlaXZlZDogYnkgMTAuMjAy LjE4NC44IHdpdGggU01UUCBpZCBpOG1yMTEyOTg4NDZvaWYuMjY2LjE1MDIz MjU2OTE1Mzk7DQogV2VkLCAwOSBBdWcgMjAxNyAxNzo0MTozMSAtMDcwMCAo UERUKQ0KTUlNRS1WZXJzaW9uOiAxLjANClJlY2VpdmVkOiBieSAxMC43NC4x NTQuNTEgd2l0aCBIVFRQOyBXZWQsIDkgQXVnIDIwMTcgMTc6NDE6MjkgLTA3 MDAgKFBEVCkNClJlY2VpdmVkOiBieSAxMC43NC4xNTQuNTEgd2l0aCBIVFRQ OyBXZWQsIDkgQXVnIDIwMTcgMTc6NDE6MjkgLTA3MDAgKFBEVCkNCkZyb206 IEJyYW5kb24gTG9uZyA8YmxvbmdAZ29vZ2xlLmNvbT4NCkRhdGU6IEZyaSwg MTggQXVnIDIwMTcgMTI6NDE6MjkgLTA3MDANCk1lc3NhZ2UtSUQ6IDxDMkJh OFI2dktXMHRoTkFncmJ5S3o5Sjh5RzNHc2lZZDExVWVkMnl1ZzdTak1tcDJh cVFAbWFpbC5nbWFpbC5jb20+DQpTdWJqZWN0OiB0aGlzIGlzIGEgZmFrZSBt ZXNzYWdlDQpUbzogZG1hcmNAaWV0Zi5vcmcNCkNvbnRlbnQtVHlwZTogdGV4 dC9wbGFpbjsgY2hhcnNldD0iVVRGLTgiDQoNClRoaXMgaXMgYSBmYWtlIG1l c3NhZ2UNCg== --_----------=_150310239526760975-- From nobody Fri Aug 18 17:40:46 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8C951323A0 for ; Fri, 18 Aug 2017 17:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=t4Zzfvi+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Tb/Y/Rvb Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9U51kGJpYt8q for ; Fri, 18 Aug 2017 17:40:42 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7C52132223 for ; Fri, 18 Aug 2017 17:40:42 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 3BB5E22169 for ; Fri, 18 Aug 2017 20:40:42 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Fri, 18 Aug 2017 20:40:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=SeZgjiGWJXLJh5aML g4ATAAItC1DlwwlX/bKJC0PG0k=; b=t4Zzfvi+jLgQ0/wNFM0mXwQOFkz7pqQ5s G+eP1mFmxxWqZ+/be6ee9Y+CO68kmIWn5ZQIyj3taNpEKGL8P4n+pB9jAwtU7c5d 4BMWnEz/ocahI8+bvojOqmdWgpIkM8rLH7Z2bfUPe3ogUBITMsiX5JVbWSjRLTNW f7sGkLx67KKNcQkw7niJkT1fx8AGDMXlca1LNRfoJPa5piXuSVKzkB6O/XXtbDz5 G+moAoBYfbFCZXOR+Y4nwAltbRahjbcR//a5y1sTX9u16L7Is9irGLRE2lDPCLo4 IzmR4xI6d2oUsljfXcy25/qdXnRoWIplafUIYfvvJ0PPZeML1UqiQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=SeZgji GWJXLJh5aMLg4ATAAItC1DlwwlX/bKJC0PG0k=; b=Tb/Y/RvbNJexC0G7gnANCp Bk05eGfM5vw3hZkPHXCM5QW/igMY9UYluZDNFmky2ob/fMVEliWxECs1bbBNCuH3 vvQuU8awcG/ON/lI8wjyht3HXg7rU0Vuz/ishLtIhhkU6Ig8f/ZHnIaFEnXwPTJm Ph8hKrPjA08GqMH9yT7OrBmi32iJKZP4EkoB42XWJCXANGcgxSy423xKyFC+Kgia 0XdeJ12Z4z2RhNYj4lmv0juVhxnSpwA3UMkSBA0/+mhtfonc8FMeV+FP5cd6Irda iLaL9bH+vi1oZC0rEiCizpAgjQoYy2mWobR999CcqVK0ATEQUwQgHRr7IidzZqDQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 12C63BAB71; Fri, 18 Aug 2017 20:40:42 -0400 (EDT) Message-Id: <1503103241.2678549.1078130088.140CD52A@webmail.messagingengine.com> From: Bron Gondwana To: dmarc@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150310324226785490" X-Mailer: MessagingEngine.com Webmail Interface - ajax-21c69044 Date: Sat, 19 Aug 2017 10:40:41 +1000 References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> <166070f0-4ba1-70da-1f73-885b4a7f7640@gmail.com> <1502497178.4103451.1070917304.23DD466D@webmail.messagingengine.com> <598F9484.7020700@isdg.net> <599484FB.9050908@isdg.net> <1502929303.4038704.1075868960.5D80A788@webmail.messagingengine.com> <1502930858.4042926.1075890568.5069945B@webmail.messagingengine.com> In-Reply-To: Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Aug 2017 00:40:46 -0000 This is a multi-part message in MIME format. --_----------=_150310324226785490 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Sat, 19 Aug 2017, at 04:51, Brandon Long wrote: > > > On Fri, Aug 18, 2017 at 10:00 AM, Seth Blank > wrote:>> On Thu, Aug 17, 2017 at 11:46 PM, Kurt Andersen >> wrote:>>> So I was able to retrace our design steps which led to the 3-piece >>> model (AAR + AMS + AS) and the reasoning for the AS, signing just >>> the ARC header sequence was to provide the verifiable chain of >>> custody trace (though, of course, only from participating >>> intermediaries). Some of the recent tweaks to the spec to deal >>> with malformed sets of ARC header fields have weakened that >>> original idea.>>> >>> In keeping with Bron's general idea to simplify, I'd suggest that >>> having an AAR + [optional AMS] + AS would be a close approach for >>> handling steps which do not break the ingress signature. Skipping >>> the AMS would be a sign to downstream intermediaries that the prior >>> DKIM or AMS was still valid upon egress. (certain details would have >>> to be worked out)>>> >>> Does that help the conversation? >> >> >> No, I think this is a huge step in the wrong direction. >> >> Right now, we've got deployed code that we know works and improves >> the landscape. Everything else is - rightly or wrongly - conjecture.>> >> Let's keep the tech stable and move to experimentation. >> >> If anything, this is an excellent question for receivers - when >> evaluating AMS/AS, were there any situations where you required both >> signatures to truly validate a chain and make a delivery decision, or >> with the added ARC payload is now just having one sufficient?> > I'm leary that removing the AMS on certain hops is the right choice, > here. Without the AMS, the extra AAR/AS is not tied to this message > directly, so I'm unsure how to handle any assertions made in the AAR. > This also feels like the opposite of what Bron is asking for. I think I agree with you here - that keeping AS but breaking old ones by removing AMS is the opposite of useful. > I also proposed a month or so back some simplifying changes which were > largely met with radio silence, that would have partially mitigated > some of Bron's operational concerns, notably to either require the s/d > be the same on AS/AMS or to eliminate the signature and s/d on AMS > completely, switching the AMS to a hash that would then be covered by > the AS. That doesn't reduce the number of crypto ops as much as his > AMS only based proposal (which presumably would halt at the first > broken AMS). Before I joined - maybe I should read back further! This makes sense to me, certainly two separate signatures (AS and AMS) is wasteful and meaningless. Which one the signature actually sits on doesn't matter at all from a topological viewpoint, only what the signature covers matters. A signature on the AS which signed an AMS-like header that was just a hash over the content would be fine. Having the AMS-like header calculated in such a way that if a site didn't modify the content of the message, it also didn't modify the AMS hash would be super fine. As a matter of fact, I really like this. An AMS that doesn't have a signature, but covers the content in a repeatably defined way, and possibly even a way that can adapt to minor changes (changing from address, stripping or adding MIME parts, etc) such that modifiers could modify in a way that allowed provenance of the bulk of the message payload to be tracked through them. Being able to assert "I only modified the message in these ways" in a way that could be verified would be fantastic as an intermediate - and it would stop me doing what I did in my last email and completely faking a valid ARC chain on a fake message from Brandon. I could only modify the message in limited ways without tipping my hand. > Another option would be to change our expectations, that is to say > that signing by non-modifying hops is optional. For sure. Either changing ARC so that non-modifying hops sign but don't change the AMS-like hash (so it's clear they didn't modify), or saying that signing by non-modifying hops is at least a SHOULD NOT. My goal with everything that I'm suggesting is to increase the ability to determine provenance of the message payload. The mail flow itself is always going to be easily faked.[1] DKIM doesn't assert anything about mail flow - you can receive a DKIM- signed message and regardless of the route it's traveled, you know that the payload was unmodified since it left the jurisdiction which had access to the private key for its signing domain. ARC as currently defined is weak on maintaining provenance on the payload. But provenance on the payload is what really matters, because falsifying the payload is where attacks against email integrity get their value. Bron. [1] footnote on this - I have alluded to crypto header rewriting such that you can't rewind. I'll write a separate email on that topic. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_150310324226785490 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Sat, 19 Aug 2017, at 04:51, Brandon Long wrote:


On Fri, Aug 18, 2017 at 10:00 AM, Seth Blank <seth@sethblank.com> wrote:
On Thu, Aug 17, 2017 at 11:46 PM, Kurt Andersen <kurta@drkurt.com> wrote:
So I was able to retrace our design steps which led to the 3-piece model (AAR + AMS + AS) and the reasoning for the AS, signing just the ARC header sequence was to provide the verifiable chain of custody trace (though, of course, only from participating intermediaries). Some of the recent tweaks to the spec to deal with malformed sets of ARC header fields have weakened that original idea.

In keeping with Bron's general idea to simplify, I'd suggest that having an AAR + [optional AMS] + AS would be a close approach for handling steps which do not break the ingress signature. Skipping the AMS would be a sign to downstream intermediaries that the prior DKIM or AMS was still valid upon egress. (certain details would have to be worked out)

Does that help the conversation?


No, I think this is a huge step in the wrong direction.

Right now, we've got deployed code that we know works and improves the landscape. Everything else is - rightly or wrongly - conjecture.

Let's keep the tech stable and move to experimentation.

If anything, this is an excellent question for receivers - when evaluating AMS/AS, were there any situations where you required both signatures to truly validate a chain and make a delivery decision, or with the added ARC payload is now just having one sufficient?

I'm leary that removing the AMS on certain hops is the right choice, here.  Without the AMS, the extra AAR/AS is not tied to this message directly, so I'm unsure how to handle any assertions made in the AAR.  This also feels like the opposite of what Bron is asking for.

I think I agree with you here - that keeping AS but breaking old ones by removing AMS is the opposite of useful.

I also proposed a month or so back some simplifying changes which were largely met with radio silence, that would have partially mitigated some of Bron's operational concerns, notably to either require the s/d be the same on AS/AMS or to eliminate the signature and s/d on AMS completely, switching the AMS to a hash that would then be covered by the AS.  That doesn't reduce the number of crypto ops as much as his AMS only based proposal (which presumably would halt at the first broken AMS). 

Before I joined - maybe I should read back further!  This makes sense to me, certainly two separate signatures (AS and AMS) is wasteful and meaningless.  Which one the signature actually sits on doesn't matter at all from a topological viewpoint, only what the signature covers matters.  A signature on the AS which signed an AMS-like header that was just a hash over the content would be fine.  Having the AMS-like header calculated in such a way that if a site didn't modify the content of the message, it also didn't modify the AMS hash would be super fine.

As a matter of fact, I really like this.  An AMS that doesn't have a signature, but covers the content in a repeatably defined way, and possibly even a way that can adapt to minor changes (changing from address, stripping or adding MIME parts, etc) such that modifiers could modify in a way that allowed provenance of the bulk of the message payload to be tracked through them.  Being able to assert "I only modified the message in these ways" in a way that could be verified would be fantastic as an intermediate - and it would stop me doing what I did in my last email and completely faking a valid ARC chain on a fake message from Brandon.  I could only modify the message in limited ways without tipping my hand.

Another option would be to change our expectations, that is to say that signing by non-modifying hops is optional.

For sure.  Either changing ARC so that non-modifying hops sign but don't change the AMS-like hash (so it's clear they didn't modify), or saying that signing by non-modifying hops is at least a SHOULD NOT.

My goal with everything that I'm suggesting is to increase the ability to determine provenance of the message payload.  The mail flow itself is always going to be easily faked.[1]

DKIM doesn't assert anything about mail flow - you can receive a DKIM-signed message and regardless of the route it's traveled, you know that the payload was unmodified since it left the jurisdiction which had access to the private key for its signing domain.

ARC as currently defined is weak on maintaining provenance on the payload.  But provenance on the payload is what really matters, because falsifying the payload is where attacks against email integrity get their value.

Bron.

[1] footnote on this - I have alluded to crypto header rewriting such that you can't rewind.  I'll write a separate email on that topic.

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


--_----------=_150310324226785490-- From nobody Fri Aug 18 17:53:52 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48A9C1323F9 for ; Fri, 18 Aug 2017 17:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=SdEHF+Qx; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=N455UVte Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdE3JoIek78i for ; Fri, 18 Aug 2017 17:53:49 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5738A132223 for ; Fri, 18 Aug 2017 17:53:49 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id C07A12216E for ; Fri, 18 Aug 2017 20:53:48 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Fri, 18 Aug 2017 20:53:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=aA1ge1wbNM0Oj5LX5Pl2pI5JUfCnIhNInkYKo+BKp Ek=; b=SdEHF+QxnMN5N+BBjOEYspogocccKAHLIed+47xR9QamoS+4a27sMzqgo 7PNCSAksNGU/GQPcxUKfQOgUCbCRanhms1li0PYKwj/n1kjYa0E19BFVFvrjzu92 hK0R1A7Y6UNMQj9sxwB+nAXfGscjVTQ2zyMJVAU203mB6seL56j9JweFsc/YFmpr cutMkMl8M+OfCpIWNZpD3fXVMoN68s1OsqhVZn1C09gFVWUiS7GlI+DUeLZbfyJD 9owGyVJglvgSyjVSzRD9ogNlOwdrkOFLhEv+/KIKHAdF4EuWghwJphd7Yo91TnpE h3VmO4pdWjTccKYU2PFKyRRoLOEpA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=aA1ge1wbNM0Oj5LX5Pl2pI5JUfCnI hNInkYKo+BKpEk=; b=N455UVteW1oru8F5BXdzmnNKq51IoiSOSqS9yenEN9l2e BgjKK+zUwm5lMCgg+3s7NFScKHKgyFTxzStLDAu8qhcgtn1NhwSB+xpY3jqn0nPy Bx1NysBxBZmNOQwV3v35c2RS/olTQ6rFrRg+mfu6YROQIx/QMYx/MZ14IkF9h5lK lYds66bBWC7g4e3Ubbyc84eleheLd9WAKxu4zCeHjlOG6KZcpEKZhPG8/wZt5YL4 wQRftzAnN2Poqg0Tq13OFEG8vkRpbJmtU2sasxIcXzaN325evCUlTQtLgdJBdkAl aObxpokJCSInWVW612SlWVhNbmJ6aJ1VWAnK1SQzw== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 98366BAB71; Fri, 18 Aug 2017 20:53:48 -0400 (EDT) Message-Id: <1503104028.2682226.1078138680.6C07899A@webmail.messagingengine.com> From: Bron Gondwana To: dmarc@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150310402826822260" X-Mailer: MessagingEngine.com Webmail Interface - ajax-21c69044 Date: Sat, 19 Aug 2017 10:53:48 +1000 Archived-At: Subject: [dmarc-ietf] About "non-rewindable crypto" X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Aug 2017 00:53:51 -0000 This is a multi-part message in MIME format. --_----------=_150310402826822260 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" So this is an interesting case that I'd like to spin into a separate thread. At the moment, ARC headers are purely additive. You receive a message with some ARC headers on it, you add some more on top and send it on. AR: arc=pass, ... // at receiver AS: i=3; cv=pass, d=site4.com AMS: i=3; d=site4.com AAR: i=3; arc=pass AS: i=2; cv=pass, d=site3.com AMS: i=2; d=site3.com AAR: i=2; arc=pass AS: i=1; cv=none, d=site2.com AMS: i=1; d=site2.com AAR: i=1; arc=none; dkim=pass DKIM-Signature: d=site1.com site1 => site2 => site3 => site4 => receiver Somebody who obtains a copy of that message could then trim the message back: AS: i=2; cv=pass, d=site3.com AMS: i=2; d=site3.com AAR: i=2; arc=pass AS: i=1; cv=none, d=site2.com AMS: i=1; d=site2.com AAR: i=1; arc=none; dkim=pass DKIM-Signature: d=site1.com And pretend that the message was sent from site3 down a different path: AR: arc=pass, ... // at receiver AS: i=3; cv=pass, d=badsite.com AMS: i=3; d=badsite.com AAR: i=3; arc=pass AS: i=2; cv=pass, d=site3.com AMS: i=2; d=site3.com AAR: i=2; arc=pass AS: i=1; cv=none, d=site2.com AMS: i=1; d=site2.com AAR: i=1; arc=none; dkim=pass DKIM-Signature: d=site1.com And the message still arrives at receiver with a valid ARC chain, just via badsite.com instead of site3.com. It is possible to do things with crypto, mixing in hashes, such that you not only add new headers, but you rewrite past headers such that the original versions of them can't be reconstructed any more. Which would mean that if you could intercept a copy at the receiver, you couldn't trim back to i=2 and restart the chain on that message. It would mean header replacement rather than just header addition though. Is this something that would have enough interest to be worth pursuing? It's bound to be more complex than ARC-as-defined, but it also makes faking mail flows a lot harder, because you would have to intercept the message between site3 and site4 if you wanted to fake the mail flow from site3 - you couldn't just pick it up later. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_150310402826822260 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
So this is an interesting case that I'd like to spin into a separate thread.

At the moment, ARC headers are purely additive.  You receive a message with some ARC headers on it, you add some more on top and send it on.

AR: arc=pass, ...  // at receiver
AS: i=3; cv=pass, d=site4.com
AMS: i=3; d=site4.com
AAR: i=3; arc=pass
AS: i=2; cv=pass, d=site3.com
AMS: i=2; d=site3.com
AAR: i=2; arc=pass
AS: i=1; cv=none, d=site2.com
AMS: i=1; d=site2.com
AAR: i=1; arc=none; dkim=pass
DKIM-Signature: d=site1.com

site1 => site2 => site3 => site4 => receiver

Somebody who obtains a copy of that message could then trim the message back:

AS: i=2; cv=pass, d=site3.com
AMS: i=2; d=site3.com
AAR: i=2; arc=pass
AS: i=1; cv=none, d=site2.com
AMS: i=1; d=site2.com
AAR: i=1; arc=none; dkim=pass
DKIM-Signature: d=site1.com

And pretend that the message was sent from site3 down a different path:

AR: arc=pass, ...  // at receiver
AS: i=3; cv=pass, d=badsite.com
AMS: i=3; d=badsite.com
AAR: i=3; arc=pass
AS: i=2; cv=pass, d=site3.com
AMS: i=2; d=site3.com
AAR: i=2; arc=pass
AS: i=1; cv=none, d=site2.com
AMS: i=1; d=site2.com
AAR: i=1; arc=none; dkim=pass
DKIM-Signature: d=site1.com

And the message still arrives at receiver with a valid ARC chain, just via badsite.com instead of site3.com.

It is possible to do things with crypto, mixing in hashes, such that you not only add new headers, but you rewrite past headers such that the original versions of them can't be reconstructed any more.  Which would mean that if you could intercept a copy at the receiver, you couldn't trim back to i=2 and restart the chain on that message.  It would mean header replacement rather than just header addition though.

Is this something that would have enough interest to be worth pursuing?  It's bound to be more complex than ARC-as-defined, but it also makes faking mail flows a lot harder, because you would have to intercept the message between site3 and site4 if you wanted to fake the mail flow from site3 - you couldn't just pick it up later.

Bron.

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


--_----------=_150310402826822260-- From nobody Fri Aug 18 18:44:01 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2A71252BA for ; Fri, 18 Aug 2017 18:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3f--C-QurrrZ for ; Fri, 18 Aug 2017 18:43:57 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88384132436 for ; Fri, 18 Aug 2017 18:43:57 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id x77so17540243qka.5 for ; Fri, 18 Aug 2017 18:43:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yxDYED/lG+rPZFejsWXKziMBSjGKdom5HweOfnS9gog=; b=DgLt5aALpaTn9WmW/m4J2Rrt3OWnESktlewvXF+M0NhfVXvAWaxEdY4lOsWpPynhd2 i3IBwfuKv5rNShCkL8h3tMnIg2A8D1iwF7jMLKPsYqB+EiqK9PPi2mcx2yG4W9TcV7Qf SzIvAliViqnCWreIlkPxAQdFXVH5i17QK+xRqVI7uog/dlB3e3ib1unWfHhDMZgaSZ0+ 7Hx7JZswo/JwONj/+8+CBDfjzcpmsS0ZexVyoU32sXvBfVnnVlyDW3u9QrI6N2hyfXO4 y2x7wNObPmB0s8etTpE0xPJ9OA8D0MZiSwgKEOj8dNkx6aKA02t4Ifj/TA+XtaTVN/nI Z0nQ== 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=yxDYED/lG+rPZFejsWXKziMBSjGKdom5HweOfnS9gog=; b=lx9i30uZqCqNZhb8b2savjv/xu4JyN67QtSmUOE6QHVdFkoCY9Zs5oV7gEf9f4HXYG 2vgXHW+u/glYuAbnDt4v640AAvkJ1oBKaVXxWwcS51iQT9hYcG/O6/19OnpVHTuRLCTh 1E5sVzEhP8SwbPTXliQXkdYL+8BFUQ6OHJ/S9p3Ch+HIepV8/8LRdRuMTYwLMw3UTOG6 msT5fR0tvHivnIAuuOIWf9SBeroFDkCvsJF0gUVhEEus97L7JRy2OPkvEn5TH9dOtDql DeImYkCpfz3l0hw9y0x+MU1nrcqZykzidnHcMqgiabvxEOvKpY9W4k3ssD3yvZGdr9zQ LrJA== X-Gm-Message-State: AHYfb5gULNbukJp14wg0NKfM/HENfFswJqNVYQYxKLy94LXPfFXrBAvF JQmlGc8dHgzKk+wKTDtCamZoMU6Zug== X-Received: by 10.55.47.135 with SMTP id v129mr14964630qkh.13.1503107036670; Fri, 18 Aug 2017 18:43:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.57.34 with HTTP; Fri, 18 Aug 2017 18:43:55 -0700 (PDT) In-Reply-To: References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> <166070f0-4ba1-70da-1f73-885b4a7f7640@gmail.com> <1502497178.4103451.1070917304.23DD466D@webmail.messagingengine.com> <598F9484.7020700@isdg.net> <599484FB.9050908@isdg.net> <1502929303.4038704.1075868960.5D80A788@webmail.messagingengine.com> <1502930858.4042926.1075890568.5069945B@webmail.messagingengine.com> <1503006397.1306110.1076933224.154E25D6@webmail.messagingengine.com> From: "Murray S. Kucherawy" Date: Fri, 18 Aug 2017 18:43:55 -0700 Message-ID: To: Brandon Long Cc: Bron Gondwana , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a114f4020faf23505571160d8" Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Aug 2017 01:43:59 -0000 --001a114f4020faf23505571160d8 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 17, 2017 at 5:22 PM, Brandon Long wrote: > We went down the path of including a diff of the message in the headers, > but you run up against more complicated changes that make that > challenging. Ie, mailing lists which strip attachments. If all we cared > about were subject munging and footers, there probably would have been a > practical solution there. > I wrote a draft a while ago that would allow a DKIM-Signature to include an annotation indicating that the signing ADMD did one or more of a specific set of small but well-defined message changes (e.g., add a footer, add a Subject tag). Knowing what those are, a verifier could undo them and attempt validation of earlier signatures in the handling chain. Presumably if no other modifications were made, the original content is thus discoverable, and you could then produce a chain of custody of the actual content before you that makes sense. If that's worthy of consideration now I could certainly revivify it. -MSK --001a114f4020faf23505571160d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Aug 17, 2017 at 5:22 PM, Brandon Long <blong@fict= ion.net> wrote:
We went down th= e path of including a diff of the message in the headers, but you run up ag= ainst more complicated changes that make that challenging.=C2=A0 Ie, mailin= g lists which strip attachments.=C2=A0 If all we cared about were subject m= unging and footers, there probably would have been a practical solution the= re.=C2=A0

I wrote a draft a while ago= that would allow a DKIM-Signature to include an annotation indicating that= the signing ADMD did one or more of a specific set of small but well-defin= ed message changes (e.g., add a footer, add a Subject tag).=C2=A0 Knowing w= hat those are, a verifier could undo them and attempt validation of earlier= signatures in the handling chain.=C2=A0 Presumably if no other modificatio= ns were made, the original content is thus discoverable, and you could then= produce a chain of custody of the actual content before you that makes sen= se.

If that's worthy of consideration now I co= uld certainly revivify it.

-MSK
--001a114f4020faf23505571160d8-- From nobody Fri Aug 18 18:47:29 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26A6013245F for ; Fri, 18 Aug 2017 18:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=anSvokG8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Aq614TR/ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-8rZERzcNIi for ; Fri, 18 Aug 2017 18:47:26 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16851132436 for ; Fri, 18 Aug 2017 18:47:26 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 317872210A; Fri, 18 Aug 2017 21:47:25 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Fri, 18 Aug 2017 21:47:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=Z1n5sK S3S0hvLRYtxwh0dVTc36WQi5e3nsQIn0tGGBY=; b=anSvokG8IRDAiUPr7ykS7H OmjAi6R6y0aXH36hb1J4aRBA7N3HPrKtyHH+HXnSTwNvD4rNrxtwA+aRGgVwO/H8 ZtqGHze5yA6ivjy4zrM8KQHIf89qmcrQMhE20s2m7Ssv/6PvWpUUvqyWe93cTXi9 7+Ss+v8J7b0XEyX9qIF27pJJI48SSweB0LwnT3eEKK/cri79Ii4WF/t9vPLVmvX0 fVdW5qHshgs7IxjAgW0Pyk3jOMW8gJvpiwjbm3XnpN07gDG3a0ZPm6KGBvG87jUx 39PEsknYR+ByJh9zV802ZSLYsXRlBjTiQagYUFJCpVSoopcizFLXAov3CcAHQ7QA == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=Z1n5sK S3S0hvLRYtxwh0dVTc36WQi5e3nsQIn0tGGBY=; b=Aq614TR/Ko6QephgUosCIt JiD7muf6KIUXnhKljgkW4+B7LZcP8sDYGx0nruCpIaJ4w6lPRHftWjhfuiqJRgjP nhnQcjJcdItFFKQ2aZqm0fHz4/YUC5Wc2isz1Xqnc0WU6yFlJyArkCXiPQlDOXGz ynQ/8ELS+6jM8pmYaoxD5xUAkvcphv0vqwxuN1bupp9EheHyoE8tej+CUS6NVu3z umO/RCvLVK4TlqKX6vyHZkAqpLlg3Mk7GOgFLJ0tdiK4z8IeFkvufQspR7bU/hW2 40+EyurVSuEHIhQDxk9FbJA5WlGx9JRx3WQHb0SrldgexanVDTRPZvaoXzraanug == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 0F2FCBAB71; Fri, 18 Aug 2017 21:47:25 -0400 (EDT) Message-Id: <1503107244.2691235.1078169016.1D12AE95@webmail.messagingengine.com> From: Bron Gondwana To: "Murray S. Kucherawy" , Brandon Long Cc: dmarc@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150310724526912352" X-Mailer: MessagingEngine.com Webmail Interface - ajax-21c69044 In-Reply-To: Date: Sat, 19 Aug 2017 11:47:24 +1000 References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> <166070f0-4ba1-70da-1f73-885b4a7f7640@gmail.com> <1502497178.4103451.1070917304.23DD466D@webmail.messagingengine.com> <598F9484.7020700@isdg.net> <599484FB.9050908@isdg.net> <1502929303.4038704.1075868960.5D80A788@webmail.messagingengine.com> <1502930858.4042926.1075890568.5069945B@webmail.messagingengine.com> <1503006397.1306110.1076933224.154E25D6@webmail.messagingengine.com> Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Aug 2017 01:47:28 -0000 This is a multi-part message in MIME format. --_----------=_150310724526912352 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Sat, 19 Aug 2017, at 11:43, Murray S. Kucherawy wrote: > On Thu, Aug 17, 2017 at 5:22 PM, Brandon Long > wrote:>> We went down the path of including a diff of the message in the >> headers, but you run up against more complicated changes that make >> that challenging. Ie, mailing lists which strip attachments. If all >> we cared about were subject munging and footers, there probably would >> have been a practical solution there.> > I wrote a draft a while ago that would allow a DKIM-Signature to > include an annotation indicating that the signing ADMD did one or more > of a specific set of small but well-defined message changes (e.g., add > a footer, add a Subject tag). Knowing what those are, a verifier > could undo them and attempt validation of earlier signatures in the > handling chain. Presumably if no other modifications were made, the > original content is thus discoverable, and you could then produce a > chain of custody of the actual content before you that makes sense.> > If that's worthy of consideration now I could certainly revivify it. That seems really valuable to me. Being able to track the provenance on individual parts of the message payload is a much stronger way to determine who is at fault when bad content is being injected than just knowing some bits of the message handling chain. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_150310724526912352 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Sat, 19 Aug 2017, at 11:43, Murray S. Kucherawy wrote:
On Thu, Aug 17, 2017 at 5:22 PM, Brandon Long <blong@fiction.net> wrote:
We went down the path of including a diff of the message in the headers, but you run up against more complicated changes that make that challenging.  Ie, mailing lists which strip attachments.  If all we cared about were subject munging and footers, there probably would have been a practical solution there. 

I wrote a draft a while ago that would allow a DKIM-Signature to include an annotation indicating that the signing ADMD did one or more of a specific set of small but well-defined message changes (e.g., add a footer, add a Subject tag).  Knowing what those are, a verifier could undo them and attempt validation of earlier signatures in the handling chain.  Presumably if no other modifications were made, the original content is thus discoverable, and you could then produce a chain of custody of the actual content before you that makes sense.

If that's worthy of consideration now I could certainly revivify it.

That seems really valuable to me.  Being able to track the provenance on individual parts of the message payload is a much stronger way to determine who is at fault when bad content is being injected than just knowing some bits of the message handling chain.

Bron.

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


--_----------=_150310724526912352-- From nobody Fri Aug 18 21:51:31 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0674313240A for ; Fri, 18 Aug 2017 21:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=isdg.net header.b=e/wznSIq; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=FhcZf0o7 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c_9RSVCWakYM for ; Fri, 18 Aug 2017 21:51:27 -0700 (PDT) Received: from listserv.winserver.com (ftp.catinthebox.net [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 4232C132382 for ; Fri, 18 Aug 2017 21:51:26 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=7581; t=1503118285; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=SA5iykNzDFZIJqQ/xrSPw3N6+hw=; b=e/wznSIqQIrXWBCHBR4N12QKQorXDQbO6dLdRP696SD1OWC1l47b+g+URDFNVp ULij3IxusI1Ah2HTmvgb+sOUXUqINz1VlGwsOJUfoO9Lc9wAovwj5dCIszlulAwb flTEBIyirg1MPqzPcegMSTn/VUs1qmmUzNjm3w6QXajUI= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Sat, 19 Aug 2017 00:51:25 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 3182139196.1.6024; Sat, 19 Aug 2017 00:51:24 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=7581; t=1503118241; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=2LiS+hN DqaUp57F7mJvxb05STjPLYFp1oVL79CY+ymc=; b=FhcZf0o7/YpGzSHdp3rGk4S uhzmVv9Y6NqlMThec6tD3Bc5nwQkjG1eDU/T0NIyYgtPZC/QgGWT4nrf42GFfaHT z4qliwePNBIx1M2vSOdkbXiicej+mds/Zc5S/Brl89GuwrOVuaPMBzuzMGYT8uUr 2webKISgbl3otQVHMuyk= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Sat, 19 Aug 2017 00:50:41 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 66121109.9.2308; Sat, 19 Aug 2017 00:50:40 -0400 Message-ID: <5997C3CE.2080900@isdg.net> Date: Sat, 19 Aug 2017 00:51:26 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> <166070f0-4ba1-70da-1f73-885b4a7f7640@gmail.com> <1502497178.4103451.1070917304.23DD466D@webmail.messagingengine.com> <598F9484.7020700@isdg.net> <599484FB.9050908@isdg.net> <1502929303.4038704.1075868960.5D80A788@webmail.messagingengine.com> <1502930858.4042926.1075890568.5069945B@webmail.messagingengine.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Aug 2017 04:51:30 -0000 On 8/16/2017 9:32 PM, Seth Blank wrote: > On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana > wrote: > > While there exists A SINGLE SITE which is ARC-unaware and DMARC > p=reject aware, you can't use ARC on a DMARC p=reject domain > without rewriting the sender. Otherwise that site will bounce the > email. > > You still have to rewrite the sender until there is either full > adoption or sufficient adoption that you just don't care about the > stragglers. > > ARC doesn't solve that unless every receiver is either ARC-aware > or DMARC-unaware. Hence the suggestion that I think Hector is > making - to define a new policy p=rejectnonarc or something, which > means that sites which are ARC-unaware accept rather than reject. > > > So this is an excellent and crucial point that has been discussed > again and again on and off this list. > > ARC only works if critical mass can be reached - both of > intermediaries who break DKIM and receivers who evaluate ARC. Of course. But in my opinion, the real problem, I thought, was finding a solution to the old DKIM Policy Model problem that began with SSP and ADSP, a proposed standard and now DMARC. They all had the same issue. As a strong policy DKIM working group advocate, I was the one that illustrated the problem (the auto-unsubscribe issue). DMARC did not resolve the reason ADSP was abandoned. DMARC only obtained popularity first as a reporting mechanism which I thought was redundant. It didn't prove anything beyond we already knew which was when a Strong Rejection was honored by receivers, it had a very high payoff value, so such, eventually, big domains supported it. But it also eventually shows what we already knew what will happen -- it will cause mailing list "auto-unsubscribe" problems with accumulated failed Policy rejections. This was well documented. So if everyone supported some of the proposals which is far better than ARC to resolve this problem, then we would of ended this long time "project research" at least 4-6 years ago. Right now, ARC is asking to stamp the mail with additional overhead. Its the first time I believe, that attempts to follow Dave Crocker's old ideas on Chain of (Mail Transport) Trust. ARC can possibly help in that area but only if it resolves the unauthorized re-signer problem. That would basically mean that at least 1 ARC Seal only needs to be trusted, and that would be the first and/or last signer. We always get back to this 100% versus less than 100% problem and with ARC, it can be inherently or explicitly stated what is required. 1) If all seals are valid, the chain is not broken, then is this an acceptable condition for a receiver to accept what would be otherwise a DMARC failed P=REJECT action? 2) What if one fails? We should let the Originating Authoring Domain have some say in all this. Its how I would like to have my restricted domains treated and protected. I will do the same with other restricted domains. > Fundamentally, ARC will never reach critical mass if senders now also > need to enter into the equation with an additional flag on their DMARC > record. This is too high a bar and increases the interoperability > problems as opposed to reducing them. I don't see that. We are already creating DMARC records which is the big gain over ADSP. And it appears sufficiently enough to support the strong "DKIM Policy" p=reject concept. But we had the same problem with SSP and ADSP, a IETF Proposed Standard. The problem is that it didn't reach critical mass, and we also said that it didn't need to reach critical mass because it was well understood it would be a limited stream. Yes, the protocol needs to start somewhere and if we don't offer an augmented policy concept for ARC, then I just don't see myself supporting it until there is some inherent or explicit declaration by the Author Domain that the payoff can be high by supporting it. ARC does not have that. > For now, there is a clear unanswered question: what coverage of > receivers is needed for most mailing lists to achieve stable delivery > once ARC is in the mix? This can leave a hole that is problematic if we continue on a critical mass reason to exist. What will happen when all mail is ARC sealed but only 5% or 10% of the domains used p=reject. You need to have a declaration somewhere about what 100% or less than 100% means as part of protocol because if ARC does not, then there will be a high overhead of legacy mail and domains didn't declare anything and ARC is suppose to be a way to ignore "p=reject" policies. At some point, you will have to say "IF you want to use P=REJECT, then you MUST|SHOULD support ARC and only use send signed mail on streams that use ARC seal. This will allow your users to use the restrictive domains in public environments which be against the domain wishes." The problem? There will be domains that really, really do not want any 3rd party streams to interfere with their direct mail streams. It helps protect their domain and reputation. I suppose this concept and offering to operators. I am asking what are the rules of the protocol game for DMARC and ARC. > Knowing the landscape of receiving domains, I > believe this to be a small number. From the above comments, I'm > guessing you think this is a large number. We're not going to resolve > this difference of opinion in an open forum. However, releasing ARC as > an experiment into the wild for major lists like the IETF and M3AAWG > will give us very clear data very quickly on what the actual landscape > looks like, and what ARC does and does not solve. I believe this was pretty obvious by now. The same issues applied with SSP and ADSP which would technically resolve the Mailing List problem by augmented it with ATPS. I am one of the few packages that know it works in practice. How is ARC any better to add now that DMARC has replaced ADSP? What will be achieved when there is 10% of the stream versus 90% using ARC? You can't treat them differently because it will leave Security Holes and an awful lot of waste if there is a low payoff. > In its current form, ARC only helps mail flows, it does not harm them. More headers adds processing, more complexity. Lets keep in mind that not everyone uses open source libraries. ARC will also add cost. > How effective this improvement is remains to be seen, but preliminary > information I've been hearing about (which could be totally wrong) > makes it seem like the improvements are dramatic. Only if there is an declaration by the authoring domain that says something about its mail. > So let's get ARC > tied off as an Experiment (thank you, Dave Crocker), collect some > data, and see where things stand. Maybe things are great and ARC can > move to proposed standard. Maybe it fundamentally needs more receivers > in the mix than currently expected, and some fix for that is needed. > But we'll know that after the experiment has begun, not before. This sounds like repeated project research work. We don't need a trillion messages to show what A) the problem is and B) what the solution can be. We can do that in theory and in practice with just 1 message. It was always about DKIM Trust/Reputation Model vs DKIM Policy Authorization model. At some point that Policy declaration needs to be made. Somewhere, somehow, otherwise the problem doesn't go away. -- HLS From nobody Fri Aug 18 22:17:16 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B838132621 for ; Fri, 18 Aug 2017 22:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCrmiuoJXnLd for ; Fri, 18 Aug 2017 22:17:13 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23CA113248A for ; Fri, 18 Aug 2017 22:17:13 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id z18so62536380qka.4 for ; Fri, 18 Aug 2017 22:17:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UVek6TlIDH2ozA1f+JJDvWGVHDE/DA8nYfPqcF0P6Tc=; b=XocFDWXLFRL1jI2Zk4/WYDdRf52sM6/uYAjGj58EkTU/h2WDP69udyuQtnPXdw4hcL Ofr1SWovlO/Bjm7ZZNmHsPqZcHWnLxE1RonY2PXMJ/axZmAqrwrcg9GQ5A74g44rhntP Bf+WAMdYBL/oshybZxbaqJJV9Agv/G5jYz5j/EaXJa7CB0ZP5UAwR9SiJEJRWCpwGnrs We9A+HMuL8G55axyG5j7Hq/Zy/rF0wzgabA/BRcOfcryxPUoWmYwnr4B2/4smr5picsJ RpAY1OfeguPr6VXhiBqam/VA3xJz24vNv4p/8ox+9pEDgpE02mucKAro4JNCAs0FEJeR 3dbA== 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=UVek6TlIDH2ozA1f+JJDvWGVHDE/DA8nYfPqcF0P6Tc=; b=GrdP7n0XWjWqkCKGzY7YGKOomS/4NrdidwqfbVYNT/FoI6inMJ9oWfuc2GgUbG8hcD PQOhTvRKq11iglBiBcn0x0BB882E4jSMrda/NuVfoNpD34BWcHu6GnuojJ84HCTAft2Y rd4KP1eaGSV458tOlHpVNuk6/lqjArGq9UBDMtv1j/k7PlQN1S3Ibwq5lG+BrqK11WNx ytHea2hv75jl/3CouskvJWZ6lf8djL5bqxKU3AGiTl981Q5iajO0s6cPST75n+tM48SU GLNXQ2KZtMpwtUxj9ayG+LpXtYajmTdvSRBk4Hi5soNT6A1/lKBAWQYd/PfihhHQniD9 GvCg== X-Gm-Message-State: AHYfb5h0Lm8/4ecYX9/ri4iHovICWCrJi8cxfEjddvaLu47dybjem0JX tHd8cpXgFBrc7pVff9CeR6vUT+OSUQ== X-Received: by 10.55.73.135 with SMTP id w129mr15175300qka.249.1503119832201; Fri, 18 Aug 2017 22:17:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.57.34 with HTTP; Fri, 18 Aug 2017 22:17:11 -0700 (PDT) In-Reply-To: <1503107244.2691235.1078169016.1D12AE95@webmail.messagingengine.com> References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> <166070f0-4ba1-70da-1f73-885b4a7f7640@gmail.com> <1502497178.4103451.1070917304.23DD466D@webmail.messagingengine.com> <598F9484.7020700@isdg.net> <599484FB.9050908@isdg.net> <1502929303.4038704.1075868960.5D80A788@webmail.messagingengine.com> <1502930858.4042926.1075890568.5069945B@webmail.messagingengine.com> <1503006397.1306110.1076933224.154E25D6@webmail.messagingengine.com> <1503107244.2691235.1078169016.1D12AE95@webmail.messagingengine.com> From: "Murray S. Kucherawy" Date: Fri, 18 Aug 2017 22:17:11 -0700 Message-ID: To: Bron Gondwana Cc: Brandon Long , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a114a8562a741520557145b6c" Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Aug 2017 05:17:15 -0000 --001a114a8562a741520557145b6c Content-Type: text/plain; charset="UTF-8" On Fri, Aug 18, 2017 at 6:47 PM, Bron Gondwana wrote: > On Sat, 19 Aug 2017, at 11:43, Murray S. Kucherawy wrote: > > On Thu, Aug 17, 2017 at 5:22 PM, Brandon Long wrote: > > We went down the path of including a diff of the message in the headers, > but you run up against more complicated changes that make that > challenging. Ie, mailing lists which strip attachments. If all we cared > about were subject munging and footers, there probably would have been a > practical solution there. > > > I wrote a draft a while ago that would allow a DKIM-Signature to include > an annotation indicating that the signing ADMD did one or more of a > specific set of small but well-defined message changes (e.g., add a footer, > add a Subject tag). Knowing what those are, a verifier could undo them and > attempt validation of earlier signatures in the handling chain. Presumably > if no other modifications were made, the original content is thus > discoverable, and you could then produce a chain of custody of the actual > content before you that makes sense. > > If that's worthy of consideration now I could certainly revivify it. > > > That seems really valuable to me. Being able to track the provenance on > individual parts of the message payload is a much stronger way to determine > who is at fault when bad content is being injected than just knowing some > bits of the message handling chain. > https://tools.ietf.org/html/draft-kucherawy-dkim-transform-00 The notion of tracking provenance is secondary to being able to recover and evaluate the original content signed by the originating ADMD. You could in theory get that signature to pass again, which would satisfy DMARC. The transformations it covers could easily be augmented to include Subject tagging, or even non-MIME footer attachment using the "--" delimiter. -MSK --001a114a8562a741520557145b6c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Aug 18, 2017 at 6:47 PM, Bron Gondwana <br= ong@fastmailteam.com> wrote:
=
On Sat, 19 Aug= 2017, at 11:43, Murray S. Kucherawy wrote:
On Thu, Aug 17, 2017 at 5:22 PM, Brandon Long <blong@fiction.net><= /span> wrote:
We went down the pat= h of including a diff of the message in the headers, but you run up against= more complicated changes that make that challenging.=C2=A0 Ie, mailing lis= ts which strip attachments.=C2=A0 If all we cared about were subject mungin= g and footers, there probably would have been a practical solution there.= =C2=A0

I wrote a draft a while ago that would allow a DKIM-Signature to inclu= de an annotation indicating that the signing ADMD did one or more of a spec= ific set of small but well-defined message changes (e.g., add a footer, add= a Subject tag).=C2=A0 Knowing what those are, a verifier could undo them a= nd attempt validation of earlier signatures in the handling chain.=C2=A0 Pr= esumably if no other modifications were made, the original content is thus = discoverable, and you could then produce a chain of custody of the actual c= ontent before you that makes sense.

If that's worthy of consideration now I could certainly revivify i= t.

That seems really valuable to me.= =C2=A0 Being able to track the provenance on individual parts of the messag= e payload is a much stronger way to determine who is at fault when bad cont= ent is being injected than just knowing some bits of the message handling c= hain.
The notion of tracking provenance is secondary to being able to recover a= nd evaluate the original content signed by the originating ADMD.=C2=A0 You = could in theory get that signature to pass again, which would satisfy DMARC= .

The transformations it covers could easily be augmented to i= nclude Subject tagging, or even non-MIME footer attachment using the "= --" delimiter.

-MSK
<= /div>
--001a114a8562a741520557145b6c-- From nobody Fri Aug 18 22:23:59 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D985132454 for ; Fri, 18 Aug 2017 22:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=HhYsdFL1; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=FSMtVRZK Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MznR4UyHktT0 for ; Fri, 18 Aug 2017 22:23:57 -0700 (PDT) Received: from listserv.winserver.com (ftp.catinthebox.net [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1B96613241B for ; Fri, 18 Aug 2017 22:23:57 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1579; t=1503120235; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=CGGH0Hhp8fQH/mcYi8llsa5awFk=; b=HhYsdFL1TxrbUhFAVYGuXzaHloo2+KzozzZOBMfS8C8qe48Fv9y7iiVMvg/4wK EavhYBnVpaTgYmKmPDqn07E2LULVVoAH1K+Z6vKTS2UBUDuklRhGvUmXISYKi+aF HmXH27tga8TiPBs81aFEXKNVbykDqiqJMbu1dfEhBl+NA= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Sat, 19 Aug 2017 01:23:55 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 3184089177.1.2920; Sat, 19 Aug 2017 01:23:55 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1579; t=1503120193; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=9Sgj8zN JxDUZhEsTPTNRuztwbax0mDkee87epCHl6LA=; b=FSMtVRZKI/ceaFKMSRG/Xma Sh3z4G3npjZ+Rm+FgOFlTqSpY/66GKMjsWt5SwYFUM2nf9goaljA7EMT5s6giz61 jameDr+pS8vRJOl1XB7HAe8Y/7GqBFQhN9boxfaZ5Iv4VLDmwWMmSa/7JvkTBAvs JphvjbgW2nuslEZLDezk= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Sat, 19 Aug 2017 01:23:13 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 68073062.9.3572; Sat, 19 Aug 2017 01:23:12 -0400 Message-ID: <5997CB6E.80905@isdg.net> Date: Sat, 19 Aug 2017 01:23:58 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> <166070f0-4ba1-70da-1f73-885b4a7f7640@gmail.com> <1502497178.4103451.1070917304.23DD466D@webmail.messagingengine.com> <598F9484.7020700@isdg.net> <599484FB.9050908@isdg.net> <1502929303.4038704.1075868960.5D80A788@webmail.messagingengine.com> <1502930858.4042926.1075890568.5069945B@webmail.messagingengine.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Aug 2017 05:23:59 -0000 On 8/18/2017 2:10 PM, Murray S. Kucherawy wrote: > Of course, the danger of proceeding along that line is that we do > establish a deployed base, however small, that will be difficult to > change later. +1 > I don't know the answer to that question immediately, > and admittedly I'm only going to be on the periphery of cleaning up > whatever mess results. Well, we should know this by now. Are we in a project research or product research phase here? We are well beyond the proof of concepts here. We all know what the problems are when a DKIM Policy Model offers a method to handle strong, exclusive, restrictive polices whether it was SSP/DomainKeys o=-, ADSP DISCARDable and now DMARC p=reject. IMO, there is nothing new added to the table other than more overhead, a ARC chain, across the transport path. Highly sensitive to breakage, until the originating domain says something about it, I don't see how it resolves the original problem. I suggest the simplest solution is to augment ARC with an extended DMARC tag that informs receivers that its "OK" to relax p=reject only under X% ARC seal conditions It could be 100% or it be partial, fuzzy, "SoftFail" concept, whatever. Let the Originating Author Domain decide. This would offer a reason to support ARC, to explore the experimentation, and best of all, we won't have the design change pressures to deal with the borderline "illegal," "unethical" 5222.From rewriting methods/kludges. Lets remember it remains to be the only hash binding header requirement by DKIM. -- HLS From nobody Fri Aug 18 23:33:10 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3DEC132328 for ; Fri, 18 Aug 2017 23:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=jldzxrlE; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=JdafulA8 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqTwYCFlKGOD for ; Fri, 18 Aug 2017 23:33:08 -0700 (PDT) Received: from winserver.com (secure.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id BB8831200C5 for ; Fri, 18 Aug 2017 23:33:07 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3059; t=1503124386; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=FD83sqtcBRm5GebOLYlK9Zti0VM=; b=jldzxrlE+csh1KX9wEgBaxOodlEYs1jdlHb3upkrsQZxr2RA9b70maJO7BKqQi /SAtp8T2Au4T5UqpIbfTxAAtyI8p0AdXb58qKgWazHeSM/0RXcSWJQC/DhrTBVKB 1XF2bS/J1KyrZlop+Ism8ghngv7Cou4ryC/Rx3rqEETHA= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Sat, 19 Aug 2017 02:33:06 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 3188239303.1.4196; Sat, 19 Aug 2017 02:33:05 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3059; t=1503124345; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=0qsvWJt MhQeHK9j6BNhGFh/Q0zeuQaOwI1hkmJ5KQtI=; b=JdafulA8BWrREvRtzIo/8zQ E9hJX7meWj098IX6XqnT0ma1AnA32RQBQc4bmOiYGQ18Tou0gt3TmDGwQ848yLA6 G2GrZ21mMRHdnfq2HWYfNm49g+4IX3mg3PSxEguJxE8RUq/geV59iV/AipvUjDYf jkZ8bw8IvgEe3B4ZPG3M= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Sat, 19 Aug 2017 02:32:25 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 72224546.9.3900; Sat, 19 Aug 2017 02:32:23 -0400 Message-ID: <5997DBA6.3080701@isdg.net> Date: Sat, 19 Aug 2017 02:33:10 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> <166070f0-4ba1-70da-1f73-885b4a7f7640@gmail.com> <1502497178.4103451.1070917304.23DD466D@webmail.messagingengine.com> <598F9484.7020700@isdg.net> <599484FB.9050908@isdg.net> <1502929303.4038704.1075868960.5D80A788@webmail.messagingengine.com> In-Reply-To: <1502929303.4038704.1075868960.5D80A788@webmail.messagingengine.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Aug 2017 06:33:10 -0000 On 8/16/2017 8:21 PM, Bron Gondwana wrote: > On Thu, 17 Aug 2017, at 03:46, Hector Santos wrote: >> On 8/13/2017 10:28 AM, Kurt Andersen (b) wrote: >> >> On Sat, Aug 12, 2017 at 4:51 PM, Hector Santos wrote: >> >> If we even have a DMARC ARC Policy concept, than that may be >> enough to begin pursuing the high cost of experimentation and >> development here. >> >> >> Beyond the protocol and usage specs, what are you looking for? >> >> >> A practical purpose for supporting (implementing) this work. It >> appears ARC wants the network to stamp mail "blindly" as the mail >> travels from point to point. I am trying to grasp how it helps >> resolve the main issue with "unauthorized" indirect 3rd party >> signatures, in particular when dealing with strong, exclusive DKIM >> signature policy models such as DMARC p=reject. > > We spent a while thinking about this (Neil and myself from FastMail) > at IETF99 after learning how ARC works, and came to the conclusion > that ARC as specified can't help with DMARC p=reject. > > The only way you could even hope (as a mailing list) to avoid > rewriting the sender is for every site that currently has DMARC > p=reject to change that to a new policy which explicitly means "only > reject if no ARC chain" - otherwise you can't stop rewriting sender > until you know that every receiver on your list is ARC-aware. The MLS (Mail List Server) cam also reject submissions from restrictive (p=reject) domains because that MAY be the intent of the originating author domain. The MLS can so prohibit new subscriptions by verifying the user's domain is not restrictive. We need more protocol information from what extracted from DMARC. As I see it, these are some of the boundary conditions: DMARC p=reject; arc=none; ignore ARC, same as no arc= tag DMARC p=reject; arc=all; reject if any arc seals is invalid DMARC p=reject; arc=first; don't reject if first arc seal is valid DMARC p=reject; arc=last; don't reject if last arc seal is valid DMARC p=reject; arc=first,last; don't reject if first and last arc seals are valid arc=none (or no arc= tag) means the domain has no interest whatsoever in ARC. It is a highly exclusive restricted domain and it expects that complaint DMARC readers will honor the policy. No interference. This is the highest payout with the highest security value. It gets more relax with the others; first or last or first and last, but with arc=all it is a tougher condition that requires all seals to be valid. If any fails, reject. I would also try to get more bang for the buck with a tag that could informs MLS to honor the DMARC p=reject policy by restricting users from a) subscribing and b) submitting list mail from restricted p=reject domains, although I think such a tag is needed to tell the MLS this. It should be a requirement, imo, cross all the teas, dot all the eyes. If the MLS knows its going to be problematic, it should restrict the subscription and submission to relax policies only. -- HLS From nobody Sat Aug 19 00:48:57 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24E4113219E for ; Sat, 19 Aug 2017 00:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=WAH67gny; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mcSN4gpI Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wff-VarhvUtr for ; Sat, 19 Aug 2017 00:48:54 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DEE713243E for ; Sat, 19 Aug 2017 00:48:54 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 79FF32133D for ; Sat, 19 Aug 2017 03:48:53 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Sat, 19 Aug 2017 03:48:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=mlEdcA3p555bp+PZh A0+LCDbFTMp0RuPcRnGYY36pMI=; b=WAH67gnygzORhsoE5ctUjqWxxymx9EolO WvItTu8svMMiThPHyXux8deuKwNmIlldaF4o1O38/1tB/TAgQ2VTEzFql/knAgf7 F3kOKSaYv5DfL34Y+51skE/VMjAJ/RVq1i1SVWv056SgxxTQzUrax4UP41fwV0fk aUEYBvut7Zkums5X9YxnJl3fPJx8YBSOKXXWGDKL1fX4E6JopNiT72Fv0/0MXvkq yLX85cYuRZKuMKt/kn4zDalPLo1P6gG0Nt0DOHEy5b7NL2aL+f+T85bGGT0o0eHK rsaMnC0xvb8EOwZ9AmY4iZPx1uUbb0JEcdufNxqrB7lj0eNY3Ms4g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=mlEdcA 3p555bp+PZhA0+LCDbFTMp0RuPcRnGYY36pMI=; b=mcSN4gpIfH45SB8tmyYU5o HNiwiu4f9G+QNpivVeUzg/wZT9RGtOItFY3buY1xMBJVtJkp7qOtHAu8szv6gi5/ eyj15LAygkkq2kvyDefg9fN0qUCoByhrtWLqCCMQ37jnU9TTFoQY5/gNju/uXPpi QordBj1KR+3RrpSlAwe+FaZ0AJfDCfOVY5xOJ458fRsHQNyA6YhkM0+KH0Jtu6Nv lJvuORAKZsyuNs/mz7jTfGoYFztltw+KZx/1BleswQqUxGQn+3O98USxByG/2H/6 DljC6CccmyjOttL2Co79DeWMUp4pVKduJJ4jwvbmEIJsxLV3SA8zF+qMGoNjKhrQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 44B71BAB71; Sat, 19 Aug 2017 03:48:53 -0400 (EDT) Message-Id: <1503128933.2760522.1078309768.4D8C11C9@webmail.messagingengine.com> From: Bron Gondwana To: dmarc@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150312893327605220" X-Mailer: MessagingEngine.com Webmail Interface - ajax-21c69044 Date: Sat, 19 Aug 2017 17:48:53 +1000 References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> <166070f0-4ba1-70da-1f73-885b4a7f7640@gmail.com> <1502497178.4103451.1070917304.23DD466D@webmail.messagingengine.com> <598F9484.7020700@isdg.net> <599484FB.9050908@isdg.net> <1502929303.4038704.1075868960.5D80A788@webmail.messagingengine.com> <5997DBA6.3080701@isdg.net> In-Reply-To: <5997DBA6.3080701@isdg.net> Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Aug 2017 07:48:56 -0000 This is a multi-part message in MIME format. --_----------=_150312893327605220 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Sat, 19 Aug 2017, at 16:33, Hector Santos wrote: > On 8/16/2017 8:21 PM, Bron Gondwana wrote: >> On Thu, 17 Aug 2017, at 03:46, Hector Santos wrote: >>> On 8/13/2017 10:28 AM, Kurt Andersen (b) wrote: >>> >>> On Sat, Aug 12, 2017 at 4:51 PM, Hector Santos wrote: >>> >>> If we even have a DMARC ARC Policy concept, than that may be >>> enough to begin pursuing the high cost of experimentation and >>> development here. >>> >>> >>> Beyond the protocol and usage specs, what are you looking for? >>> >>> >>> A practical purpose for supporting (implementing) this work. It >>> appears ARC wants the network to stamp mail "blindly" as the mail >>> travels from point to point. I am trying to grasp how it helps >>> resolve the main issue with "unauthorized" indirect 3rd party >>> signatures, in particular when dealing with strong, exclusive DKIM >>> signature policy models such as DMARC p=reject. >> >> We spent a while thinking about this (Neil and myself from FastMail)>> at IETF99 after learning how ARC works, and came to the conclusion >> that ARC as specified can't help with DMARC p=reject. >> >> The only way you could even hope (as a mailing list) to avoid >> rewriting the sender is for every site that currently has DMARC >> p=reject to change that to a new policy which explicitly means "only>> reject if no ARC chain" - otherwise you can't stop rewriting sender >> until you know that every receiver on your list is ARC-aware. > > The MLS (Mail List Server) cam also reject submissions from > restrictive (p=reject) domains because that MAY be the intent of the > originating author domain. The MLS can so prohibit new subscriptions> by verifying the user's domain is not restrictive. > > We need more protocol information from what extracted from DMARC. As> I see it, these are some of the boundary conditions: > > DMARC p=reject; arc=none; ignore ARC, same as no arc= tag > DMARC p=reject; arc=all; reject if any arc seals is > invalid> DMARC p=reject; arc=first; don't reject if first arc seal is> valid > DMARC p=reject; arc=last; don't reject if last arc seal is> valid > DMARC p=reject; arc=first,last; don't reject if first and last > arc seals are valid For what it's worth, the ONLY one of these which my "fake Brandon" email would have failed to validate for is p=reject, arc=none. A chain of valid ARC seals is so easy to fraudulently create that it's not funny. Everything other than arc=all there is totally pointless - if you can intercept and modify email, you can easily add ARC headers that maintain a complete chain is seals. Now arc=site2.com,site3.com,site4.com - that's valuable. You could say "only allow ARC through the following intermediate domains" - and then you could add those to your allowed list for your domain as you got reports of validation failures and user requests. Over time a domain would build a list of mail flows that its users used. You could even use a different selector for each sending user, and publish a different policy for that selector, so each user got their own allowed mail flows! But anything that's based on count/position of seals in the chain, that has no value. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_150312893327605220 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Sat, 19 Aug 2017, at 16:33, Hector Santos wrote:
On 8/16/2017 8:21 PM, Bron Gondwana wrote:
On Thu, 17 Aug 2017, at 03:46, Hector Santos wrote:
On 8/13/2017 10:28 AM, Kurt Andersen (b) wrote:

  On Sat, Aug 12, 2017 at 4:51 PM, Hector Santos wrote:

    If we even have a DMARC ARC Policy concept, than that may be
    enough to begin pursuing the high cost of experimentation and
    development here.


  Beyond the protocol and usage specs, what are you looking for?


A practical purpose for supporting (implementing) this work.   It
appears ARC wants the network to stamp mail "blindly" as the mail
travels from point to point.  I am trying to grasp how it helps
resolve the main issue with "unauthorized" indirect 3rd party
signatures, in particular when dealing with strong, exclusive DKIM
signature policy models such as DMARC p=reject.

We spent a while thinking about this (Neil and myself from FastMail)
at IETF99 after learning how ARC works, and came to the conclusion
that ARC as specified can't help with DMARC p=reject.

The only way you could even hope (as a mailing list) to avoid
rewriting the sender is for every site that currently has DMARC
p=reject to change that to a new policy which explicitly means "only
reject if no ARC chain" - otherwise you can't stop rewriting sender
until you know that every receiver on your list is ARC-aware.

The MLS (Mail List Server) cam also reject submissions from
restrictive (p=reject) domains because that MAY be the intent of the
originating author domain.   The MLS can so prohibit new subscriptions
by verifying the user's domain is not restrictive.

We need more protocol information from what extracted from DMARC.  As
I see it, these are some of the boundary conditions:

    DMARC p=reject;  arc=none;       ignore ARC, same as no arc= tag
    DMARC p=reject;  arc=all;        reject if any arc seals is invalid
    DMARC p=reject;  arc=first;      don't reject if first arc seal is
valid
    DMARC p=reject;  arc=last;       don't reject if last arc seal is
valid
    DMARC p=reject;  arc=first,last; don't reject if first and last
arc seals are valid

For what it's worth, the ONLY one of these which my "fake Brandon" email would have failed to validate for is p=reject, arc=none.  A chain of valid ARC seals is so easy to fraudulently create that it's not funny.

Everything other than arc=all there is totally pointless - if you can intercept and modify email, you can easily add ARC headers that maintain a complete chain is seals.

Now arc=site2.com,site3.com,site4.com - that's valuable.  You could say "only allow ARC through the following intermediate domains" - and then you could add those to your allowed list for your domain as you got reports of validation failures and user requests.  Over time a domain would build a list of mail flows that its users used.   You could even use a different selector for each sending user, and publish a different policy for that selector, so each user got their own allowed mail flows!

But anything that's based on count/position of seals in the chain, that has no value.

Bron.


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


--_----------=_150312893327605220-- From nobody Sat Aug 19 08:22:26 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3595132926 for ; Sat, 19 Aug 2017 08:22: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=isdg.net header.b=Fy/1k7zL; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=qd4DRpGu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15a6H4p-cyBb for ; Sat, 19 Aug 2017 08:22:21 -0700 (PDT) Received: from mail.santronics.com (pop3.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id F0D511323C9 for ; Sat, 19 Aug 2017 08:22:20 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3179; t=1503156136; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=DAV9d1kRd/mjnVhImEjhEJMOllQ=; b=Fy/1k7zLrgADzVI3kt1uOp6Ma4+NMO00wAMEDCoMycnrwPhxpJ+J0hcpBetGRv VjAdRBx2fJXwLJ7WJFWv+jvI8H5a0f6fLFhJFfly3/ioxXDOJF44tQ7yb3lh+XZh HerAE1W42puTXxunLHBY7MUb/rmZxsujesRHezTzOortk= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Sat, 19 Aug 2017 11:22:16 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 3219989812.1.3528; Sat, 19 Aug 2017 11:22:16 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3179; t=1503156095; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=h5I66ML CRSEyACXjNJjbN1CPyUnNRdL34V0c2T7Wt5k=; b=qd4DRpGuVptVSWndPdoGkoL nGeHcHhy0TlANcp3bxwSJgHRKn3/N/eBgmGolOa0T8AYKz8Y5VwV8lw9VKy/ULBX TKUVJHIcKQmFUsK/KA3xLzmw1ue0tEdicd2HmCeFQbfW60I8F6Fp5O9WXNDCCUt5 6rUTmknERXwrY2y9wu4o= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Sat, 19 Aug 2017 11:21:35 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 103975687.9.5512; Sat, 19 Aug 2017 11:21:34 -0400 Message-ID: <599857AE.2090708@isdg.net> Date: Sat, 19 Aug 2017 11:22:22 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: Bron Gondwana , dmarc@ietf.org References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> <166070f0-4ba1-70da-1f73-885b4a7f7640@gmail.com> <1502497178.4103451.1070917304.23DD466D@webmail.messagingengine.com> <598F9484.7020700@isdg.net> <599484FB.9050908@isdg.net> <1502929303.4038704.1075868960.5D80A788@webmail.messagingengine.com> <5997DBA6.3080701@isdg.net> <1503128933.2760522.1078309768.4D8C11C9@webmail.messagingengine.com> In-Reply-To: <1503128933.2760522.1078309768.4D8C11C9@webmail.messagingengine.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Aug 2017 15:22:24 -0000 On 8/19/2017 3:48 AM, Bron Gondwana wrote: > For what it's worth, the ONLY one of these which my "fake Brandon" > email would have failed to validate for is p=reject, arc=none. A > chain of valid ARC seals is so easy to fraudulently create that it's > not funny. > > Everything other than arc=all there is totally pointless - if you can > intercept and modify email, you can easily add ARC headers that > maintain a complete chain is seals. > > Now arc=site2.com,site3.com,site4.com - that's valuable. I agree. That is what the ATPS (Authorized Third Party Signature) and the ASL (Authorized Sender List) proposals was all about. https://tools.ietf.org/html/rfc6541 Check out this wizard that helps generate the appropriate ATPS records and/or ASL extended DMARC tags: http://www.winserver.com/public/wcdmarc/default.wct But many feel it doesn't scale. We also called it a "registration" problem, i.e. how to get that authorized list, etc. What has been going since then is to develop a method to inherently pass this information via the headers. Thats been hard to understand since we are already making a DMARC DNS lookup that perpetuates all this. We are just not getting enough information to properly work with it. > You could > say "only allow ARC through the following intermediate domains" - and > then you could add those to your allowed list for your domain as you > got reports of validation failures and user requests. Over time a > domain would build a list of mail flows that its users used. You > could even use a different selector for each sending user, and publish > a different policy for that selector, so each user got their own > allowed mail flows! > > But anything that's based on count/position of seals in the chain, > that has no value. I fully concur with the "level of "experimentations" that would give all parties, a payoff they can realize and the capability to design a logical integrated system and negotiate3ed protocol without kludges and also apply some "Deep Learning" to help with the indeterminate conditions. We have determinate conditions with the strong policies. These MUST be honored or nothing works. This is the DKIM POLICY LAYER MODEL. The indeterminate conditions are the relaxed policies leaving it up to the receiver to explore algorithms. This is the DKIM TRUST/REPUTATION LAYER MODEL. The DKIM standard purposely removed the Policy Layer with the hope the trust layer would prevail. Many folks did not like this decision. It was extremely rough and we didn't have other developers, such as yourself around. But as expected, it didn't happen and the problems we are seeing is due to that separation. That said, I still expect it to happen because Policy gives us the first level automation (thanks to DMARC), and Trust/Reputation is the 2nd level to help with the fuzzy conditions. This is where it will be a vendor-based added value component to DKIM, as it was designed to be and should be. But as it was always stated, not everyone is going to use the same "Trust/Reputation" databases. I called that the "Batteries Required" dilemma. -- HLS From nobody Sun Aug 20 10:00:45 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD761323FD for ; Sun, 20 Aug 2017 10:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fiction.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 nmzJG7ZYwr_h for ; Sun, 20 Aug 2017 10:00:41 -0700 (PDT) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::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 DC22A1321A4 for ; Sun, 20 Aug 2017 10:00:39 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id n29so16777963uai.5 for ; Sun, 20 Aug 2017 10:00:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fiction.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZQjUbMX/ABXsOI5W5oP5gYAoT4AFTYTVkAuNdNAAIsY=; b=dVkx0vw5DFTb50g9aFEDSlMS5bkOpLDejZBptdCDNOtH+VgHU4I6qmOC8obNfX+a9k 9N5pYgQOmuZEyjcSzLQ95COmOMHiOEvhMfUiEW5XsBQn20EPfsxN78i+xMYTtlZzEtWN Qc4lOQ4XRZxSjrmVWptJyuHHFEuiQFLqY50ltcYLIC5AxslGg5VZcSVSELJNJeFWHSQh YiXCPj3Bket6zbjkUNJvCrnd20uToCo41OFFkIQk8Mx3c+aANcmYIjXe7N/t/EF6UvpY OT1uCMZtc2tEso883fy9PXbHx3XYiBZYgziB2gtj1bS0u4d6Y3pGyq9YbeZzxPqMHM6v DqFg== 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=ZQjUbMX/ABXsOI5W5oP5gYAoT4AFTYTVkAuNdNAAIsY=; b=FHlKKNsGiDSAdsgfvHlmsSRekHv5R7hRh5mMBeC0eLjFJmco3WT3tFP/Dst+FGBCYn OAxPUEUoJ6G9zkb64Om69l23YuIqY9asSSFXEASnDt9NL8hju4ZuVuH0wSFNSJJqg3Mx E0qEU/FDkv548HUHj4iy3w8VACwY5vd5gw1bCatpMxrQ7F2tIgMUFhP/SBDjY+gJA5uT js1vqdhuLQqGkY+qIKiQzt3S11m0LeJ8MUDV9O1rUMVTA8dQoIkAkIKqHVYJNmxuQXBo e+KwMK1jIRoLJ88fyp4o84+cblm/F39YK9NwGSIq7plcf5OlIMeD84hBbcau8PoLPE6I w8eA== X-Gm-Message-State: AHYfb5hKOw+sQfDZ8xQimUnyqNRKe90cZkBq0BDcYAl2vXFBiZNWIRv+ 6acWkOBUZFebHd/+WDY= X-Received: by 10.176.71.82 with SMTP id i18mr10148440uac.171.1503248438977; Sun, 20 Aug 2017 10:00:38 -0700 (PDT) Received: from mail-ua0-f172.google.com (mail-ua0-f172.google.com. [209.85.217.172]) by smtp.gmail.com with ESMTPSA id k33sm2399413uaf.37.2017.08.20.10.00.38 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 20 Aug 2017 10:00:38 -0700 (PDT) Received: by mail-ua0-f172.google.com with SMTP id n29so16777932uai.5 for ; Sun, 20 Aug 2017 10:00:38 -0700 (PDT) X-Received: by 10.159.49.205 with SMTP id w13mr9572245uad.18.1503248437844; Sun, 20 Aug 2017 10:00:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.135.139 with HTTP; Sun, 20 Aug 2017 10:00:37 -0700 (PDT) Received: by 10.103.135.139 with HTTP; Sun, 20 Aug 2017 10:00:37 -0700 (PDT) In-Reply-To: <1503104028.2682226.1078138680.6C07899A@webmail.messagingengine.com> References: <1503104028.2682226.1078138680.6C07899A@webmail.messagingengine.com> From: Brandon Long Date: Sun, 20 Aug 2017 10:00:37 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Bron Gondwana Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="001a1146820a26194f0557324d01" Archived-At: Subject: Re: [dmarc-ietf] About "non-rewindable crypto" X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2017 17:00:43 -0000 --001a1146820a26194f0557324d01 Content-Type: text/plain; charset="UTF-8" Can you do that and it's still possible to validate that site2 signed it? Brandon On Aug 18, 2017 5:53 PM, "Bron Gondwana" wrote: > So this is an interesting case that I'd like to spin into a separate > thread. > > At the moment, ARC headers are purely additive. You receive a message > with some ARC headers on it, you add some more on top and send it on. > > AR: arc=pass, ... // at receiver > AS: i=3; cv=pass, d=site4.com > AMS: i=3; d=site4.com > AAR: i=3; arc=pass > AS: i=2; cv=pass, d=site3.com > AMS: i=2; d=site3.com > AAR: i=2; arc=pass > AS: i=1; cv=none, d=site2.com > AMS: i=1; d=site2.com > AAR: i=1; arc=none; dkim=pass > DKIM-Signature: d=site1.com > > site1 => site2 => site3 => site4 => receiver > > Somebody who obtains a copy of that message could then trim the message > back: > > AS: i=2; cv=pass, d=site3.com > AMS: i=2; d=site3.com > AAR: i=2; arc=pass > AS: i=1; cv=none, d=site2.com > AMS: i=1; d=site2.com > AAR: i=1; arc=none; dkim=pass > DKIM-Signature: d=site1.com > > And pretend that the message was sent from site3 down a different path: > > AR: arc=pass, ... // at receiver > AS: i=3; cv=pass, d=badsite.com > AMS: i=3; d=badsite.com > AAR: i=3; arc=pass > AS: i=2; cv=pass, d=site3.com > AMS: i=2; d=site3.com > AAR: i=2; arc=pass > AS: i=1; cv=none, d=site2.com > AMS: i=1; d=site2.com > AAR: i=1; arc=none; dkim=pass > DKIM-Signature: d=site1.com > > And the message still arrives at receiver with a valid ARC chain, just via > badsite.com instead of site3.com. > > It is possible to do things with crypto, mixing in hashes, such that you > not only add new headers, but you rewrite past headers such that the > original versions of them can't be reconstructed any more. Which would > mean that if you could intercept a copy at the receiver, you couldn't trim > back to i=2 and restart the chain on that message. It would mean header > replacement rather than just header addition though. > > Is this something that would have enough interest to be worth pursuing? > It's bound to be more complex than ARC-as-defined, but it also makes faking > mail flows a lot harder, because you would have to intercept the message > between site3 and site4 if you wanted to fake the mail flow from site3 - > you couldn't just pick it up later. > > Bron. > > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --001a1146820a26194f0557324d01 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Can you do that and it's still possible to validate t= hat site2 signed it?

Brandon

On Aug = 18, 2017 5:53 PM, "Bron Gondwana" <brong@fastmailteam.com> wrote:
So this is an interesting case that I= 'd like to spin into a separate thread.

At the moment, ARC headers are purely addi= tive.=C2=A0 You receive a message with some ARC headers on it, you add some= more on top and send it on.

AR: arc=3Dpass, ...=C2=A0 // at receiver
AS: i=3D3; cv=3Dpass, d=3Dsite4.com
AMS: i=3D= 3; d=3Dsite4.com
AAR: i=3D3; arc=3Dpass
AS: i=3D2= ; cv=3Dpass, d=3Dsite3.com
AAR: i=3D2; arc=3Dpass
AS: i=3D1= ; cv=3Dnone, d=3Dsite2.com
AAR: i=3D1; arc=3Dnone; dkim=3Dpass
DKIM-Signature: d=3Dsite1.com

site1 =3D> site2 =3D> site3 =3D> = site4 =3D> receiver

Somebody who obtains a copy of that messag= e could then trim the message back:

AS: i=3D2; cv=3Dpass, d=3Dsite3.com
AMS: i=3D= 2; d=3Dsite3.com
AAR: i=3D2; arc=3Dpass
AS: i=3D1= ; cv=3Dnone, d=3Dsite2.com
AAR: i=3D1; arc=3Dnone; dkim=3Dpass
DKIM-Signature: d=3Dsite1.com

And pretend that the message was sent from= site3 down a different path:

AR: arc=3Dpass, ...=C2=A0 // at receiver
AS: i=3D3; cv=3Dpass, d=3Dbadsite.com
AMS: i=3D= 3; d=3Dbadsite.com
=
AAR: i=3D3; arc=3Dpass
AS: i=3D2= ; cv=3Dpass, d=3Dsite3.com
AAR: i=3D2; arc=3Dpass
AS: i=3D1= ; cv=3Dnone, d=3Dsite2.com
AAR: i=3D1; arc=3Dnone; dkim=3Dpass
DKIM-Signature: d=3Dsite1.com

And the message still arrives at receiver = with a valid ARC chain, just via badsite.com instead of site3.com.

It is possible to do things with crypto, = mixing in hashes, such that you not only add new headers, but you rewrite p= ast headers such that the original versions of them can't be reconstruc= ted any more.=C2=A0 Which would mean that if you could intercept a copy at = the receiver, you couldn't trim back to i=3D2 and restart the chain on = that message.=C2=A0 It would mean header replacement rather than just heade= r addition though.

Is this something that would have enough i= nterest to be worth pursuing?=C2=A0 It's bound to be more complex than = ARC-as-defined, but it also makes faking mail flows a lot harder, because y= ou would have to intercept the message between site3 and site4 if you wante= d to fake the mail flow from site3 - you couldn't just pick it up later= .

Bron.

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



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

--001a1146820a26194f0557324d01-- From nobody Sun Aug 20 16:34:25 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A67841321D5 for ; Sun, 20 Aug 2017 16:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=ISE94/Vt; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=j80F7dIY Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWUvOhZH2mUB for ; Sun, 20 Aug 2017 16:34:21 -0700 (PDT) Received: from catinthebox.net (pop3.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id AFD111321BE for ; Sun, 20 Aug 2017 16:34:20 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=308; t=1503272055; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=J59TfTfKUx8SBTHoCVWzmuHTanE=; b=ISE94/VtMRW5nrtbo7mGd5j+f3xE585j7nCp55EEdy6/2T3xS37ALi3ekJFaB1 F7TvlSkOx1vnGBRVVdT97/SPXVImVDCaczPaA6E6JYCC6CugGjrU4EuOYMRYsMzN fV75g9Z5l6+CiaVjfOt/vWUIykw0XMtMShqamAhM3eoUE= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Sun, 20 Aug 2017 19:34:15 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 3335906761.1.4088; Sun, 20 Aug 2017 19:34:14 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=308; t=1503272007; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=oqXUzG4 r6//empfz6LKCpOLqmSbgz5NSed+lhOeqefU=; b=j80F7dIY+gr+ICf57RPEVXV XvWIEfveUkEY6DFbaCDIl6NGWFBHjDTwIZnGWUdaNvY0HAK5oTUS4zPMNWo2K4hU m0H4wyIUXI72J+Gh34UgxtbjCqHJoWeo6pq1mG6dUTjCxml1PofAfwWENte+K2En g5jtuHdvVUCUml1PQRrE= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Sun, 20 Aug 2017 19:33:27 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 219886593.9.8632; Sun, 20 Aug 2017 19:33:25 -0400 Message-ID: <599A1C70.7050200@isdg.net> Date: Sun, 20 Aug 2017 19:34:08 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <1503104028.2682226.1078138680.6C07899A@webmail.messagingengine.com> In-Reply-To: <1503104028.2682226.1078138680.6C07899A@webmail.messagingengine.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] About "non-rewindable crypto" X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2017 23:34:24 -0000 On 8/18/2017 8:53 PM, Bron Gondwana wrote: > ... > > And the message still arrives at receiver with a valid ARC chain, just > via badsite.com instead of site3.com. The same receiver? If so, wouldn't this be a duplicate message when the same receiver can see the same 5322.Message-Id? -- HLS From nobody Sun Aug 20 16:47:34 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D37C1321E6 for ; Sun, 20 Aug 2017 16:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=Bz8YsUsi; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JDNPAirg Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMPwTq7FQO06 for ; Sun, 20 Aug 2017 16:47:31 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96B7B1321E3 for ; Sun, 20 Aug 2017 16:47:31 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 137E920B1E for ; Sun, 20 Aug 2017 19:47:31 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Sun, 20 Aug 2017 19:47:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=XQrAWAbbhOG1lQkPS 9YQsIMrwBhN5qxETgMdIhNR74M=; b=Bz8YsUsit1ynEucODJKQsSVz/h7gDTIy3 SnRwQQ5Blio+XqqLO9N3GfdwxgE5XUIIqqfy9vWrrgfDJo08JX2FYyegROlCogBl Lxkyc/CAKyfr81AJUO/6RxpY5J4u7MlBXzTTROG0cmcfLkKMNZSw5MuAyUEycAlw C/PxGZHBXoOuEcA9mJSg42s5D4TrbyZ6IKTGWsSHs//xG/IZJHv7H6VyUnWO/OFF 67uBCbZDFopMDPTcJaGdwsh0+ikEGt2N2nYjLCdgcMTPOtv1WKhKy+rQ8SxCXZ1O HvYIGkNfJX1In4O9puolLFWZ0sSOrpHuhxI4QTj6AIok57i1tw5fQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=XQrAWA bbhOG1lQkPS9YQsIMrwBhN5qxETgMdIhNR74M=; b=JDNPAirgmE9pTv3gUh4pd2 w69k/OuBFILZ5UTwmUvlmn3kxh9XHuizGnCDo9foKYgYwR3pWEE7866clyEkMdC/ iyrUCeJe2mmZ2eNRJ1Mg0U7Y1hC5zTsVEaV2wTdpII97+qAgd34U+dgoKl9V1ZXW 8dG9LcId3oLAQJCW9qPpL2soqLdVckMz2K1eM1o5RIMAkF/BPnt2s6gke3DwBFff MzStDMSLusPCUwHCpRtYMLQKoXmod5Ng8F3MNeqfoiEIuEpnQFm51qi+DM1G1iJv A5vV8FGEriR2kWVCZvl6GrR88IBI+nFRYRbw1VK5knlQjzmKy+jrhzUVFIIQ0Bpg == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id D4EB66264D; Sun, 20 Aug 2017 19:47:30 -0400 (EDT) Message-Id: <1503272850.655355.1079444872.679578A8@webmail.messagingengine.com> From: Bron Gondwana To: dmarc@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15032728506553551" X-Mailer: MessagingEngine.com Webmail Interface - ajax-21c69044 References: <1503104028.2682226.1078138680.6C07899A@webmail.messagingengine.com> <599A1C70.7050200@isdg.net> Date: Mon, 21 Aug 2017 09:47:30 +1000 In-Reply-To: <599A1C70.7050200@isdg.net> Archived-At: Subject: Re: [dmarc-ietf] About "non-rewindable crypto" X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2017 23:47:33 -0000 This is a multi-part message in MIME format. --_----------=_15032728506553551 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Mon, 21 Aug 2017, at 09:34, Hector Santos wrote: > On 8/18/2017 8:53 PM, Bron Gondwana wrote: > >> ... >> >> And the message still arrives at receiver with a valid ARC >> chain, just>> via badsite.com instead of site3.com. > > The same receiver? If so, wouldn't this be a duplicate message when > the same receiver can see the same 5322.Message-Id? There is nothing stopping you changing the 5322.Message-Id - it's not encoded in the AS or AAR. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_15032728506553551 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Mon, 21 Aug 2017, at 09:34, Hector Santos wrote:
On 8/18/2017 8:53 PM, Bron Gondwana wrote:

...

And the message still arrives at receiver with a valid ARC chain, just
via badsite.com instead of site3.com.

The same receiver?  If so, wouldn't this be a duplicate message when
the same receiver can see the same 5322.Message-Id?

There is nothing stopping you changing the 5322.Message-Id - it's not encoded in the AS or AAR.

Bron.


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


--_----------=_15032728506553551-- From nobody Sun Aug 20 17:04:23 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B704D1323B1 for ; Sun, 20 Aug 2017 17:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=CmoAxgjO; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=j0l0OII0 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xm-1-LWNu2Y for ; Sun, 20 Aug 2017 17:04:20 -0700 (PDT) Received: from catinthebox.net (ntbbs.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id AA0B01323A7 for ; Sun, 20 Aug 2017 17:04:20 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=910; t=1503273855; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=9y6QtphpjxtBiO/ZiYgafIAJ92s=; b=CmoAxgjOg0TwqdZ3Cj2oHPXD/Me4NHCUCkfNhMOXcUtveYj7dLyPz89iP6dU7y srfg3QMZMBytpQshh0cgwoY/OIlMLeq/qx5z+2Yqai6hZXA8fvc1JJ2JzFO6V+8D ZhflNsHjN1CIo1eGuoPavh4dGmq1QBHNXci5fm5cX57DU= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Sun, 20 Aug 2017 20:04:15 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 3337706856.1.4248; Sun, 20 Aug 2017 20:04:14 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=910; t=1503273810; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=jCbDf7v xQZKgfxTjkYTXTbOFNeaEscWojFF2pM1xgUQ=; b=j0l0OII0I6xhCkjIDU445iE 6JivXL9dohIgj93outobYAhj2pmsebEanTM8FjtZvEysgn10HFj8BKUo//2xtGhM Nxv/tblpWlMpPNman1Vo6Syx3eeM6oinH6akVGIOB1S2TYvrEFpZfT28j6rJgjfx 2+d9HDchaj2g9RjOB+Rc= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Sun, 20 Aug 2017 20:03:30 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 221690906.9.5684; Sun, 20 Aug 2017 20:03:30 -0400 Message-ID: <599A237C.9030303@isdg.net> Date: Sun, 20 Aug 2017 20:04:12 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <1503104028.2682226.1078138680.6C07899A@webmail.messagingengine.com> <599A1C70.7050200@isdg.net> <1503272850.655355.1079444872.679578A8@webmail.messagingengine.com> In-Reply-To: <1503272850.655355.1079444872.679578A8@webmail.messagingengine.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] About "non-rewindable crypto" 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, 21 Aug 2017 00:04:23 -0000 On 8/20/2017 7:47 PM, Bron Gondwana wrote: > On Mon, 21 Aug 2017, at 09:34, Hector Santos wrote: >> On 8/18/2017 8:53 PM, Bron Gondwana wrote: >> >> ... >> >> And the message still arrives at receiver with a valid ARC >> chain, just >> via badsite.com instead of site3.com. >> >> >> The same receiver? If so, wouldn't this be a duplicate message when >> the same receiver can see the same 5322.Message-Id? > > There is nothing stopping you changing the 5322.Message-Id - it's not > encoded in the AS or AAR. It is protected by the original DKIM-Signature. Message-Id is pretty high on the recommended hashed header list. But if the original DKIM signature was lost, all bets are off and nothing else matters unless ARC is attempting to replace DKIM which you just illustrated it is quite easy to create alternate paths, even when its not all to the same final destination. -- HLS From nobody Sun Aug 20 18:25:39 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC5B132833 for ; Sun, 20 Aug 2017 18:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=mI5bjE4k; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KgMH1eF4 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VADFf_fJRpRL for ; Sun, 20 Aug 2017 18:25:35 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5122F132356 for ; Sun, 20 Aug 2017 18:25:35 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id AD33220DB8 for ; Sun, 20 Aug 2017 21:25:34 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Sun, 20 Aug 2017 21:25:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=yH1QQg9dS21kukFTY uLd6wyOsDV8Ctdy6yPiZ1NS3J8=; b=mI5bjE4ks+yqnqrBHL4Nr7ImonVgH2K5y wTbzgUTCKiuIiMeTJrEkAu6CZ+OptYpkfUrbRP8qM+A/RwbWFDkG8ZjQNBkEBeJt 2XwxOjyd5+59wJQUnaxtFFE2up2y8zwrVtpoD/ul4wdEwQ5PCuWUDxyVWH9mwibP L2NPU2OVQzSNTLwGvoP+MSCXK8CPdraREqOxG8c/x6H+MYlcRGRtF2y0EN5GRsTm +mwizbu0hUobeoMOXxixFEKp3RNyHmapVmUKcel3V6RweCA1AbGmcZPcT1M3Lhtx NepvQf3pYITQEgHgaIDXk0b4Sz0bNhvH95SRRftYCHNyR5EIY2ouA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=yH1QQg 9dS21kukFTYuLd6wyOsDV8Ctdy6yPiZ1NS3J8=; b=KgMH1eF4i+QD+BQIzU7KCW wH3ZKPbEeWcLBEBTuoh87fmbzOTPMPR1XQwNaLyXSX+hBiDxySLx///Q3wv/1jiI zi218qwxrrp1tD//nrYYnOLJCNEW7bdPMqhE0s4qJB4pmHsUgg0LayhdKxpfJvzm cM8lSv5HMg3rWlAJFFKXV9rbHfUnLjn8yVpq2XM356TjqzVRAqBHjy1/nhPdRBkU LNjq/a5UQMrJ+3MAE4WiLhhUUVj5lyd2NBsMTNtNxj/VD7+pFegSrf72yxLlSBwz qTtLhd5YoRe9CCbIDEPQnsOAtDOWrpe1dds/1DVXDX8YFbeNgopHon4/DRkjl2Pg == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 8BBCB9E2C3; Sun, 20 Aug 2017 21:25:34 -0400 (EDT) Message-Id: <1503278734.2705712.1079502928.44F6A29D@webmail.messagingengine.com> From: Bron Gondwana To: dmarc@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150327873427057120" X-Mailer: MessagingEngine.com Webmail Interface - ajax-21c69044 In-Reply-To: <599A237C.9030303@isdg.net> References: <1503104028.2682226.1078138680.6C07899A@webmail.messagingengine.com> <599A1C70.7050200@isdg.net> <1503272850.655355.1079444872.679578A8@webmail.messagingengine.com> <599A237C.9030303@isdg.net> Date: Mon, 21 Aug 2017 11:25:34 +1000 Archived-At: Subject: Re: [dmarc-ietf] About "non-rewindable crypto" 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, 21 Aug 2017 01:25:38 -0000 This is a multi-part message in MIME format. --_----------=_150327873427057120 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Mon, 21 Aug 2017, at 10:04, Hector Santos wrote: > On 8/20/2017 7:47 PM, Bron Gondwana wrote: >> On Mon, 21 Aug 2017, at 09:34, Hector Santos wrote: >>> On 8/18/2017 8:53 PM, Bron Gondwana wrote: >>> >>> ... >>> >>> And the message still arrives at receiver with a valid ARC >>> chain, just >>> via badsite.com instead of site3.com. >>> >>> >>> The same receiver? If so, wouldn't this be a duplicate message when>>> the same receiver can see the same 5322.Message-Id? >> >> There is nothing stopping you changing the 5322.Message-Id - it's not>> encoded in the AS or AAR. > > It is protected by the original DKIM-Signature. Message-Id is pretty > high on the recommended hashed header list. > > But if the original DKIM signature was lost, all bets are off and > nothing else matters unless ARC is attempting to replace DKIM which > you just illustrated it is quite easy to create alternate paths, even> when its not all to the same final destination. Right - so how exactly does that help, given that you've modified the message since then? You could easily change the message-id at the same time. If the original DKIM-Signature still passes then sure, you can't modify anything. But then you don't need ARC anyway. If the DKIM signature allowed you to tell that some of the protected headers were unchanged while allowing others to change, then it would mean something - but the whole point of ARC is for when DKIM doesn't validate any more, and if DKIM doesn't validate any more then the message- id can be spoofed too. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_150327873427057120 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Mon, 21 Aug 2017, at 10:04, Hector Santos wrote:
On 8/20/2017 7:47 PM, Bron Gondwana wrote:
On Mon, 21 Aug 2017, at 09:34, Hector Santos wrote:
On 8/18/2017 8:53 PM, Bron Gondwana wrote:

  ...

  And the message still arrives at receiver with a valid ARC
  chain, just
  via badsite.com instead of site3.com.


The same receiver?  If so, wouldn't this be a duplicate message when
the same receiver can see the same 5322.Message-Id?

There is nothing stopping you changing the 5322.Message-Id - it's not
encoded in the AS or AAR.

It is protected by the original DKIM-Signature. Message-Id is pretty
high on the recommended hashed header list.

But if the original DKIM signature was lost, all bets are off and
nothing else matters unless ARC is attempting to replace DKIM which
you just illustrated it is quite easy to create alternate paths, even
when its not all to the same final destination.

Right - so how exactly does that help, given that you've modified the message since then?  You could easily change the message-id at the same time.  If the original DKIM-Signature still passes then sure, you can't modify anything.  But then you don't need ARC anyway.

If the DKIM signature allowed you to tell that some of the protected headers were unchanged while allowing others to change, then it would mean something - but the whole point of ARC is for when DKIM doesn't validate any more, and if DKIM doesn't validate any more then the message-id can be spoofed too.

Bron.

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


--_----------=_150327873427057120-- From nobody Mon Aug 21 04:47:08 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E28F81329EB for ; Mon, 21 Aug 2017 04:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=FXKCGqmO; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=Tpk2q2P8 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Inma1EhSP3T for ; Mon, 21 Aug 2017 04:47:04 -0700 (PDT) Received: from mail.catinthebox.net (secure.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 54F95132351 for ; Mon, 21 Aug 2017 04:47:04 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2623; t=1503316016; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=RrJIRHB5l+yeZdJK3IMPiIJlf0U=; b=FXKCGqmOqv0Uz0EWDTTwtwTq4bn1eMbU5tEfJrJYFiaaS+aANq87FwiYq30j82 yhPnOM+XQOoPmbiObqZ8WZadOQbRKTRL03PCgevcILovBVvMK5Rfdb6dOfVSpQEx 9gXoXcCEkEZDyGFNDJjnnnN+dWXCf54nDxiHJU/5ZlDO8= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Mon, 21 Aug 2017 07:46:56 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 3379867640.1.2632; Mon, 21 Aug 2017 07:46:55 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2623; t=1503315970; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=9jVSCVe QPCkgq2Qosd02e/qvoU4Dc2nyG0oYD7pvkvo=; b=Tpk2q2P8zvp8md5bVN7DNKC XqfSZ0fTPDa49OjgXrstqFsvaWdy3YEA6w4ZwvgbVEl4B/ouwBQ6F8WOPaf09Npb 0yxSeHztHtMNNOuK00fPuYo1kvJY2TgnauqLYMMfhVQQM2gO8qktgmDdQ1MvU5hJ ftlZioO+hL7Z+Dq7MCPE= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Mon, 21 Aug 2017 07:46:10 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 263850843.9.4664; Mon, 21 Aug 2017 07:46:10 -0400 Message-ID: <599AC82E.4020305@isdg.net> Date: Mon, 21 Aug 2017 07:46:54 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <1503104028.2682226.1078138680.6C07899A@webmail.messagingengine.com> <599A1C70.7050200@isdg.net> <1503272850.655355.1079444872.679578A8@webmail.messagingengine.com> <599A237C.9030303@isdg.net> <1503278734.2705712.1079502928.44F6A29D@webmail.messagingengine.com> In-Reply-To: <1503278734.2705712.1079502928.44F6A29D@webmail.messagingengine.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] About "non-rewindable crypto" 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, 21 Aug 2017 11:47:07 -0000 On 8/20/2017 9:25 PM, Bron Gondwana wrote: >> >> It is protected by the original DKIM-Signature. Message-Id is pretty >> high on the recommended hashed header list. >> >> But if the original DKIM signature was lost, all bets are off and >> nothing else matters unless ARC is attempting to replace DKIM which >> you just illustrated it is quite easy to create alternate paths, even >> when its not all to the same final destination. > > Right - so how exactly does that help, given that you've modified the > message since then? You could easily change the message-id at the > same time. If the original DKIM-Signature still passes then sure, you > can't modify anything. But then you don't need ARC anyway. > > If the DKIM signature allowed you to tell that some of the protected > headers were unchanged while allowing others to change, then it would > mean something - but the whole point of ARC is for when DKIM doesn't > validate any more, and if DKIM doesn't validate any more then the > message-id can be spoofed too. Which brings us back to square one, the lost of the 1st party association with the author-domain and the signer-domain whose signature is broken. ARC needs to re-establish this association if its going to grab the "security baton" from DKIM. I presume the first seal is the association. Any other subsequent seal is beyond the author-domain understanding (unknown) other than its expected to be valid chain to the end which the receiver can verify. So one way to mitigate the "Chain Trimming" problem is to a) reseal the message-id and b) provide insight of the expected final destination. List servers are now resigning and not to beat on the proverbial dead horse, we don't have the 3rd party association to work with. ARC is trying to change that, I suppose. DKIM supports the concept of user tags. I've explore this. You will notice in my isdg.net DKIM-signature, it will have atps= tag; DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=910; t=1503273855; atps=ietf.org; atpsh=sha1; signifying the list domain, ietf.org, is the expected authorized resigner and can be trusted. As long as the original signature is valid, that tag can be used by the receiver to confirm the resigner. But that signature is lost. I guess, overall, if ARC reason to exist is because of lost of original signatures, and it has a trimming problem, then this should not to be taken lightly. It will suggest there several original DKIM hashed headers that need to be preserved in order to mitigate the potential issue. -- HLS From nobody Wed Aug 23 15:29:27 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D816513236D for ; Wed, 23 Aug 2017 15:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fiction.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 oXh4hcSAaW8A for ; Wed, 23 Aug 2017 15:29:22 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41C551321A2 for ; Wed, 23 Aug 2017 15:29:22 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id w17so5339441uaw.3 for ; Wed, 23 Aug 2017 15:29:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fiction.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MkszM6XAzHuDx+TEYHMJG2y6zxsxUahqsDsudZXrUic=; b=eBFpQ6+jWK9Y5DI0RQcXtIchy24Dnrj4U2+UW9jiTZnK0CJIeSbweREvFlj4f0WEV5 ongdrS88AONfl4dMMFIZL4S7uHCOCB8U1dZ/lH4umMeO0XwlJ0YMvtQ/EkiHnRCSMNRg a0Src2tZe8a/ySWZldHUOQFKzTgiRM44kDfmDjTZeOEbZPP5BZNCC4vvNuyzTEKrbBH0 SYRamu0PaWxcc9uumRbgFO8dkm0K4piNcS+XAlj5B5PhMYOFCKTNl/0vDIp9DPzTzjQv LslaFEl37WtwQ9fqqYMfieqk3LFPM3/Q7HuSV9PrglTS7pD+AobC/nJO8edZqddfaOP9 hiMA== 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=MkszM6XAzHuDx+TEYHMJG2y6zxsxUahqsDsudZXrUic=; b=AYLHnGf3J+77MMJbbHYg3ETz+YETw+CT7LAJ7k6w8doynC6K9tfT9gCpNkX+ANgwo9 b84PbMzPlsDgM7p9drMpJPD2MGJXQ/jTYJS3yiHl9vvaItysDmyu63fVzR51M5U/ls4e F8OPmrQer/Ofnd6/0BzmDZhNovcuLkP++M3DhQcNhngOdfhtc8/OvwDSj6zwjfN2rUx+ 47Ne1C1GeR4q0g6yejF5jcnGeLCTHt6eQDs8zO7oChhP7tmBg5zasvlUuuQorcfK3U14 ct6p693kD+jGMaSPRivSwhcfI4rBzcW5D0qtv6ULzc+Fc6jCfhbkgAlCnSfnUA0tnOEY 0Srw== X-Gm-Message-State: AHYfb5iDnpCk/EMq5N0RlmT62qyB6KpDPAZ4Mp4PUD5QKf0Aqj3f0wNR c11dKjYFXq/yEaHIiUA= X-Received: by 10.176.74.81 with SMTP id r17mr2866579uae.180.1503527361085; Wed, 23 Aug 2017 15:29:21 -0700 (PDT) Received: from mail-ua0-f182.google.com (mail-ua0-f182.google.com. [209.85.217.182]) by smtp.gmail.com with ESMTPSA id w22sm578300uah.39.2017.08.23.15.29.20 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Aug 2017 15:29:20 -0700 (PDT) Received: by mail-ua0-f182.google.com with SMTP id g11so5396072uah.0 for ; Wed, 23 Aug 2017 15:29:20 -0700 (PDT) X-Google-Smtp-Source: ADKCNb62YLOjb9/q0On7Hj1tbQKXY7H4BMvHK1TDWt9yJukowZoHOpaQRo3EmhBESzqwX5030MXMtJzoHfoOJ5/rPl4= X-Received: by 10.159.49.205 with SMTP id w13mr2896331uad.18.1503527359620; Wed, 23 Aug 2017 15:29:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.135.139 with HTTP; Wed, 23 Aug 2017 15:29:19 -0700 (PDT) In-Reply-To: <599D2E77.1000407@openfortress.nl> References: <599D158C.3070804@openfortress.nl> <599D2E77.1000407@openfortress.nl> From: Brandon Long Date: Wed, 23 Aug 2017 15:29:19 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Rick van Rein Cc: draft-ietf-dmarc-arc-protocol@ietf.org, "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a1146820a2f4d860557733e2b" Archived-At: Subject: Re: [dmarc-ietf] Readability and some technical remarks on draft-ietf-dmarc-arc-protocol-08 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, 23 Aug 2017 22:29:26 -0000 --001a1146820a2f4d860557733e2b Content-Type: text/plain; charset="UTF-8" We did discuss a diff based approach in the past, but ran into issues. Thread here: https://mailarchive.ietf.org/arch/msg/dmarc/_soxy-2IPCbXuV5aET9z4RFnG4o The problem happens when we try to enumerate all the ways in which messages can be modified during forwarding. I agree, that if all we cared about was the 99% mailing list case, then we're talking subject markers and footers, which would be pretty easy to handle. If we start getting into the final 1%, we're looking at things like stripping attachments, and including the attachment in a diff basically defeats the purpose of removing them. Or, some mailing list providers like Yahoo Groups allow the moderator to edit the message, including the diff there also defeats that (whether such features are a good idea or the result should actually authenticate as the original author is it's own debate, of course) If you go beyond mailing lists, you also run into more things like URL rewriting or S/MIME de-encapsulation which could also result in large diffs. There is an argument to be made that handling the 99% mailing list case simply and effectively would be a better choice, and maybe there are N solutions for the top M DMARC breaking issues, and even the complete set of M is a better choice. Brandon On Wed, Aug 23, 2017 at 12:27 AM, Rick van Rein wrote: > Hi, > > Enhancing my own remark with example text: > > > 11. > > As a design alternative, catering to those much-cheaper forwarding > > structures, has it been considered that a "diff" style header could be > > inserted much more easily? This would inform the recipient with > > information that could be presented in colour, for instance, seeing that > > the intention [of DMARC] is to protect that what is shown to the user. > > Since we're mostly talking of inserted "[listname] " in the Subject: > > header I wonder if ARC isn't a bit going over the top -- as well as > > limiting the ability to judge where things went wrong. At the same > > time, I do believe that the improved privacy of being able to drop > > information from the headers can be valuable (as long as someone takes > > responsibility over it). > > I worked out a ROUGH SKETCH of how a diff-based approach would look. It > could save a lot of work, both in the simplistic forwarders / lists and in > the validation nodes. I could work to get this more accurate if you think > it is a valuable approach. IMHO, it is simpler and that can be better for > some use cases. IMHO, it should not replace current ARC headers but could > be useful to augment it. > > Cheers, > -Rick > > > 5.4. ARC-Patch > > The ARC-Patch header indiciates changes that have been made to the > message while in transit. Headers are inserted at the top in the > order of occurrence, and can thus be unwound by going over the > headers in their order of appearance in the header list. > > An example application is the insertion of a list name in the Subject > header, with: > > ARC-Patch: Subject /^/[Katy] / > > This would transform a Subject header value "Something Like A Song" > to "[Katy] Something Like A Song", which is considered helpful by > list members, but which also breaks DKIM signatures. Changes to the > body are written as : for the entire email body, or :1 for the first > element in a multiple-entry MIME form, :1:2 for the second of the > first, and so on. > > Upon presenting content to email users, these differences are helpful > in colouring the text presented. At the same time, they can be used > to reverse the changes and return the text to values that can be > validated based on their original signature, whether made with DKIM > or ARC. > > I-D NOTE: Regular expressions can be kept as simple as possible to > make their reversal really simple. Examples of this include > mentioning the line number instead of just ranging over a body; > mentioning /KateBush/Katy/ instead of /(K[a-z]*)eBush/\1y/ and so on. > It is however possible to reverse even such a patch to a form by > swapping (...) and \N to derive /(K[a-z]*)y/\1eBush/ as a reversal of > the form. The trick of specifying this well will be to balance > simplicity in the most simplistic mail handling nodes against > efficient handling in the mail validation nodes. > > In general, multiple patterns may occur in each line, in the order in > which they are applied; upon reconstruction of the original text, the > order should be reversed. Furthermore, the reversal involves > matching the pattern of the outcome, which may lead to more matches > than desired; to accommodate for this, the matches in the output that > should be mapped may be specified in a list of numbers in [N,M,O] > form. Each pattern may be preceded with a line number to which it > applies. Patterns should not span multiple lines; they should then > be represented as multiple patterns, each modifying one line. > Provisions are made for inserting and removing lines. > > The ARC-Patch header may be released together with (TODO: before, > after, between?) a triple of cryptographic ARC headers, but it may > also be released independently. In general, a server passing a > message with modest modifications can use this mechanism to avoid the > overhead of cryptographic message handling. > > --001a1146820a2f4d860557733e2b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We did discuss a diff based approach in the past, but ran = into issues.

Thread here:=C2=A0https://mailarchive.ietf.org= /arch/msg/dmarc/_soxy-2IPCbXuV5aET9z4RFnG4o

The problem happens = when we try to enumerate all the ways in which messages can be modified dur= ing forwarding.

I agree, that if all we cared about was the 99% mai= ling list case, then we're talking subject markers and footers, which w= ould be pretty easy to handle.

If we start getting into the final 1%= , we're looking at things like stripping attachments, and including the= attachment in a diff basically defeats the purpose of removing them.=C2=A0= Or, some mailing list providers like Yahoo Groups allow the moderator to e= dit the message, including the diff there also defeats that (whether such f= eatures are a good idea or the result should actually authenticate as the o= riginal author is it's own debate, of course)

If you go b= eyond mailing lists, you also run into more things like URL rewriting or S/= MIME de-encapsulation which could also result in large diffs.
There is an argument to be made that handling the 99% mailing l= ist case simply and effectively would be a better choice, and maybe there a= re N solutions for the top M DMARC breaking issues, and even the complete s= et of M is a better choice.

Brandon

On Wed, Aug 23, 2017 at 12:27 A= M, Rick van Rein <rick@openfortress.nl> wrote:
Hi,

Enhancing my own remark with example text:

> 11.
> As a design alternative, catering to those much-cheaper forwarding
> structures, has it been considered that a "diff" style heade= r could be
> inserted much more easily? This would inform the recipient with
> information that could be presented in colour, for instance, seeing th= at
> the intention [of DMARC] is to protect that what is shown to the user.=
> Since we're mostly talking of inserted "[listname] " in = the Subject:
> header I wonder if ARC isn't a bit going over the top -- as well a= s
> limiting the ability to judge where things went wrong. At the same
> time, I do believe that the improved privacy of being able to drop
> information from the headers can be valuable (as long as someone takes=
> responsibility over it).

I worked out a ROUGH SKETCH of how a diff-based approach would look.= =C2=A0 It
could save a lot of work, both in the simplistic forwarders / lists and in<= br> the validation nodes.=C2=A0 I could work to get this more accurate if you t= hink
it is a valuable approach.=C2=A0 IMHO, it is simpler and that can be better= for
some use cases.=C2=A0 IMHO, it should not replace current ARC headers but c= ould
be useful to augment it.

Cheers,
=C2=A0-Rick


=C2=A0 =C2=A05.4.=C2=A0 ARC-Patch

=C2=A0 =C2=A0The ARC-Patch header indiciates changes that have been made to= the
=C2=A0 =C2=A0message while in transit.=C2=A0 Headers are inserted at the to= p in the
=C2=A0 =C2=A0order of occurrence, and can thus be unwound by going over the=
=C2=A0 =C2=A0headers in their order of appearance in the header list.

=C2=A0 =C2=A0An example application is the insertion of a list name in the = Subject
=C2=A0 =C2=A0header, with:

=C2=A0 =C2=A0ARC-Patch: Subject /^/[Katy] /

=C2=A0 =C2=A0This would transform a Subject header value "Something Li= ke A Song"
=C2=A0 =C2=A0to "[Katy] Something Like A Song", which is consider= ed helpful by
=C2=A0 =C2=A0list members, but which also breaks DKIM signatures.=C2=A0 Cha= nges to the
=C2=A0 =C2=A0body are written as : for the entire email body, or :1 for the= first
=C2=A0 =C2=A0element in a multiple-entry MIME form, :1:2 for the second of = the
=C2=A0 =C2=A0first, and so on.

=C2=A0 =C2=A0Upon presenting content to email users, these differences are = helpful
=C2=A0 =C2=A0in colouring the text presented.=C2=A0 At the same time, they = can be used
=C2=A0 =C2=A0to reverse the changes and return the text to values that can = be
=C2=A0 =C2=A0validated based on their original signature, whether made with= DKIM
=C2=A0 =C2=A0or ARC.

=C2=A0 =C2=A0I-D NOTE: Regular expressions can be kept as simple as possibl= e to
=C2=A0 =C2=A0make their reversal really simple.=C2=A0 Examples of this incl= ude
=C2=A0 =C2=A0mentioning the line number instead of just ranging over a body= ;
=C2=A0 =C2=A0mentioning /KateBush/Katy/ instead of /(K[a-z]*)eBush/\1y/ and= so on.
=C2=A0 =C2=A0It is however possible to reverse even such a patch to a form = by
=C2=A0 =C2=A0swapping (...) and \N to derive /(K[a-z]*)y/\1eBush/ as a reve= rsal of
=C2=A0 =C2=A0the form.=C2=A0 The trick of specifying this well will be to b= alance
=C2=A0 =C2=A0simplicity in the most simplistic mail handling nodes against<= br> =C2=A0 =C2=A0efficient handling in the mail validation nodes.

=C2=A0 =C2=A0In general, multiple patterns may occur in each line, in the o= rder in
=C2=A0 =C2=A0which they are applied; upon reconstruction of the original te= xt, the
=C2=A0 =C2=A0order should be reversed.=C2=A0 Furthermore, the reversal invo= lves
=C2=A0 =C2=A0matching the pattern of the outcome, which may lead to more ma= tches
=C2=A0 =C2=A0than desired; to accommodate for this, the matches in the outp= ut that
=C2=A0 =C2=A0should be mapped may be specified in a list of numbers in [N,M= ,O]
=C2=A0 =C2=A0form.=C2=A0 Each pattern may be preceded with a line number to= which it
=C2=A0 =C2=A0applies.=C2=A0 Patterns should not span multiple lines; they s= hould then
=C2=A0 =C2=A0be represented as multiple patterns, each modifying one line.<= br> =C2=A0 =C2=A0Provisions are made for inserting and removing lines.

=C2=A0 =C2=A0The ARC-Patch header may be released together with (TODO: befo= re,
=C2=A0 =C2=A0after, between?) a triple of cryptographic ARC headers, but it= may
=C2=A0 =C2=A0also be released independently.=C2=A0 In general, a server pas= sing a
=C2=A0 =C2=A0message with modest modifications can use this mechanism to av= oid the
=C2=A0 =C2=A0overhead of cryptographic message handling.


--001a1146820a2f4d860557733e2b-- From nobody Wed Aug 23 15:40:22 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8BD4132A51 for ; Wed, 23 Aug 2017 15:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fiction.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 P0EgM-ukMytc for ; Wed, 23 Aug 2017 15:40:20 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E487A132A4A for ; Wed, 23 Aug 2017 15:40:19 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id w17so5403804uaw.3 for ; Wed, 23 Aug 2017 15:40:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fiction.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6oF2sFV441aZH8zfUtxLo2OacM0vexjpCMXJq8yxTjI=; b=PGu1aqsSwnP66Ci7EGKm09fUqmgrA/023U/Og5eND/Z3dAIMgB8UKWuAfSAN6BT2xP eC85uMGoQNarRgPCy1dhFAiQ6LjXLJ/fzjAMoSNwfQ7oX9WXF5raWrIcagOrpvjdqxwH 4d5Bjis35zL4Gk/H1CxGr3RF2c5eq6p7aeVeI6UhPyaWZDfZ56JDBq2VIzX/Z0QdKhV3 SSZwEOgTy0Zlyp9iveFWnYGfqeI/Y0iOgphAX8V3ESI6ZRas11J6j2F0zo+e41Fs78kD GSwSrldF15CxXf7QpX4srRmEOEkkS9XtJlYNdr+s77WuTAbkiHJ3G/Dx6GtVpRgAxByE JlDw== 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=6oF2sFV441aZH8zfUtxLo2OacM0vexjpCMXJq8yxTjI=; b=pqdkjdpv11NAP46Tlk+r00ddcQuc8S7qAVPwtc6yHvz+Ez9WSiOsOh5Rtj+wsMzo4M FbAu03uhm1HsM0x5Q+M8Lu7Ah/WLPKbNHHpgInfrSFm1kwCUxquZpw5jbVkY10zQ/oHA Drv7nyYSt/krYbNP9IUGisACePtMuKimQZHssiEgD1Xu3HppoyKnt4+av6nw9Ohhsyfw 2PljqjOm4oJV06kO1GR9lBDq7IsjwBIM1zQvYuEFuItfiR4B1baI9tvfhYXkThk9/Zor W/mJOQPyWwzPQqH3i00o5GpdewS6I7HQJDiWIzdn/ek39aCHSYoEaP/jgwCNiepC7BfF rqFQ== X-Gm-Message-State: AHYfb5hqjYEvNG5N0ae/JUXIo5pzdQROc5IDQ1PvJiXh6pEBWeP5kswg rXjDNjT5kVREN4BdaQc= X-Received: by 10.159.33.232 with SMTP id 95mr3194420uac.1.1503528018863; Wed, 23 Aug 2017 15:40:18 -0700 (PDT) Received: from mail-vk0-f53.google.com (mail-vk0-f53.google.com. [209.85.213.53]) by smtp.gmail.com with ESMTPSA id t31sm586741uad.18.2017.08.23.15.40.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Aug 2017 15:40:18 -0700 (PDT) Received: by mail-vk0-f53.google.com with SMTP id z187so4999254vkd.3 for ; Wed, 23 Aug 2017 15:40:18 -0700 (PDT) X-Google-Smtp-Source: ADKCNb7WNLaQAM6cUamE+leCYvs2f+/IlU8qe2Z7AGvnEkZtE4lcbkcnpxTyrLsys9+g0VJTAGk4WB3pxuJC12Dhh24= X-Received: by 10.31.89.195 with SMTP id n186mr2714766vkb.5.1503528017729; Wed, 23 Aug 2017 15:40:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.135.139 with HTTP; Wed, 23 Aug 2017 15:40:17 -0700 (PDT) In-Reply-To: <599D158C.3070804@openfortress.nl> References: <599D158C.3070804@openfortress.nl> From: Brandon Long Date: Wed, 23 Aug 2017 15:40:17 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Rick van Rein Cc: draft-ietf-dmarc-arc-protocol@ietf.org, "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a114e1ff268a817055773657f" Archived-At: Subject: Re: [dmarc-ietf] Readability and some technical remarks on draft-ietf-dmarc-arc-protocol-08 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, 23 Aug 2017 22:40:21 -0000 --001a114e1ff268a817055773657f Content-Type: text/plain; charset="UTF-8" On Tue, Aug 22, 2017 at 10:41 PM, Rick van Rein wrote: > Hello, > > Thanks for the work on ARC! > > I would like to share a few remarks about > > > draft-ietf-dmarc-arc-protocol-08 > > that could improve its readability, and then there is one technical > remark. I apologise if things are due to reading it not intensely > enoughh, but that is only a sign that I find the draft difficult to read. > [snip] > > 11. > It is not clear to me how the market forces would work in getting all > those low-cost / low-effort email forwarding arrangements to implement > this (somewhat complex) technology. Just the fact that keys have to be > hunt in domains, presumably by users at the level of understanding of > forwarding, sounds like an irrational dream to me. What is the > intention of ARC in that respect? Is the intention to push such > situations out of the Internet [basically breaking email functionality] > or to use SPF (without DMARC's additional envelope.From==header.From > check) and/or to trace back Received headers on an incoming "real" mail > deal? What would then be the expectations of SPF on the forwarding mail > domain? These kinds of impact on the email landscape are incredibly > important, especially because ARC intends to resolve them -- by being > rather heavy-weight. > I really don't understand what you're saying here (hunt in domains?) For one, most forwarders, especially the low-cost / low-effort ones, don't modify mail when forwarding, so there is no DMARC issue. If they do modify mail, they're already hurting today. It's also true that the email ecosystem of today is more complicated, and although you can just send mail from anywhere, it's not clear that anyone will accept your mail without effort. The keys put in domains are already a requirement for DKIM, which, if not a requirement for sending, is a good step at getting your mail accepted anywhere. No one's trying to push anyone out of the Internet, but sometimes the bar for participation is raised. And no one's saying that ARC will be a requirement for anything. One could argue that ARC usage by the larger providers actually allows you to send mail with only SPF auth and not DKIM, since the SPF auth will be forwarded with ARC. Probably be a long time before that can be relied on. As for the rest of the paragraph about SPF and whatever... it sounds like you're proposing an alternative or something. As for the heavy-weight issue, managing a key is the same weight as it was for DKIM, which isn't to say that most people get it right (someone should make a lets encrypt style system for managing DKIM keys, it wouldn't be too hard to do). The rest is handled by the software, and frankly, although the software may be a bit tricky to get right, I wouldn't expect the low-cost / low-effort folks to be writing their own, they'll install something already written and use it. And that software is much less complicated than say the TLS software they are also hopefully using. Brandon --001a114e1ff268a817055773657f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Aug 22, 2017 at 10:41 PM, Rick van Rein <<= a href=3D"mailto:rick@openfortress.nl" target=3D"_blank">rick@openfortress.= nl> wrote:
Hello,

Thanks for the work on ARC!

I would like to share a few remarks about


=C2=A0 draft-ietf-dmarc-arc-protocol-08

that could improve its readability, and then there is one technical
remark.=C2=A0 I apologise if things are due to reading it not intensely
enoughh, but that is only a sign that I find the draft difficult to read.

[snip]
=C2=A0

11.
It is not clear to me how the market forces would work in getting all
those low-cost / low-effort email forwarding arrangements to implement
this (somewhat complex) technology.=C2=A0 Just the fact that keys have to b= e
hunt in domains, presumably by users at the level of understanding of
forwarding, sounds like an irrational dream to me.=C2=A0 What is the
intention of ARC in that respect?=C2=A0 Is the intention to push such
situations out of the Internet [basically breaking email functionality]
or to use SPF (without DMARC's additional envelope.From=3D=3Dheader.Fro= m
check) and/or to trace back Received headers on an incoming "real"= ; mail
deal?=C2=A0 What would then be the expectations of SPF on the forwarding ma= il
domain?=C2=A0 These kinds of impact on the email landscape are incredibly important, especially because ARC intends to resolve them -- by being
rather heavy-weight.

I really don't= understand what you're saying here (hunt in domains?)

For one, most forwarders, especially the low-cost / low-effort one= s, don't modify mail when forwarding, so there is no DMARC issue.
=

If they do modify mail, they're already hurting tod= ay.

It's also true that the email ecosystem of today is m= ore complicated, and although you can just send mail from anywhere, it'= s not clear that anyone will accept your mail without effort.
The keys put in domains are already a requirement for DKIM, whi= ch, if not a requirement for sending, is a good step at getting your mail a= ccepted anywhere.

No one's trying to push anyo= ne out of the Internet, but sometimes the bar for participation is raised.= =C2=A0 And no one's saying that ARC will be a requirement for anything.=

One could argue that ARC usage by the larger prov= iders actually allows you to send mail with only SPF auth and not DKIM, sin= ce the SPF auth will be forwarded with ARC.=C2=A0 Probably be a long time b= efore that can be relied on.

As for the rest of th= e paragraph about SPF and whatever... it sounds like you're proposing a= n alternative or something.

As for the heavy-weigh= t issue, managing a key is the same weight as it was for DKIM, which isn= 9;t to say that most people get it right (someone should make a lets encryp= t style system for managing DKIM keys, it wouldn't be too hard to do).= =C2=A0 The rest is handled by the software, and frankly, although the softw= are may be a bit tricky to get right, I wouldn't expect the low-cost / = low-effort folks to be writing their own, they'll install something alr= eady written and use it.=C2=A0 And that software is much less complicated t= han say the TLS software they are also hopefully using.

Brandon
--001a114e1ff268a817055773657f-- From nobody Wed Aug 23 15:49:27 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 699E9132A65 for ; Wed, 23 Aug 2017 15:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, 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=fiction.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 umtwBoyLNL6p for ; Wed, 23 Aug 2017 15:49:24 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85D3C132A62 for ; Wed, 23 Aug 2017 15:49:24 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id j189so5160557vka.0 for ; Wed, 23 Aug 2017 15:49:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fiction.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fNNpV0/7V6Jnp30YdG2U5psA8BAPt9RTycK8WSTalNc=; b=Kj9edoHdeIk3QqVjXr+DI1RZq6AbSE2XmFWaIUw1FVgtZOilW/WbatTX4KRq1xh0FB API4NK2xKcmLjzmDwesSMIFnaD4Gt7JBks36ZwAjTSToJZ1CvJdbX6yHKOR6Fsankus6 WHkOvrMf0IMMzT30jiWt5SI9O2TnsxXB1uiqahE2BCRe/FioE5niVHdgHEPbj9KFbgI7 ZBvqqCcNvHT4Ji51m3A3GVfE1MG811w5iHjRQQ0ySPLqNOnbyBNRqHH4UIrgBxzTr8ZR 97hrMBiz6GBWizwF33XuHJWgyvGWbKeMfRDISEuTFyAJD1QLB7+DrjskGW9u8mAUQn5L lAIQ== 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=fNNpV0/7V6Jnp30YdG2U5psA8BAPt9RTycK8WSTalNc=; b=Cqkj6WMsPaqGoRy1iusNVDIw6GpTvv0ps8FZncO+ul+kTKThaglXZ9Lp9Q4EOu/gk8 bW33gTvAKe0vWNmpnz/anbfMxDrtkAPVVXHzGOwMd2klZNEM1HFvi0redbetTo5jfLOw PoC/ujYjiUpaE4VG6tfiSDiB3/OXNzSwYGVzPQ+zWjOK7Crzm9Xb92P5U904/L1FF4hH c72qkda8l2fOUWo5NvxE7tbmB3R3rTdJDtUzXcz86O/qlaBZcPH/rZqFU63N18AC/MoF oEpbnTBXBZ6pXmgFHAFVBWb1ZNjXuz3mX0DOLEa1y9Rtuc/fX4PttM5XYFafNJmLE6xu coWw== X-Gm-Message-State: AHYfb5ixLMbfDDegtxOAGrxGnGL5+F2WZ+fWRKxSz/xITRiC2oFcZFvU KCGqQa6Mkc0ugigcf7E= X-Received: by 10.31.47.86 with SMTP id v83mr2884243vkv.138.1503528563372; Wed, 23 Aug 2017 15:49:23 -0700 (PDT) Received: from mail-ua0-f175.google.com (mail-ua0-f175.google.com. [209.85.217.175]) by smtp.gmail.com with ESMTPSA id q8sm569517vkd.45.2017.08.23.15.49.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Aug 2017 15:49:22 -0700 (PDT) Received: by mail-ua0-f175.google.com with SMTP id e28so5391957uah.4 for ; Wed, 23 Aug 2017 15:49:22 -0700 (PDT) X-Google-Smtp-Source: ADKCNb4IyNMAxxrau3fZ6wdSsKMrhdGhAtFgPYWEBIhmiCYytxc/+Y1KT2Dl24BKWtJ50J+rGch/kMubCALZ9XjCY/Y= X-Received: by 10.159.53.36 with SMTP id o33mr2929479uao.95.1503528562218; Wed, 23 Aug 2017 15:49:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.135.139 with HTTP; Wed, 23 Aug 2017 15:49:21 -0700 (PDT) In-Reply-To: <1503278734.2705712.1079502928.44F6A29D@webmail.messagingengine.com> References: <1503104028.2682226.1078138680.6C07899A@webmail.messagingengine.com> <599A1C70.7050200@isdg.net> <1503272850.655355.1079444872.679578A8@webmail.messagingengine.com> <599A237C.9030303@isdg.net> <1503278734.2705712.1079502928.44F6A29D@webmail.messagingengine.com> From: Brandon Long Date: Wed, 23 Aug 2017 15:49:21 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Bron Gondwana Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c03ce80dd809b05577385da" Archived-At: Subject: Re: [dmarc-ietf] About "non-rewindable crypto" 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, 23 Aug 2017 22:49:26 -0000 --94eb2c03ce80dd809b05577385da Content-Type: text/plain; charset="UTF-8" On Sun, Aug 20, 2017 at 6:25 PM, Bron Gondwana wrote: > > Right - so how exactly does that help, given that you've modified the > message since then? You could easily change the message-id at the same > time. If the original DKIM-Signature still passes then sure, you can't > modify anything. But then you don't need ARC anyway. > > If the DKIM signature allowed you to tell that some of the protected > headers were unchanged while allowing others to change, then it would mean > something - but the whole point of ARC is for when DKIM doesn't validate > any more, and if DKIM doesn't validate any more then the message-id can be > spoofed too. > > Do we think there's any utility to adding more message info to the AS, such as message-id? We originally tried to keep them very separate, but we could combine the AS with the concepts of the "weak DKIM" signature we talked about a while back. It equally doesn't prevent any individual attack, but perhaps there are other benefits in aggregate. I could also easily imagine some utility for having AMS include the z= DKIM tag, though this may get into the weeds of what can be used programmatically to determine spamminess/reuse vs expert user forensics after the fact. Brandon --94eb2c03ce80dd809b05577385da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Aug 20, 2017 at 6:25 PM, Bron Gondwana <brong@fastmailtea= m.com> wrote:
Right - so how exactly does that help, given that yo= u've modified the message since then?=C2=A0 You could easily change the= message-id at the same time.=C2=A0 If the original DKIM-Signature still pa= sses then sure, you can't modify anything.=C2=A0 But then you don't= need ARC anyway.

If the DKIM signature allowed you to tell = that some of the protected headers were unchanged while allowing others to = change, then it would mean something - but the whole point of ARC is for wh= en DKIM doesn't validate any more, and if DKIM doesn't validate any= more then the message-id can be spoofed too.

<= br>
Do we think there's any utility to adding more message in= fo to the AS, such as message-id?

We originally tried to keep= them very separate, but we could combine the AS with the concepts of the &= quot;weak DKIM" signature we talked about a while back.

=
It equally doesn't prevent any individual attack, but perhap= s there are other benefits in aggregate.

I could a= lso easily imagine some utility for having AMS include the z=3D DKIM tag, t= hough this may get into the weeds of what can be used programmatically to d= etermine spamminess/reuse vs expert user forensics after the fact.

Brandon=C2=A0
--94eb2c03ce80dd809b05577385da-- From nobody Wed Aug 23 23:12:32 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61CCB13203D; Wed, 23 Aug 2017 23:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePoPUw-iWhJJ; Wed, 23 Aug 2017 23:12:28 -0700 (PDT) Received: from lb3-smtp-cloud7.xs4all.net (lb3-smtp-cloud7.xs4all.net [194.109.24.31]) (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 45E3B12426E; Wed, 23 Aug 2017 23:12:27 -0700 (PDT) Received: from airhead.local ([IPv6:2001:980:93a5:1:84b6:e9c6:3f95:b821]) by smtp-cloud7.xs4all.net with ESMTPSA id klNMdZb1eAr7rklNOdb0Zl; Thu, 24 Aug 2017 08:12:25 +0200 Message-ID: <599E6E45.1000003@openfortress.nl> Date: Thu, 24 Aug 2017 08:12:21 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Brandon Long CC: draft-ietf-dmarc-arc-protocol@ietf.org, "dmarc@ietf.org" References: <599D158C.3070804@openfortress.nl> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfNHeovLtGSBmKQztKpAyiIC/umR2iCPVIPAV8TczVwm21Idygx6uXgeH5M6Rqki00PgieSD3xcKt2T4CX+AU/2o5xcEs5WgUpiPwYMwlpuvNUMwBmHbS wBc2c52qLzL7ybEPS9h+V1PwNyT0pChgOIkdVOlEQDRsVP0fovzxIxzb+9kp6JRiwqIhYYt9PpPXrT+QyYCLiqCHxkmbNkKeZsiji8ba0JPgidgJ+p5auyrt KXCiVunngOBqzu3OqcMzngqP9QuKpL9xKaBnVfYGUho3KqFpATkjScXo+FiyENsptZ9TtQT6rvyjQrcLMbwzEpsXBptegG7K8YJ+0jvGqiM= Archived-At: Subject: Re: [dmarc-ietf] Readability and some technical remarks on draft-ietf-dmarc-arc-protocol-08 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 06:12:31 -0000 Hi, > Brandon Long > 24 August 2017 at 00:40 > > > On Tue, Aug 22, 2017 at 10:41 PM, Rick van Rein > wrote: > > Hello, > > Thanks for the work on ARC! > > I would like to share a few remarks about > > > draft-ietf-dmarc-arc-protocol-08 > > that could improve its readability, and then there is one technical > remark. I apologise if things are due to reading it not intensely > enoughh, but that is only a sign that I find the draft difficult > to read. > > > [snip] > > > > 11. > It is not clear to me how the market forces would work in getting all > those low-cost / low-effort email forwarding arrangements to implement > this (somewhat complex) technology. Just the fact that keys have > to be > hunt in domains, presumably by users at the level of understanding of > forwarding, sounds like an irrational dream to me. What is the > intention of ARC in that respect? Is the intention to push such > situations out of the Internet [basically breaking email > functionality] > or to use SPF (without DMARC's additional envelope.From==header.From > check) and/or to trace back Received headers on an incoming "real" > mail > deal? What would then be the expectations of SPF on the > forwarding mail > domain? These kinds of impact on the email landscape are incredibly > important, especially because ARC intends to resolve them -- by being > rather heavy-weight. > > > I really don't understand what you're saying here (hunt in domains?) > Typo. "hung" in domains. > For one, most forwarders, especially the low-cost / low-effort ones, > don't modify mail when forwarding, so there is no DMARC issue. > I've seen at least one that touches the subject, and as a result they have serious problems. > If they do modify mail, they're already hurting today. > Yep. Which is not the same as saying that it's acceptable -- ARC is supposed to help overcome that kind of pain, after all. > It's also true that the email ecosystem of today is more complicated, > and although you can just send mail from anywhere, it's not clear that > anyone will accept your mail without effort. > > The keys put in domains are already a requirement for DKIM, which, if > not a requirement for sending, is a good step at getting your mail > accepted anywhere. > I'm not fighting with the ideas of using crypto. I'm only stating that there may be a much lighter-weight alternative that could increase the chances of getting the simpler forwarders on board. > No one's trying to push anyone out of the Internet, but sometimes the > bar for participation is raised. And no one's saying that ARC will be > a requirement for anything. > It would be sad to raise the bar without a need. Hence the alternative. In practice, ARC will be a requirement for reliable delivery. > One could argue that ARC usage by the larger providers actually allows > you to send mail with only SPF auth and not DKIM, since the SPF auth > will be forwarded with ARC. Probably be a long time before that can > be relied on. > "only SPF" -> "only SPF and a matching From in envelope and header" > As for the rest of the paragraph about SPF and whatever... it sounds > like you're proposing an alternative or something. > Yes, though I'm not sure if it would be added on the same nodes that also do ARC, or on intermediate nodes. > As for the heavy-weight issue, managing a key is the same weight as it > was for DKIM, which isn't to say that most people get it right > (someone should make a lets encrypt style system for managing DKIM > keys, it wouldn't be too hard to do). The rest is handled by the > software, and frankly, although the software may be a bit tricky to > get right, I wouldn't expect the low-cost / low-effort folks to be > writing their own, they'll install something already written and use > it. And that software is much less complicated than say the TLS > software they are also hopefully using. I agree with all that. It's just leaning on parties that hardly have a model of earning an income (forwarders, unlike the senders and recipients of email) that I find unwise. Which made me think of an alternative. -Rick From nobody Fri Aug 25 08:43:46 2017 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45781132C24 for ; Fri, 25 Aug 2017 08:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxJRloaXVdPT for ; Fri, 25 Aug 2017 08:43:43 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7C5F132974 for ; Fri, 25 Aug 2017 08:43:42 -0700 (PDT) Received: (qmail 49650 invoked from network); 25 Aug 2017 15:43:41 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 25 Aug 2017 15:43:41 -0000 Date: 25 Aug 2017 15:43:19 -0000 Message-ID: <20170825154319.27031.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org Cc: blong@fiction.net In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] About "non-rewindable crypto" 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, 25 Aug 2017 15:43:44 -0000 In article you write: >Do we think there's any utility to adding more message info to the AS, such >as message-id? Probably not. Mailing lists sometimes change the message ID, so it's not a very useful indication of evil. Having watched this thread, I don't see what the issue is. If a bad guy rewinds and resends a message, it'll arrive from the bad guy, not from wherever it was supposed to come from. I think we agree that ARC is only useful on messages that come from normally trustworthy sources, which the bad guy would not be. So what problem are we solving here? R's, John