Re: [dmarc-ietf] third party authorization, not, was non-mailing list

Dave Crocker <dhc@dcrocker.net> Sun, 16 August 2020 15:47 UTC

Return-Path: <dhc@dcrocker.net>
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 36F493A0D29 for <dmarc@ietfa.amsl.com>; Sun, 16 Aug 2020 08:47:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.848
X-Spam-Level:
X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, 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 RRj27Z4L4EqO for <dmarc@ietfa.amsl.com>; Sun, 16 Aug 2020 08:47:33 -0700 (PDT)
Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 063C03A0D25 for <dmarc@ietf.org>; Sun, 16 Aug 2020 08:47:32 -0700 (PDT)
Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 07GFoH04013071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 16 Aug 2020 08:50:18 -0700
To: Dotzero <dotzero@gmail.com>, Alessandro Vesely <vesely@tana.it>
Cc: IETF DMARC WG <dmarc@ietf.org>
References: <20200810172411.A13681E7CD8B@ary.local> <10d4cb3b-baf5-0bfc-6160-70db96b9f0d1@tana.it> <CAJ4XoYefzLaV_tbvPTE9YaqBwtY93=n2v8KwWxL5i9GGxKW90Q@mail.gmail.com>
From: Dave Crocker <dhc@dcrocker.net>
Reply-To: dcrocker@bbiw.net
Organization: Brandenburg InternetWorking
Message-ID: <6abec496-479f-a9e0-1f66-786af53c161c@dcrocker.net>
Date: Sun, 16 Aug 2020 08:47:25 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0
MIME-Version: 1.0
In-Reply-To: <CAJ4XoYefzLaV_tbvPTE9YaqBwtY93=n2v8KwWxL5i9GGxKW90Q@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------3F7E4BD89A6A1670FC025C78"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/UXOQQ5IgnbPhCNtQAa4f4oksJk0>
Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 16 Aug 2020 15:47:34 -0000

On 8/14/2020 7:12 AM, Dotzero wrote:
>       At that time there were also folks pushing for PGP, GPG, 
> Personal Certificate and  S/MIME as  paths forward.

There was, by then, a long history of these failing to scale.


> Even with that, it took a while for industry efforts to gain some 
> sense of clarity. Notice that the general path forward was basically 
> domain based and not individual user/client based.

SPF and DomainKey were informal, spontaneous, private efforts. They 
established their viability long before reaching a standards venue.  So 
there was no 'policy' 'decision' to make this approach.


> There was a debate within the DKIM effort regarding i= vs d= to the 
> extent that at one industry event people were walking around with 
> little stickers on their badges to indicate which they supported. I 
> believe that was courtesy of Dave Crocker.

This was a follow-on issue after DKIM was initially published. We 
realized that the spec said that DKIM's goal was to provide an 
identifier, but then it didn't specify which one to use, the one in the 
i= parameter or the one in the d=.  (Note that neither of these was 
requirement to correlate with any other identifier in the message.

The IETF working group debate about this was intense and was not 
converging on a choice. One of the early arrivals to the meeting walked 
through the hotel's entrance, saw me, and said "d= or i=?" and I 
realized we could have some fun both promoting the issue at this 
industry trade event, and possibly get some constructive discussion.  
The meeting staff were helpful in provide sticky dots to use.


d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net