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): 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.

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