Subject: [MLS] Spencer Dawkins' No Objection on charter-ietf-mls-00-02: (with COMMENT)

From: Spencer Dawkins <[email-masked]>
Date: Fri, 18 May 2018 11:25:10 -0700

Spencer Dawkins has entered the following ballot position for
charter-ietf-mls-00-02: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-mls/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm looking at "In developing this protocol, we will draw on lessons learned
from several prior message-oriented security protocols", and I'm wondering
whether these lessons have already been written down, or if the working group
plans to write them down. I don't see any mention of either an existing
reference or a deliverable, so thought I would ask. Is a list of lessons
learned something that would have value outside the work MLS would be chartered
to do?

I saw Mirja's comment about naming drafts in the charter - that's actually a
good thing to notice, because someone might argue that the working group isn't
chartered to work on another approach, if the working group encounters problems
with its initial direction.

One phrasing I see used, is something like

"The QUIC working group will provide a standards-track specification for a
UDP-based, stream-multiplexing, encrypted transport protocol, based on
pre-standardization implementation and deployment experience, and generalizing
the design described in draft-hamilton-quic-transport-protocol,
draft-iyengar-quic-loss-recovery, draft-shade-quic-http2-mapping, and
draft-thomson-quic-tls."

I also see charters that say something like "the working group will use
draft-foo and draft-bar as a starting point".

-- not part of my ballot position, only curiosity --

I have an honest question (which will affect my ballot position in no way, so
cluing me in privately would be a reasonable response).

I see people talking a lot more often about perfect forward secrecy than about

o Post-compromise security - Full compromise of a node at a
  point in time does not reveal future messages sent within the group

Is "post-compromise security" equally well understood in the community?