Re: [ietf-822] A permission to re-sign header

Miles Fidelman <mfidelman@meetinghouse.net> Sun, 20 April 2014 00:00 UTC

Return-Path: <mfidelman@meetinghouse.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 B4F351A008F for <ietf-822@ietfa.amsl.com>; Sat, 19 Apr 2014 17:00:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.281
X-Spam-Level:
X-Spam-Status: No, score=-0.281 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, MISSING_HEADERS=1.021, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 uoOjE0RRoQAr for <ietf-822@ietfa.amsl.com>; Sat, 19 Apr 2014 17:00:20 -0700 (PDT)
Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id 412AD1A0104 for <ietf-822@ietf.org>; Sat, 19 Apr 2014 17:00:20 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id 28E11CC08B for <ietf-822@ietf.org>; Sat, 19 Apr 2014 20:00:15 -0400 (EDT)
X-Virus-Scanned: by amavisd-new-2.6.2 (20081215) (Debian) at neighborhoods.net
Received: from server1.neighborhoods.net ([127.0.0.1]) by localhost (server1.neighborhoods.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id LoWpCEzHgAfA for <ietf-822@ietf.org>; Sat, 19 Apr 2014 20:00:06 -0400 (EDT)
Received: from new-host.home (pool-173-76-155-14.bstnma.fios.verizon.net [173.76.155.14]) by server1.neighborhoods.net (Postfix) with ESMTPSA id 0D15ECC089 for <ietf-822@ietf.org>; Sat, 19 Apr 2014 20:00:06 -0400 (EDT)
Message-ID: <53530E05.1010006@meetinghouse.net>
Date: Sat, 19 Apr 2014 20:00:05 -0400
From: Miles Fidelman <mfidelman@meetinghouse.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:28.0) Gecko/20100101 Firefox/28.0 SeaMonkey/2.25
MIME-Version: 1.0
CC: ietf-822@ietf.org
References: <20140418021925.2979.qmail@joyce.lan> <53516FA7.3020507@qti.qualcomm.com> <alpine.BSF.2.00.1404181500430.5575@joyce.lan> <6411.1397912723@sandelman.ca> <20140419155241.GD31552@thunk.org> <5352FF75.3020605@qti.qualcomm.com>
In-Reply-To: <5352FF75.3020605@qti.qualcomm.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf-822/mXCrJKkyRmECVoaa0yTat5Z0jV8
Subject: Re: [ietf-822] A permission to re-sign header
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: <http://www.ietf.org/mail-archive/web/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: Sun, 20 Apr 2014 00:00:24 -0000

Pete Resnick wrote:
> On 4/19/14 10:52 AM, Theodore Ts'o wrote:
>
>> There are mailing lists that want to "fix" broken messages, yes, but
>> if we need to provide end-to-end assurance that the message really
>> came from the originator...
>
> Providing end-to-end assurance that the message really came from the 
> originator is not the stated goal. It would be nice if we could do 
> that, but so far there are operational and deployment problems with 
> accomplishing that. I've got ideas about how we might improve that 
> situation, but they will take much longer to deploy than the things we 
> are talking about here.
>
Is that not a critical goal?  As a sender, I want to make sure that my 
message gets through intact (authentication and integrity).  As a 
recipient, I want to know who authored the message (authentication) and 
that I got what the author sent (integrity).

It strikes me that it's a secondary consideration as to whether the 
author intended to send the message to me - i.e., these cases seem 
important, but secondary:
- someone uses the list as a vector to send unwanted traffic (e.g., 
spam) - that seems to be an issue for authentication of the author, to 
the list server
- the list server sends stuff to me, even if I'm not on it (that's 
simply unsolicited email)
- a malicious actor masquerades as a list server that I'm on - that's 
about the list server authenticating itself to recipients

Ultimately, a sender cares about "protecting their name" (e.g., avoiding 
phishing attacks), and protecting the integrity of what they send.  A 
recipient wants to have some assurance that what they're reading came 
from the avowed sender, and that what you're reading is what they sent.

What that suggests to me is that:

1. The original sending system has to attach some strong cryptography to 
provide both authentication, and integrity.

2. Any intermediate system that munges pieces of the message (changing 
the From address, adding subject tags, adding message headers and 
footers) - has to ALSO add enough information that a recipient can 
recreate the original message, exactly, and validate the original 
signature.  E.g.,
- if a mailing list changes the From: address, it has to put the 
original From: address in a Original-From: header
- if a mailing list adds tags to the subject line, it has to put the 
original Subject: into an Original-Subject header
- if a mailing list adds 5 lines of header and 5 lines of footer to the 
text body, then it needs to add a header indicating as much
- with that information, software at the receiving end can recreate the 
original message, and check its authentication and integrity, and 
mistrust all of the modifications the mailing list added
- the mailing list software can additionally add signatures to 
authenticate itself and provide integrity for the things its changed/added
- of course things get a bit more complicated if MIME, or S/MIME, or 
PGP-enhanced mail, or digests, etc. are added to the mix
- and, of course, this has to be done in a standard way - otherwise 
nobody will be able to write code

Miles Fidelman





-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra