Subject: [lamps] IETF 104 LAMPS draft minutes

From: Tim Hollebeek <[email-masked]>
Date: Fri, 19 Apr 2019 14:17:26 +0000

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

---

From: Bernie Hoeneisen <[email-masked]>
Date: Fri, 19 Apr 2019 20:30:01 +0200 (CEST)

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:

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:

> DKG: let's consolidate these drafts, and if the charter is updated we can make
> 
> it draft-ietf-lamps-*.
> 
>  
> 
>  
> 
> Tim Hollebeek: injecting hash state into the HSM changes the security model of
> 
> the HSM.
> 
>  
> 
> side-channel attacks are applicable to multi-level trees that aren't relevant
>

---

From: Russ Housley <[email-masked]>
Date: Fri, 19 Apr 2019 14:45:40 -0400

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 <[email-masked]> wrote:
> 
> Hi Tim
> 
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm