Re: not really pgp signing in van

Måns Nilsson <mansaxel@besserwisser.org> Tue, 10 September 2013 11:08 UTC

Return-Path: <mansaxel@besserwisser.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6241F21E80F7 for <ietf@ietfa.amsl.com>; Tue, 10 Sep 2013 04:08:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.996
X-Spam-Level:
X-Spam-Status: No, score=-0.996 tagged_above=-999 required=5 tests=[AWL=1.294, BAYES_00=-2.599, DRUGS_PAIN=0.01, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rd6m-bz93zwc for <ietf@ietfa.amsl.com>; Tue, 10 Sep 2013 04:08:44 -0700 (PDT)
Received: from jaja.besserwisser.org (jaja.besserwisser.org [IPv6:2a01:298:4:0:211:43ff:fe36:1299]) by ietfa.amsl.com (Postfix) with ESMTP id BE9AF21E812C for <ietf@ietf.org>; Tue, 10 Sep 2013 04:08:39 -0700 (PDT)
Received: by jaja.besserwisser.org (Postfix, from userid 1004) id 42F249E76; Tue, 10 Sep 2013 13:08:37 +0200 (CEST)
Date: Tue, 10 Sep 2013 13:08:37 +0200
From: Måns Nilsson <mansaxel@besserwisser.org>
To: John Levine <johnl@taugh.com>
Subject: Re: not really pgp signing in van
Message-ID: <20130910110836.GB15954@besserwisser.org>
References: <1604134.0PAONl8GoT@scott-latitude-e6320> <20130910010719.33978.qmail@joyce.lan>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="EuxKj2iCbKjpUGkD"
Content-Disposition: inline
In-Reply-To: <20130910010719.33978.qmail@joyce.lan>
X-URL: http://vvv.besserwisser.org
X-Purpose: More of everything NOW!
X-happyness: Life is good.
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: scott@kitterman.com, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Sep 2013 11:08:45 -0000

Subject: Re: not really pgp signing in van Date: Tue, Sep 10, 2013 at 01:07:19AM -0000 Quoting John Levine (johnl@taugh.com):
> 
> The MUAs I use (Thunderbird, Alpine, Evolution) support S/MIME a lot
> better than they support PGP.  There's typically a one key command or
> a button to turn signing and encryption on and off, and they all
> automagically import the certs from on incoming mail.

<advocacy type=MUA>
That is why you should start using mutt. Mutt fetches the PGP key that
signed a received message from key servers if it is not present in
the local keyring, and verifies it. 
</advocacy>

As a result, I've got all the IETFers that sign messages saved in my
key ring. Automatically. Subsequent signed messages from that same sender
will either validate or be very clearly flagged as fakes. 

This is exactly the same security level that all SSH fans know
and love, ie. wide open for MITM and impostors. It is -- however --
upgradeable to "really useful" by verifying and signing the sending keys.

As has been stated before, MIME multipart signatures and their
structured data are definitely capable of maintaining the integrity
of the message one is replying to. Frequently, though, this either
means that replying properly will trash the message or deteriorate into
top-posting. Top-posting, while normally a flogging offense in my book,
has the advantage of preserving the replied-to text slightly better. The
conversation structure is OTOH trashed[0]

The one thing that comes out of this message, then, is that this is a
end-node problem that is probably best solved in MUA implementations. A
possible method could be to design a "diff" multipart -- that is a list
of edits (i'm thinking of something like "diff -e" that makes a diff as
an "ed" script that can be applied to the original message.)  applied to
the replied-to message. This multipart is then signed and transmitted,
and the receiving MUA then performs validation of the replied-to text
part, the diff part, and if they validate, will merge them, creating
a clear presentation of which lines are original and which ones are
edited. For reference, the original message of course is included and
the MUA should have a display option to show the original unaltered.

There are several problems with the above idea, for instance the notion of
ever-growing emails as all posters simply shove the history downwards to
push their stellar insights on top of the pile, but today, that is mainly
a display problem. Since I'm suggesting a fairly aggressive presentation
system with preserved history, I think that is tolerable.

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
I feel like a wet parking meter on Darvon!

[0] A: Because it messes up the order in which people normally read text.
    Q: Why is top-posting such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing in e-mail?