Re: [ietf-dkim] versions of RFC822 mail messages, Where is the formal definition of DKIM-Signature?

"John Levine" <johnl@taugh.com> Sat, 10 February 2018 15:52 UTC

Return-Path: <ietf-dkim-bounces@mipassoc.org>
X-Original-To: ietfarch-ietf-dkim-archive@ietfa.amsl.com
Delivered-To: ietfarch-ietf-dkim-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF8A12DA07 for <ietfarch-ietf-dkim-archive@ietfa.amsl.com>; Sat, 10 Feb 2018 07:52:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.789
X-Spam-Level:
X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1536-bit key) reason="fail (message has been altered)" header.d=iecc.com header.b=dI8uacAt; dkim=fail (1536-bit key) reason="fail (message has been altered)" header.d=taugh.com header.b=EXJSd3hm
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 jvd1WZ2Qy4yj for <ietfarch-ietf-dkim-archive@ietfa.amsl.com>; Sat, 10 Feb 2018 07:52:05 -0800 (PST)
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 14711124205 for <ietf-dkim-archive@ietf.org>; Sat, 10 Feb 2018 07:52:04 -0800 (PST)
Received: from simon.songbird.com (simon.songbird.com [127.0.0.1]) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w1AFpCHk003856; Sat, 10 Feb 2018 07:51:13 -0800
Authentication-Results: simon.songbird.com; dkim=fail reason="verification failed; unprotected key" header.d=iecc.com header.i=@iecc.com header.b=dI8uacAt; dkim-adsp=none (unprotected policy); dkim-atps=neutral
Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w1AFp9sj003852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <ietf-dkim@mipassoc.org>; Sat, 10 Feb 2018 07:51:11 -0800
Received: (qmail 99137 invoked from network); 10 Feb 2018 15:50:10 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1833f.5a7f14b2.k1802; bh=GFF6lP7Hr4pmyhqnCjIMLcTocrIukc9ZMJ09s+J8Kbk=; b=dI8uacAth9ak5gFRX/1UBjbt2rw6q/tB/JMZZsHyu/MEYLeIFQMACMmen7PWIby9+1BzrkVB6AI9A54dBNZaMohng6/sra7ppodOfuqb15I696GzfDjSOBUbFuLpU2aK40EXM72vlDB2Zc2HZuzvSC4YtxvNh6P6eZZtiPJgiggNE8vNCy0ApvrDcYgo8Wap73K/ubQIz4DdB9RvkfbcZAOva7yPTU/JO1y6mCmpp7XsnzWKuIsZ9AmY0DHrJn90
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1833f.5a7f14b2.k1802; bh=GFF6lP7Hr4pmyhqnCjIMLcTocrIukc9ZMJ09s+J8Kbk=; b=EXJSd3hmKmDoYuIlvbOUDIbIhXruuKxb7T0l3TZvYgZ8tcRO3rUtYJiyahSED6IhPgb/lovoWkWyAJUCccJNKyyZR1tz+IrluIFWXXCUj5nDEjIxqZ1DUU3D7mZeKkIUqgCOKxMea8sb6qbvB7/qMDWHU1yor4bWy8yT/wdsZlBQvyh5jMBi5/FCOQE67FDU9EVTVdH+asGxFWBCzNcTHhLMTpRmvQLjaDErhsv8KzTdxrMs1TO/1hCPlVxwVsys
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 10 Feb 2018 15:50:10 -0000
Received: by ary.qy (Postfix, from userid 501) id 3735B1A7DD64; Sat, 10 Feb 2018 10:50:10 -0500 (EST)
Date: 10 Feb 2018 10:50:10 -0500
Message-Id: <20180210155011.3735B1A7DD64@ary.qy>
From: "John Levine" <johnl@taugh.com>
To: ietf-dkim@mipassoc.org
In-Reply-To: <20180210092127.33398.qmail@f3-external.bushwire.net>
Organization: Taughannock Networks
X-Headerized: yes
Mime-Version: 1.0
Subject: Re: [ietf-dkim] versions of RFC822 mail messages, Where is the formal definition of DKIM-Signature?
X-BeenThere: ietf-dkim@mipassoc.org
X-Mailman-Version: 2.1.16
Precedence: list
List-Id: IETF DKIM Discussion List <ietf-dkim.mipassoc.org>
List-Unsubscribe: <http://mipassoc.org/mailman/options/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=unsubscribe>
List-Archive: <http://mipassoc.org/pipermail/ietf-dkim/>
List-Post: <mailto:ietf-dkim@mipassoc.org>
List-Help: <mailto:ietf-dkim-request@mipassoc.org?subject=help>
List-Subscribe: <http://mipassoc.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Errors-To: ietf-dkim-bounces@mipassoc.org
Sender: "ietf-dkim" <ietf-dkim-bounces@mipassoc.org>

In article <20180210092127.33398.qmail@f3-external.bushwire.net> you write:
>In any event, 822 is an existence-proof that decades-long upgrades are entirely
>possible without the scorched-earth approach of versioning. ...

Nope, see the PS.  But anyway.

I don't understand this scorched earth stuff.  This is not IPv6, which
is often incompatible for the sake of being incompatible, and is
intended to make IPv4 go away sometime in the fourth millenium.

The idea with DKIM v=2 is that there are things that you cannot say in
a v=1 signature, no matter how many new tags you add, so you need some
way to tell verifiers what they need to understand.  How about this?

We rebrand the v= tag to be a feature list so the syntax is now roughly

  v= word (, word)*

where each word describes a semantic feature.  Feature tag "1" is all
the stuff in RFC6376.  My feature is mandatory to understand tags,
feature name "mandatory", so the signatures start

  DKIM-Signature: v=1,mandatory ...

R's,
John

PS: The reason you haven't noticed the versions in RFC822 is that we
put the version flags into SMTP.  An 8BITMIME or EAI mail message is
not backward compatible with RFC822.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html