Re: [Ietf-dkim] Adding an aim= tag to DKIM Signature Tag Specifications

Dave Crocker <dhc@dcrocker.net> Mon, 11 May 2020 22:08 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: ietf-dkim@ietfa.amsl.com
Delivered-To: ietf-dkim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2663A0D52 for <ietf-dkim@ietfa.amsl.com>; Mon, 11 May 2020 15:08:34 -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 YKqsvuZGFBL6 for <ietf-dkim@ietfa.amsl.com>; Mon, 11 May 2020 15:08:31 -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 1D1273A0D51 for <ietf-dkim@ietf.org>; Mon, 11 May 2020 15:08:30 -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 04BMAIiZ031608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 11 May 2020 15:10:18 -0700
Reply-To: dcrocker@bbiw.net
To: Jim Fenton <fenton@bluepopcorn.net>, ietf-dkim@ietf.org
References: <80533fb3-75a2-1d60-801d-c54d735d4094@tana.it> <7ac84ebf-e30b-6288-81c2-4a6631471d74@dcrocker.net> <5d9709d4-fd1e-9275-6a36-dfc6e7fca97b@bluepopcorn.net>
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
Message-ID: <486245c5-d261-c6df-560b-f022c1ebabd5@dcrocker.net>
Date: Mon, 11 May 2020 15:08:15 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <5d9709d4-fd1e-9275-6a36-dfc6e7fca97b@bluepopcorn.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-dkim/A90gPPgCFXGZjXyiBmUZD7FkX0k>
Subject: Re: [Ietf-dkim] Adding an aim= tag to DKIM Signature Tag Specifications
X-BeenThere: ietf-dkim@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DKIM List <ietf-dkim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-dkim>, <mailto:ietf-dkim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-dkim/>
List-Post: <mailto:ietf-dkim@ietf.org>
List-Help: <mailto:ietf-dkim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 May 2020 22:08:34 -0000

On 5/11/2020 11:23 AM, Murray S. Kucherawy wrote:
> Indeed; why would I believe what any given domain claims in this
> tag?
> 
> If the response to that is that you will trust only what certain
> domains say here, then you probably already know the equivalent of
> what's in the tag anyway.

Establishing a clear community desire for this and for how it is 
expected to be used seems an important hurdle to get over, with the 
question you raise nicely establishing the need (for the need...)



On 5/11/2020 1:33 PM, Jim Fenton wrote:
> On 5/11/20 10:30 AM, Dave Crocker wrote:
>> On 5/11/2020 10:21 AM, Alessandro Vesely wrote:
>>> The question is, what responsibility is being claimed?
>> ....
>>> Tagging keys with aim= would allow senders to choose an appropriate
>>> selector
>>> under different circumstances.
>>
>> If signers want to have a standardized means of indicating the
>> fine-grained semantics behind their signature, they can do that
>> without modifying DKIM.
>>
>> Rather, define and use a header field that specifies DKIM signing
>> policy.  Cover it with the DKIM signature, of course.
> 
> If this is expressing semantics for the DKIM signature, it's also likely
> that there are going to be multiple DKIM signatures on the message with
> different semantics. There might then be multiple instances of the
> header field, and it would be difficult to associate each signature with
> the appropriate semantics header field, except in the specific case
> where there is only one specific semantics header field and all
> signatures use either that or the default.

Tie it do the DKIM d= or d= + selector.


> There might also be the situation where a domain wants to delegate a key

Hence my suggestion that figuring out such details is where discussion 
could get interesting, if only because people will raise all sorts of 
combinatorial theories, independent of demonstrated need, and this is a 
space with lots of combinatorials...


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net