Re: [lamps] Draft addition of header protection to the LAMPS charter

bernie@ietf.hoeneisen.ch Sat, 05 January 2019 10:09 UTC

Return-Path: <bernie@ietf.hoeneisen.ch>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04CF5128CB7 for <spasm@ietfa.amsl.com>; Sat, 5 Jan 2019 02:09:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 o3-sC9W1YDTw for <spasm@ietfa.amsl.com>; Sat, 5 Jan 2019 02:09:09 -0800 (PST)
Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A73B5124B0C for <spasm@ietf.org>; Sat, 5 Jan 2019 02:09:08 -0800 (PST)
Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.86_2) (envelope-from <bernie@ietf.hoeneisen.ch>) id 1gfit5-00038i-KW; Sat, 05 Jan 2019 11:09:03 +0100
Date: Sat, 05 Jan 2019 11:09:03 +0100
From: bernie@ietf.hoeneisen.ch
X-X-Sender: bhoeneis@softronics.hoeneisen.ch
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
cc: John Levine <johnl@taugh.com>, spasm@ietf.org
In-Reply-To: <87h8eonzxx.fsf@fifthhorseman.net>
Message-ID: <alpine.DEB.2.20.1901051041470.26171@softronics.hoeneisen.ch>
References: <20190104012415.AA6C3200C425F9@ary.qy> <87h8eonzxx.fsf@fifthhorseman.net>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="US-ASCII"
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch
X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/eVgsymUeOHYXm-eMV1fHj63Udns>
Subject: Re: [lamps] Draft addition of header protection to the LAMPS charter
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 05 Jan 2019 10:09:12 -0000

Hi Daniel

Thanks for your comments.

On Fri, 4 Jan 2019, Daniel Kahn Gillmor wrote:

> On Thu 2019-01-03 20:24:15 -0500, John Levine wrote:
>> In article <alpine.DEB.2.20.1901032153560.13542@softronics.hoeneisen.ch> you write:
>>
>>> I think we need to include what's the current situation with this
>>> issue, in particular mention that there is a solution in on Standards
>>> Track already (RFC5751). How about something like this:
>
> Bernie, thanks for your proposed change.  The second revision of your
> text looks fine to me.  It is certainly "not widely implemented" --
> iirc, there was only one implementation of it anywhere last i looked.

There are certainly more than just one implementation of S/MIME version 
3.1 / 3.2 Header Protection in the wild. Unfortunately, most of these 
implementations offer this as an optional feature only (e.g. to prevent 
interoperability issues). As a consequence, the Header protection feature 
is mostly hidden.

Outside the S/MIME world I am aware of at least 4 further implementations 
that use RFC 5751 mechanisms for doing header protection.


> FWIW, i lean in Bernie's direction as far as "somewhat underspecified"
> because the specification does lead to significant usability gaps (as
> identified later in the proposed charter text) due to lack of guidance
> about how a receiving MUA should interpret conflicting headers on the
> inside and outside of the message's cryptographic envelope ("This entity
> SHOULD be presented as the top-level message, taking into account header
> merging issues as previously discussed." -- but with no mention of
> "merging" anywhere else in the document).

Yep, that's another challenge faced.


Furthermore, we probably should also look into "feature negotiation" 
capabilities, e.g. to detect whether the other party is (parties are) 
capable of handling Header protection messages.


cheers,
  Bernie