Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily

Dave Crocker <dcrocker@gmail.com> Wed, 15 August 2018 13:33 UTC

Return-Path: <dcrocker@gmail.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15EC3130F73 for <dmarc@ietfa.amsl.com>; Wed, 15 Aug 2018 06:33:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Do1ADX_W2QIs for <dmarc@ietfa.amsl.com>; Wed, 15 Aug 2018 06:33:50 -0700 (PDT)
Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60CA7130F4A for <dmarc@ietf.org>; Wed, 15 Aug 2018 06:33:50 -0700 (PDT)
Received: by mail-pf1-x42f.google.com with SMTP id j26-v6so513195pfi.10 for <dmarc@ietf.org>; Wed, 15 Aug 2018 06:33:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=SkILELobu088wFV+CZujaetNU2ysB6+NeMoLKqsRHXk=; b=CxzSWLsdyBKGPKBnb0BVuZwCGjQcPfA8R2OLALVRE/mZBavlOfFdGxdZ0UlyDmpQdv K1dlxOIBaFmGhdweZX/HZJD5wg59/5m3GHixdxbJl08zeRGjC+kaIIN69RCJCwEmwAXc XakgvQGd2dUrAYVq/LQd4ICDjgwojGSpaqxaZL1/xcqm/Mo3e4UKQLWaql99T6khNpFV RHTnmtHRcSQeNzQE4BJwiZLcmlAu1L/7yYO5ynehX11SAEgCGMekdFviNcPQsMFXnyrT CyXakTKT9TxKJk6j4+J30ahBdvrMJAUQhzzl1M98iyCbaTAYdZZ9u5az4P4nH2FVxPtj 3x9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=SkILELobu088wFV+CZujaetNU2ysB6+NeMoLKqsRHXk=; b=fxfx0WMu3TxRPGPyqY10J8DMMRQZreR67idpoE9NhD81eKf4eGj1N1RQwmrgA2ufHi BaDOhE+y0B276KcrefrymOsvyV0IQdQNGh3tXcTBz/NTLpQnWvkyJTMxGePeERRCXvkv Ra3LyUR8Zmr9LiQp+51lE8XSHkXlAQVdIYZk/RjNHgyw5lwP4y23BHIlyi5jSVS41w1o mzS0B1T7VteOCrXZfBx65sE+n1Xtz92zbuW786jQL3X+NRzirn2TuHbAb6zKQSENuCFd MO0Pu9xP08Dn0PqKk0lpz3agtn07Ah6nTUzlIep2rktB2J2kYxtBIMyw2YNONPQ5eCw9 Avew==
X-Gm-Message-State: AOUpUlG3HBYrp8bmx6PYefcBF/04ACCsLnn4SzBKj/e7e3rXUBbpNvvb 3J8H4Zjioqs6AxlaN4WeBGA=
X-Google-Smtp-Source: AA+uWPzSHpL/+pyAdhVGTIHIDp1MXTd4+6vwz422diCeSMmVAMUsHhi6AixvtXtzxLyHanr6mVP1aw==
X-Received: by 2002:a62:858c:: with SMTP id m12-v6mr27981214pfk.173.1534340029822; Wed, 15 Aug 2018 06:33:49 -0700 (PDT)
Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net. [76.218.8.128]) by smtp.gmail.com with ESMTPSA id q81-v6sm37046842pfd.15.2018.08.15.06.33.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Aug 2018 06:33:48 -0700 (PDT)
To: "Kurt Andersen (b)" <kboth@drkurt.com>
Cc: "Murray S. Kucherawy" <superuser@gmail.com>, IETF DMARC WG <dmarc@ietf.org>, Brandon Long <blong=40google.com@dmarc.ietf.org>, Seth Blank <seth@sethblank.com>
References: <CAD2i3WNSe+of7U8fdTnmUeU3sthUbpEVgdYHT9J6BgLxoeOL3w@mail.gmail.com> <20180730221726.713CE200316625@ary.qy> <CAD2i3WMvCugRm4KZeLx3PFb6f_pKR3rs4mnH2FZO4_X7ZA7GHA@mail.gmail.com> <alpine.OSX.2.21.1807302025420.60501@ary.qy> <CABa8R6sWSu9Q+mozxzaVGab3PE2zxqVmt4L6FERSLC1oDTh1oA@mail.gmail.com> <alpine.OSX.2.21.1808031352460.29088@ary.qy> <CABa8R6u_09D9BNiq3fXDXjPVfFeZxHtRa0NyLamKyj033xO72A@mail.gmail.com> <CAD2i3WNJdQ95drzue17UdKEb_6qkN7DuB7WdMbORTSjWGgwJZA@mail.gmail.com> <CABa8R6sgtcAHGt10GQ85PvhYvEZfv1K1SqiFLe7ozWeZ5+Y30A@mail.gmail.com> <CABuGu1rmxMWhUQvzf=uyNVYSb1zGCgWtiak5+yPKaXGWPV4XUg@mail.gmail.com> <CAL0qLwbjpMH30hD8xKnAgT6kJ9wmN9hm3gwnRGmiqTOxKLiHDw@mail.gmail.com> <a6eb3ab9-0e0f-f3e5-9dd0-8d9e992595a0@gmail.com> <CABuGu1oVG-=5TtfdQffENQkf5+vQ9Fp44L42nsGY1QgUjzYyHA@mail.gmail.com>
From: Dave Crocker <dcrocker@gmail.com>
Message-ID: <799c2b18-97fe-6e22-f2cf-49245ae9c65e@gmail.com>
Date: Wed, 15 Aug 2018 06:33:46 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <CABuGu1oVG-=5TtfdQffENQkf5+vQ9Fp44L42nsGY1QgUjzYyHA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/T-xzi6WzlzicrgUb0W9eF2Bx7L0>
Subject: Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Aug 2018 13:33:52 -0000

On 8/14/2018 10:28 PM, Kurt Andersen (b) wrote:
> The only reason to affix a seal with "cv=fail" on the end of an ARC 
> chain is to spare all subsequent handlers from having to venture past 
> step 2 in the validation process. Without that, every intermediary and 
> the final receiver (at least those which validate ARC) will have to 
> repeat the entire sequence of validation up to whatever point in the 
> process a failure is determined. 


So the extra mechanism is intended an efficiency hack.

1. The processing being saved is merely normal processing that they'd be 
expected to do for a valid message.

2. I hope we are assuming that failure is not a typical condition

3. In order to save some occasional processing in some cases, we are 
adding mechanism to all implementations everywhere.

This doesn't sound like compelling benefit, which is why I suggest 
removing it.  Absent compelling benefit, simpler specifications is to be 
preferred, IMO.


d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net