Re: [lamps] IETF 104 LAMPS draft minutes

[Russ Housley <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm