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

Paul Smith <paul@pscs.co.uk> Tue, 22 April 2014 10:38 UTC

Return-Path: <paul@pscs.co.uk>
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 7F2661A036F for <ietf-822@ietfa.amsl.com>; Tue, 22 Apr 2014 03:38:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.974
X-Spam-Level:
X-Spam-Status: No, score=-0.974 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] 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 zufVvgtANKBB for <ietf-822@ietfa.amsl.com>; Tue, 22 Apr 2014 03:38:51 -0700 (PDT)
Received: from mail.pscs.co.uk (mail.pscs.co.uk [188.65.177.237]) by ietfa.amsl.com (Postfix) with ESMTP id 68A4C1A0372 for <ietf-822@ietf.org>; Tue, 22 Apr 2014 03:38:50 -0700 (PDT)
Authentication-Results: mail.pscs.co.uk; spf=none; auth=pass (cram-md5) smtp.auth=paul
Received: from lmail.pscs.co.uk ([82.68.5.206]) by mail.pscs.co.uk ([188.65.177.237] running VPOP3) with ESMTP for <ietf-822@ietf.org>; Tue, 22 Apr 2014 11:39:57 +0100
Authentication-Results: lmail.pscs.co.uk; spf=none; auth=pass (cram-md5) smtp.auth=paul
Received: from [192.168.66.101] ([192.168.66.101]) by lmail.pscs.co.uk ([192.168.66.70] running VPOP3) with ESMTP for <ietf-822@ietf.org>; Tue, 22 Apr 2014 11:38:35 +0100
Message-ID: <535646AA.2080400@pscs.co.uk>
Date: Tue, 22 Apr 2014 11:38:34 +0100
From: Paul Smith <paul@pscs.co.uk>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: 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> <01P6X5AW821O000052@mauve.mrochek.com> <5356414B.70101@tana.it>
In-Reply-To: <5356414B.70101@tana.it>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Authenticated-Sender: paul
X-Server: VPOP3 Enterprise V6.7 - Registered
X-Organisation: Paul Smith Computer Services
X-Authenticated-Sender: paul
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf-822/Jh5RGfo1apBdozKIVHf0nzPSr_k
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: Tue, 22 Apr 2014 10:38:56 -0000

On 22/04/2014 11:15, Alessandro Vesely wrote:
> On Tue 22/Apr/2014 04:58:21 +0200 Ned Freed wrote:
>>> On Sat, Apr 19, 2014 at 09:05:23AM -0400, Michael Richardson 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, disallowing this behavior so that things
>>> like S/MIME and PGP signatures don't get broken might be an
>>> engineering tradeoff that we might have to make.
>> That's possible, but then you run into other problems. Take the issue
>> of adding a disclaimer. You can certainly do this without damaging
>> the S/MIME signature by converting a MIME structure of:
>>
>>     multipart/signed
>>       text/html
>>       application/signature-whatever
>>
>> to:
>>
>>     multipart/mixed
>>       multipart/signed
>>         text/html
>>         application/signature-whatever
>>       text/plain - disclaimer
>>
>> But then you have to take into account how this gets displayed, and what
>> it means when it is displayed.
> That alters the content-type and the very beginning of the message body.
> The result may be more difficult to display/interpret than a signed
> attachment.
>
> For a related trifle, no PGP or S/MIME signatures could have pointed out
> that I altered a few bits in the text quoted above, attributed to Ned.
> Did I thus break authentication, non-repudiation, or integrity?
>
I know people think I'm wrong, but I think it needs to be looked at a 
different way. As a recipient, I don't want 'proof' that this message 
came from Alessandro, I want 'proof' that it came from the 
ietf-822@ietf.org mailing list.

I have chosen to trust that mailing list. What I don't want is to 
receive messages pretending to be from that mailing list, but not really 
coming from it.

Then, because I trust that mailing list, I trust that it has done what 
it can to be sure that messages which claim to come from Alessandro 
really did.

So, I see the mailing list as being the 'final' recipient of the message 
from Alessandro. Then, the mailing list sent a new message to me, 
containing (to a reasonable degree) the content of the message which 
Alessandro sent. I did NOT receive the message from Alessandro, I 
received the 'essence' of that message, in a new message from the 
mailing list. The mailing list is not simply a forwarder/redistribution 
list, it is an entity in its own right, which receives and sends 
messages. (If you want, you could get the mailing list to include the 
original message as an attachment, so signatures etc can be validated in 
that).

Once you think of it in that way, then the problems become a lot fewer, 
IMHO. I don't really see how it can work any other way, without 
castrating the mailing list system so it just becomes a dumb 
distribution system.

-


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53