Messaging Layer Security
charter-ietf-mls-01
Yes
No Objection
Note: This ballot was opened for revision 00-02 and is now closed.
Ballot question: "Do we approve of this charter?"
Alvaro Retana No Objection
Warren Kumari No Objection
(Adam Roach; former steering group member) Yes
(Alexey Melnikov; former steering group member) Yes
(Alissa Cooper; former steering group member) Yes
(Ben Campbell; former steering group member) Yes
(Benjamin Kaduk; former steering group member) Yes
I still need to tweak the language a little in response to comments received.
(Eric Rescorla; former steering group member) Yes
(Terry Manderson; former steering group member) Yes
(Deborah Brungard; former steering group member) No Objection
(Ignas Bagdonas; former steering group member) No Objection
(Martin Vigoureux; former steering group member) No Objection
(Mirja Kühlewind; former steering group member) No Objection
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).
(Spencer Dawkins; former steering group member) No Objection
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; former steering group member) No Objection