Re: [ietf-822] DKIM differs from "--" first in lines to indicate start of signature

Jim Fenton <fenton@bluepopcorn.net> Tue, 05 January 2016 16:57 UTC

Return-Path: <fenton@bluepopcorn.net>
X-Original-To: ietf-822@ietfa.amsl.com
Delivered-To: ietf-822@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5671A916A for <ietf-822@ietfa.amsl.com>; Tue, 5 Jan 2016 08:57:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 zIQLy2casIZP for <ietf-822@ietfa.amsl.com>; Tue, 5 Jan 2016 08:57:10 -0800 (PST)
Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 466F81A8853 for <ietf-822@ietf.org>; Tue, 5 Jan 2016 08:57:10 -0800 (PST)
Received: from [IPv6:2001:470:1f05:bfe::3] ([IPv6:2001:470:1f05:bfe::3]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id u05Gv7E2021917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for <ietf-822@ietf.org>; Tue, 5 Jan 2016 08:57:09 -0800
To: ietf-822@ietf.org
References: <D6D98A12-74D5-45CB-86AD-3BDE6A931CFF@dsv.su.se> <87vb7bwv7n.fsf@hope.eyrie.org> <CAL0qLwYRTvLFwEZPNFbaNybGwj+e_g33kZQkFeLN4YTsZ=KSZg@mail.gmail.com> <8737ufwo02.fsf@hope.eyrie.org> <568AC6A9.6080208@isdg.net> <87bn91m7wr.fsf@hope.eyrie.org> <568BC536.1050501@tana.it>
From: Jim Fenton <fenton@bluepopcorn.net>
X-Enigmail-Draft-Status: N1110
Message-ID: <568BF5E3.9030302@bluepopcorn.net>
Date: Tue, 05 Jan 2016 08:57:07 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <568BC536.1050501@tana.it>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1452013029; bh=M4PEG2qDZsxPkH7f0Np/2sYOjQiGv+wcElX+pN1kzQA=; h=Subject:To:References:From:Date:In-Reply-To; b=BEPafLgHeu/d7l/n0XzNU2773aGFPicJOS0zar3y8XzUuwlgjysegOldrJMV3DK9r YhvxKJNe0FnoRuWf/xhG6MzN6JL/HJOKlGR/f9LuCttlWYCpRfcHZN5PUVeerg8VkK KMpEnIxlVfiu74L/V0nSX0tqwiC1wsKY37Umk3Es=
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf-822/4DVcgBBIaC6dzWNUjj7FX9pTJBA>
Subject: Re: [ietf-822] DKIM differs from "--" first in lines to indicate start of signature
X-BeenThere: ietf-822@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion of issues related to Internet Message Format \[RFC 822, RFC 2822, RFC 5322\]" <ietf-822.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-822>, <mailto:ietf-822-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-822/>
List-Post: <mailto:ietf-822@ietf.org>
List-Help: <mailto:ietf-822-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-822>, <mailto:ietf-822-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Jan 2016 16:57:11 -0000

On 01/05/2016 05:29 AM, Alessandro Vesely wrote:
>
> DKIM differs in that its signatures live in the header --with the obvious
> disadvantage of requiring two passes.  Drafts which inspired DKIM, [DK] and
> [IIM], provide for storing signatures in the header too.
>
> Out of curiosity, does anyone recall how this design decision came?

DKIM, DK, and IIM signatures are all intended to be applied and verified
by the infrastructure, not by end users. If the signatures were added to
the body, many users would call their email providers and ask, "What's
this junk in my message?" The cost of fielding those calls alone would
be a significant barrier to deployment. Putting the signatures in the
header makes them invisible to end users who don't ask to see the
header, so it provides the right answer to the visibility problem.

The signatures are of a constrained size, so why not just store a copy
of the signature header field and do the verification at the end of the
message receipt rather than make another pass for verification? I agree,
though, that adding an Authentication-Results or similar header field
would require another pass.

-Jim