Re: [lamps] IETF 104 LAMPS draft minutes

Russ Housley <housley@vigilsec.com> Fri, 19 April 2019 18:45 UTC

Return-Path: <housley@vigilsec.com>
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 B9BB212015E for <spasm@ietfa.amsl.com>; Fri, 19 Apr 2019 11:45:47 -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 S-CgsQD6zCwW for <spasm@ietfa.amsl.com>; Fri, 19 Apr 2019 11:45:45 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C68F8120110 for <spasm@ietf.org>; Fri, 19 Apr 2019 11:45:44 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 64E8A300AE3 for <spasm@ietf.org>; Fri, 19 Apr 2019 14:27:26 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 77mGa8_RiBHI for <spasm@ietf.org>; Fri, 19 Apr 2019 14:27:24 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id D89B63004C7; Fri, 19 Apr 2019 14:27:23 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <alpine.DEB.2.20.1904192022580.30433@softronics.hoeneisen.ch>
Date: Fri, 19 Apr 2019 14:45:40 -0400
Cc: Tim Hollebeek <tim.hollebeek@digicert.com>, SPASM <spasm@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6AB85C9D-085D-4F9A-9E58-50567EA87BC1@vigilsec.com>
References: <BN6PR14MB11062AE6D59CF1E7BA0B8B3183270@BN6PR14MB1106.namprd14.prod.outlook.com> <alpine.DEB.2.20.1904192022580.30433@softronics.hoeneisen.ch>
To: Bernie Hoeneisen <bernie@ietf.hoeneisen.ch>
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/FK969W8e53T7lNROSoSsVHjrd60>
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:45:48 -0000

Thanks for the careful review.  I have changed the two paragraphs as follows:

   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, so implementation gets 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 today looks fairly ugly; people think they are getting
   forwarded messages, and they don't know why.

Russ

> On Apr 19, 2019, at 2:30 PM, Bernie Hoeneisen <bernie@ietf.hoeneisen.ch> wrote:
> 
> 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
>>  
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm