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

Scott Kitterman <ietf-dkim@kitterman.com> Tue, 12 May 2020 18:58 UTC

Return-Path: <ietf-dkim@kitterman.com>
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 46A433A0885 for <ietf-dkim@ietfa.amsl.com>; Tue, 12 May 2020 11:58:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=znbFD/Kz; dkim=pass (2048-bit key) header.d=kitterman.com header.b=c+VaNkPn
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 d5n0mS7YIxlI for <ietf-dkim@ietfa.amsl.com>; Tue, 12 May 2020 11:58:08 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A9C03A0837 for <ietf-dkim@ietf.org>; Tue, 12 May 2020 11:58:08 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) by interserver.kitterman.com (Postfix) with ESMTPS id 4CA23F80276 for <ietf-dkim@ietf.org>; Tue, 12 May 2020 14:58:07 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1589309887; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=aAeRjJH/buoB6TLbBdRqibPbIEeQTSdsHpveG/A4FSc=; b=znbFD/Kzhwlg/8rw8pM3+RDIHM9SVce5IURlsMW9QMeBTS3blsSeiiqubqUK9Cagf+sKj No7QUxeOQVWvjVHCA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1589309887; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=aAeRjJH/buoB6TLbBdRqibPbIEeQTSdsHpveG/A4FSc=; b=c+VaNkPn4b6KJkEQlRfWJosvG6YYrPkyl7ibhbj/Lj8if3gcLPpKWdvIA3N1lE0iEBine ik1AfyBJFQXxanUfje4ZeY98ClmrWatKYM5Im9DSuRf1jV6rbW7zYj2Q7odsdGyNk3OJMYJ aVUEgUMfEFHggwOUXCRl1XwghnWxMGG03oPMyhPybN7C8NskZqn+QrfLkbV+gADdy50vd3x iMiEurCDwFYaEiAVbc59vv3MXiMgEQf9gaAQt7p7043DWuEoYBt1Ios3mh+6UMJAE8tYdgF +XXFTikuxAO/sIIEI+FWEQola9qZjy8snPnEOq4BkdNtGQ0sAoT2CD0pnngQ==
Received: from sk-desktop.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTP id 0D873F801F8 for <ietf-dkim@ietf.org>; Tue, 12 May 2020 14:58:07 -0400 (EDT)
From: Scott Kitterman <ietf-dkim@kitterman.com>
To: ietf-dkim@ietf.org
Date: Tue, 12 May 2020 14:58:06 -0400
Message-ID: <1600513.6Fcf0uKhHM@sk-desktop>
In-Reply-To: <CAL0qLwYY4PCFwe8=WTBMJLU3=OBnRfB4TUpRma_WXppnueBQKA@mail.gmail.com>
References: <80533fb3-75a2-1d60-801d-c54d735d4094@tana.it> <c975c01e-c3a5-a0d6-dba6-f4a1c245ab56@tana.it> <CAL0qLwYY4PCFwe8=WTBMJLU3=OBnRfB4TUpRma_WXppnueBQKA@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-dkim/spgjs3CkWwrN1bfQy_3V6bvvTLE>
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: Tue, 12 May 2020 18:58:10 -0000

On Tuesday, May 12, 2020 1:09:55 PM EDT Murray S. Kucherawy wrote:
> On Tue, May 12, 2020 at 9:30 AM Alessandro Vesely <vesely@tana.it> wrote:
> > On Tue 12/May/2020 17:48:38 +0200 Murray S. Kucherawy wrote:
> > > On Tue, May 12, 2020 at 1:20 AM Alessandro Vesely <vesely@tana.it>
> > 
> > wrote:
> > >> On Mon 11/May/2020 20:23:12 +0200 Murray S. Kucherawy wrote:
> > >>> Indeed; why would I believe what any given domain claims in this tag?
> > >> 
> > >> If you trust the domain, you can as well trust their tagging.
> > > 
> > > If you trust the domain, you don't need their tagging.
> > 
> > Why not?  I may trust gmail, say.  Yet, in order to learn what
> > restrictions
> > they apply to the From: I have to create an account and try.  There is no
> > standard location where they declare their policy in a machine-readable
> > manner,
> > and policies written in legalese are even less readable...
> 
> What would you do with that information if you had it?
> 
> Maybe you're using a different definition of "trust" than I am.  To me, "I
> trust gmail.com" means "I believe mail signed by gmail.com is legitimate",
> irrespective of how they might handle their mail.
> 
> Put another way: I believe I would only reach the opinion that I "trust"
> mail from a domain when I already know the thing(s) your tag(s) would tell
> me.

The implication is that such tags won't affect a deliver/don't deliver decision 
(which I think is correct - the moment it does, all my mail will be marked 
super duper urgent first class the user really wants this I swear).  

To the extent such information is useful for downstream processing (and I 
don't really know that it is, but if it is), there's no compelling need to 
complicate DKIM with this.  As Dave suggested, this could be a new header 
field.  It could be covered by a DKIM signature with the same security 
properties as if it were a part of DKIM without imposing additional complexity 
on DKIM.

Scott K