[lamps] IETF 104 LAMPS draft minutes

[Tim Hollebeek <[e-mail]>]

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