[lamps] How to proceed with Header Protection requirements

Bernie Hoeneisen <bernie@ietf.hoeneisen.ch> Tue, 29 October 2019 20:07 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 67C611200A3 for <spasm@ietfa.amsl.com>; Tue, 29 Oct 2019 13:07:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] 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 gpfgUYrST_Oe for <spasm@ietfa.amsl.com>; Tue, 29 Oct 2019 13:07:26 -0700 (PDT)
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 1FC9612007A for <spasm@ietf.org>; Tue, 29 Oct 2019 13:07:25 -0700 (PDT)
Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.86_2) (envelope-from <bernie@ietf.hoeneisen.ch>) id 1iPXlz-00041r-KG for spasm@ietf.org; Tue, 29 Oct 2019 21:07:23 +0100
Date: Tue, 29 Oct 2019 21:07:23 +0100
From: Bernie Hoeneisen <bernie@ietf.hoeneisen.ch>
X-X-Sender: bhoeneis@softronics.hoeneisen.ch
To: IETF LAMPS WG <spasm@ietf.org>
Message-ID: <alpine.DEB.2.20.1910292031370.3308@softronics.hoeneisen.ch>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
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/xu3zgRqYEHBYkVe0dVMMGr9lw_0>
Subject: [lamps] How to proceed with Header Protection requirements
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: Tue, 29 Oct 2019 20:07:28 -0000

Dear LAMPS WG

We have submitted a new version of Header Protection Requirement that 
includes feedback from the LAMPS WG session in Montreal. Please find it at
https://datatracker.ietf.org/doc/draft-ietf-lamps-header-protection-requirements/


1) There are several open issues to be resolved, including

    o  In which form requirements for backward compatibility
       to legacy Header Protection should remain in this document?

    o  Should requirement G3 remain?
       "There SHOULD be a single format that covers all protection levels."

    o  Are there requirements missing?

    o  Should some requirement be stripped from the document?

Any comments?


2) Content-Type Parameter "forwarded"

During the LAMPS session in Montreal the introdution of a new Content-Type 
Parameter "forwarded" (as described in appendix A.1.2.1.) received quite 
some support. Several members of the LAMPS session expressed this to be 
useful. Not only in the context of encapsulated vs. forwarded message 
(incl. Header Protection), but also for helping with mailing list 
operations. At least two implementations using the Content-Type Parameter 
"forwarded" exist at this time.

Proposal:

   Standardize Content-Type Parameter "forwarded" as Working Group item of
   the LAMPS WG (to assist Header Protection and mailing lists).

Note: Which option to choose for Header Protection shall remain open. This 
proposal is not contradictionary to any of the options described in A1, 
but rather complementary.

Any opinions on this proposal?


Looking forward to your feedback and comments.


cheers,
  Bernie

--

http://ucom.ch/
Modern Telephony Solutions and Tech Consulting for Internet Technology