Messaging Layer Security
charter-ietf-mls-01

Note: This ballot was opened for revision 00-02 and is now closed.

Ballot question: "Do we approve of this charter?"

(Ben Campbell) Yes

Alissa Cooper Yes

Benjamin Kaduk Yes

Comment (2018-05-24 for -00-02)
No email
send info
I still need to tweak the language a little in response to comments received.

(Terry Manderson) Yes

(Alexey Melnikov) Yes

(Eric Rescorla) Yes

(Adam Roach) Yes

(Ignas Bagdonas) No Objection

Deborah Brungard No Objection

(Spencer Dawkins) No Objection

Comment (2018-05-18 for -00-02)
No email
send info
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?

(Suresh Krishnan) No Objection

Warren Kumari No Objection

(Mirja K├╝hlewind) No Objection

Comment (2018-05-18 for -00-02)
No email
send info
Based on the feedback provided by Paul Wouters: What's the relationship to ORT?

Also a minor comment: Not sure if the drafts need to be listed in the charter. This seems very unusal as there should still be an adoption call (after the wg has been formed).

Alvaro Retana No Objection

Martin Vigoureux No Objection