Re: [lamps] IETF 104 LAMPS draft minutes

Bernie Hoeneisen <bernie@ietf.hoeneisen.ch> Fri, 19 April 2019 18:30 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 EFCE0120320 for <spasm@ietfa.amsl.com>; Fri, 19 Apr 2019 11:30:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 KbmBsCShVw59 for <spasm@ietfa.amsl.com>; Fri, 19 Apr 2019 11:30:05 -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 7721B120110 for <spasm@ietf.org>; Fri, 19 Apr 2019 11:30:04 -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 1hHYGv-0000Gu-J4; Fri, 19 Apr 2019 20:30:01 +0200
Date: Fri, 19 Apr 2019 20:30:01 +0200 (CEST)
From: Bernie Hoeneisen <bernie@ietf.hoeneisen.ch>
X-X-Sender: bhoeneis@softronics.hoeneisen.ch
To: Tim Hollebeek <tim.hollebeek@digicert.com>
cc: SPASM <spasm@ietf.org>
In-Reply-To: <BN6PR14MB11062AE6D59CF1E7BA0B8B3183270@BN6PR14MB1106.namprd14.prod.outlook.com>
Message-ID: <alpine.DEB.2.20.1904192022580.30433@softronics.hoeneisen.ch>
References: <BN6PR14MB11062AE6D59CF1E7BA0B8B3183270@BN6PR14MB1106.namprd14.prod.outlook.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="37663318-512300344-1555698601=:30433"
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/VlCA50VvZiSsrXjAHDT3H4YS2qE>
Subject: Re: [lamps] IETF 104 LAMPS draft minutes
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: Fri, 19 Apr 2019 18:30:08 -0000

Hi Tim

Thanks for the information on the minutes.

After listening to the streams, I suggest the follwing changes, which is
slightly more accurate:


OLD:

  Krista (pEp implementer): MIME libraries needed to be hacked.  With the
  wrapping approach, you had an easier implementation.  The "memory hole"
  approach required hacking the MIME library.

  Krista: for legacy clients, though, the visual representation of wrapped
  messages is worse.


NEW:

  Krista (pEp implementer): Implemented both approaches.  With the "memory
  hole" approach parsing was a real pain, as it required hacking the MIME
  library.  With the wrapping approach, just move something from one node
  in the MIME tree to another node, implementations get a lot easier.

  Krista: It would be incredibly helpful, if we had some mechanism to
  distinguish between wrapped messages and forwarded messages. What we see
  in Thunderbird right now is, that it does look fairly ugly, because
  people are getting forwarded messages and they don't know why.


cheers
  Bernie

--

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


On Fri, 19 Apr 2019, Tim Hollebeek wrote:

> 
> The following draft minutes have been uploaded to the datatracker. 
> 
> If anyone has any comments or corrections, let me know.
> 
>  
> 
> LAMPS Session at IETF 104
> 
> Tuesday, 26 March 2019 at 11:20
> 
>  
> 
> Minutes from notes taken by Daniel Kahn Gillmor
> 
>  
> 
>  
> 
> Executive Summary
> 
>  
> 
> There are currently five documents with the IESG, and the only active
> 
> working group document is ready for WG Last Call.  There were no comments
> 
> on these documents.  Two drafts exist related to a pending re-charter
> 
> to address e-mail header protection.  These drafts will be consolidated
> 
> if the re-charter is approved.  Two presentations were made on quantum
> 
> safe certificates and signatures.  Concerns about tradeoffs between
> 
> number of signatures and key generation time were discussed, as well as
> 
> single tree vs multi tree issues.  A lightweight profile for CMP was
> 
> presented and will be discussed on the list.  Work needs to be coordinated
> 
> with ACE.
> 
>  
> 
> 0)  Minute Taker, Jabber Scribe, Bluesheets
> 
>  
> 
> Participants were reminded about the NOTE WELL.
> 
>  
> 
>  
> 
> 1)  Agenda Bash
> 
>  
> 
> No agenda changes.
> 
>  
> 
>  
> 
> 2) Documents with the IESG
> 
>     a)  draft-ietf-lamps-rfc6844bis (Jacob and Phillip)
> 
>    b)  draft-ietf-lamps-hash-of-root-key-cert-extn (Russ)
> 
>     c)  draft-ietf-lamps-pkix-shake (Panos and Quynh)
> 
>     d)  draft-ietf-lamps-cms-shakes (Quynh and Panos)
> 
>     e)  draft-ietf-lamps-cms-hash-sig (Russ)
> 
>  
> 
> No comments were made on any of the documents with IESG.
> 
>  
> 
>  
> 
> 3)  Documents in WG Last Call
> 
>  
> 
> 4)  Active Working Group Documents
> 
>     a)  draft-ietf-lamps-cms-mix-with-psk (Russ)
> 
>  
> 
> No comments from the mic line.  Tim will start the WG Last Call on the
> 
> document.
> 
>  
> 
>  
> 
> 5)  Documents related to the pending re-charter
> 
>     a)  draft-luck-lamps-pep-header-protection (Bernie)
> 
>  
> 
> DKG commented that we need to explicitly state how encryption-only e-mail
> 
> messages must be handled.
> 
>  
> 
> Massimiliano Pala (CableLabs) suggested that encryption-only messages could
> 
> have guidance to display with no security indicators.
> 
> Alexey Melnikov says that we need to make sure we document existing problems
> 
> with legacy clients.  If all other things are equal, and there are different
> 
> side effects on UI for legacy clients.
> 
>  
> 
> DKG raised concerns about MIME structure constraints, will send the concerns
> 
> to the list.
> 
>  
> 
>     b)  draft-melnikov-lamps-header-protection (Alexey)
> 
>  
> 
> It was suggested that this might be a good topic for the next hackathon.
> 
>  
> 
> Krista (pEp implementer): MIME libraries needed to be hacked.  With the
> 
> wrapping approach, you had an easier implementation.  The "memory hole"
> 
> approach required hacking the MIME library.
> 
>  
> 
> Krista: for legacy clients, though, the visual representation of wrapped
> 
> messages is worse.
> 
>  
> 
> DKG: let's consolidate these drafts, and if the charter is updated we can make
> 
> it draft-ietf-lamps-*.
> 
>  
> 
>  
> 
> 6)  Other Business (if time allows)
> 
>     a)  draft-vangeest-x509-hash-sigs (Daniel)
> 
>  
> 
> DKG: streaming API for verification is problematic -- emitting content
> 
> before establishing verification encourages data misuse.
> 
>  
> 
> Jim Schaad: It's possible that we need streaming for verification (but not
> 
> an HSM concern -- agree that verification is expected to be done on normal
> 
> hardware)
> 
>  
> 
> Massimiliano: if the HSM can export hash state to the client, and get it
> 
> back, then you can avoid streaming.
> 
>  
> 
> Tim Hollebeek: injecting hash state into the HSM changes the security model of
> 
> the HSM.
> 
>  
> 
> Qunyh Dang: why do we need multiple trees?  why not one flat layer?  Some
> 
> side-channel attacks are applicable to multi-level trees that aren't relevant
> 
> to single-level trees.  Can forward to the mailing list.
> 
>  
> 
> Scott Fluhrer: one XMSS tree can only do one million signatures.  LMSS is
> 
> limited to 32 million.
> 
>  
> 
> Qunyh: we could change the algorithm parameters to change the limits.
> 
>  
> 
> Tim: those parameters affect key generation time.
> 
>  
> 
> Russ Housley: possibly weeks to generate the key.
> 
>  
> 
> Scott: on my multicore system took 1.5hrs to generate a 25-deep tree.
> 
>  
> 
> Qunyh: i'm tentatively OK, will send side-channel concern to the list.
> 
>  
> 
>     b)  quantum-safe certificates (Scott)
> 
>  
> 
> Massimiliano: i'm concerned that the draft shares similarities with
> 
> some IP we have.  IPR: we published a disclosure -- royalty-free
> 
> with reciprocity.
> 
>  
> 
> Mike Ounsworth: (editor on this draft) will follow up with
> 
> Massimiliano, we hadn't meant to slight anyone. re: IPR we're all
> 
> on the same page, interested in this being completely free/open.
> 
>  
> 
>     c)  lightweight profile of CMP (Hendrik)
> 
>  
> 
> Russ: this is currently not in the charter.  if folks are interested,
> 
> we'd need to recharter.
> 
>  
> 
> Massimiliano: we have use cases where there is a struggle to come
> 
> up with a profile that all the devices understand.  see also work
> 
> in the EMU WG about provisioning credentials through EAP
> 
>  
> 
> Sean Turner: ACE is looking at exactly this sort of thing. If we
> 
> adopt this, we're stepping on toes.  Please coordinate.
> 
>  
> 
> Russ: we'll discuss on the list.
> 
>  
> 
>     d)  draft-pala-composite-crypto (Max)
> 
>  
> 
> Not presented due to time constraints.
> 
>  
> 
> 7)  Wrap Up
> 
>  
> 
> 
>