Subject: [MLS] Working calls: Notes from today and plans for the next few weeks

From: Richard Barnes <[email-masked]>
Date: Thu, 20 Jan 2022 16:27:50 -0500

Hey folks,

A few of us that had been working PRs/issues on GitHub had a call this
morning to try to make faster progress.  Notes are below.

We're going to try to do weekly calls the next few weeks to keep progress
moving.  Next week will be unofficial, thereafter we'll make them official
virtual interims.  The planned time for next week is Thursday, Jan 27,
15:00-17:00 UTC.

https://www.timeanddate.com/worldclock/fixedtime.html?msg=MLS+PR%2FIssue+calls&iso=20220127T10&p1=263&ah=2

Webex link for next week is: <https://cisco.webex.com/meet/richbarn>.  For
the official virtual interims after that, the chairs should be able to
provide a bridge.

Thanks to everyone who dialed in today.  Look forward to advancing toward
completion in the coming weeks!

Best,
--Richard

(Notes by PR #)

#546 - Filed just before the call, needs some time for review.

#543 - Richard changed everything to “mls10”.  Théophile says “MLS 1.0” is
clearer.  Richard agrees, will update the PR and merge.

TODO(Richard) - Switch to “MLS 1.0” and merge

#544 / #532 - Basically three options here: (1) do nothing, (2) remove
version fields [#532], (3) remove version from ciphersuite [#544].  General
agreement to do either 2 or 3.  Richard is strongly opposed to removing
version fields, to enable ciphersuite reuse across versions, and because
versions are logically just different from ciphers.  Raphael notes that the
reasoning behind the current scheme was to force consideration of whether
to carry ciphers forward into new versions.

TODO(Richard) - Add some advisory text and merge.

#526 - Richard suggests removing the context from the signature, pointing
out that it’s duplicative with membership_tag / AEAD, so it would only be
necessary if the signature is to “stand alone”.  Raphael points out that
you might want to process the signature alone, e.g., at a delivery server.

TODO(Théophile) - Update to add context to new_member case, then ready to
merge.

#525 - There are a couple of small things for Richard to fix, otherwise
good to merge.

TODO(Richard) - Clean up and merge

#524 - Joël presented some analysis that he had done with Marta and Daniel
on options here, basically (1) aggressive merge + removing “redundant”
parent nodes that have only one child, and (2) careful merge.  While
there’s some aesthetic appeal to removing redundancy, it would involve a
little complexity.  So there was agreement to do careful truncation for now
(to un-break the spec) and then see if we can figure out how to remove
redundant nodes.

TODO(Richard) - Merge #524
TODO(Richard+Marta) - Propose a PR removing redundant nodes

#527 - Joël mentioned an alternative approach based on incorporating only
leaf nodes (which provides similar properties to including the resolution
assuming the tree invariant holds).  This is probably less efficient than
tree hashing, though the ambiguities around reconstruction in the tree hash
case make it a little hard to tell.  There was some discussion about
exactly what high-level security properties we get out of a stronger tree
hash.

TODO(Théophile) - Write a note to the list summarizing the tree-hash-based
parent hash proposal and its security implications, incorporating fixes to
the “right edge of the tree” problems.

---

From: Richard Barnes <[email-masked]>
Date: Mon, 24 Jan 2022 18:25:10 -0500

Hey all,

I just sent an invite for Thursday morning (US time) to those who were on
the call last week.  Please let me know 1:1 if I should add you.

--RLB

On Thu, Jan 20, 2022 at 4:27 PM Richard Barnes <[email-masked]> wrote:

> Webex link for next week is: <https://cisco.webex.com/meet/richbarn>.
> For the official virtual interims after that, the chairs should be able to
> provide a bridge.
>

---

From: Richard Barnes <[email-masked]>
Date: Thu, 27 Jan 2022 09:35:15 -0500

Hey all,

Sorry, I thought I sent this out yesterday, but apparently failed to and
deleted the draft.  Here's a proposed agenda for today's call.

--Richard

#546 - Downgrade MUST to SHOULD for commit senders including all valid
commits
#542 - Conflicting proposal / commit behavior

#509 - Be explicit that Credentials can attest to multiple identities

#523 - Move wire_format to a separate tagged-union structure MLSMessage

#540 - Proposals by reference in external commit

#537 - Clarity around extensions and RequiredCapabilities

#539 - Separation between pre-published key packages and leaf node content
#538 - KeyPackage lifetime handling

#527 - Stronger parent hashes for authenticated identities

#556 - Fix some typos.
#555 - Add clarifying note about _resolution_ in the most common case.
#554 - Use common-sense definition of _descendant_
#553 - Make definition of _group_ match the Introduction definition
#552 - fetching KeyPackages SHOULD be rate limited.
#551 - Rename InitKeys -> KeyPackages; and GroupInfo -> PublicGroupState

#409 - Draft structure/Editorial Changes editorial

---

From: Théophile Wallez <[email-masked]>
Date: Thu, 27 Jan 2022 15:52:33 +0100

Hey,

Can we talk about #527 (stronger parent hash) earlier (at least a bit 
briefly)? Karthik would like to attend this part of the call but it's 
already quite late in his current location.

Thanks,
Théophile.

On 27/01/2022 15:35, Richard Barnes wrote:
> Hey all,
>
> Sorry, I thought I sent this out yesterday, but apparently failed to 
> and deleted the draft.  Here's a proposed agenda for today's call.
>
> --Richard
>
>     A few of us that had been working PRs/issues on GitHub had a call
>     this morning to try to make faster progress. Notes are below.
>
>     We're going to try to do weekly calls the next few weeks to keep
>     progress moving.  Next week will be unofficial, thereafter we'll
>     make them official virtual interims.  The planned time for next
>     week is Thursday, Jan 27, 15:00-17:00 UTC.
>
>     <https://www.timeanddate.com/worldclock/fixedtime.html?msg=MLS+PR%2FIssue+calls&iso=20220127T10&p1=263&ah=2>
>
>     Webex link for next week is:
>     <https://cisco.webex.com/meet/richbarn>. For the official virtual
>     interims after that, the chairs should be able to provide a bridge.
>
>     Thanks to everyone who dialed in today.  Look forward to advancing
>     toward completion in the coming weeks!
>
>     Best,
>     --Richard
>
>     (Notes by PR #)
>
>     #543 - Richard changed everything to “mls10”.  Théophile says “MLS
>     1.0” is clearer.  Richard agrees, will update the PR and merge.
>
>     #544 / #532 - Basically three options here: (1) do nothing, (2)
>     remove version fields [#532], (3) remove version from ciphersuite
>     [#544].  General agreement to do either 2 or 3.  Richard is
>     strongly opposed to removing version fields, to enable ciphersuite
>     reuse across versions, and because versions are logically just
>     different from ciphers.  Raphael notes that the reasoning behind
>     the current scheme was to force consideration of whether to carry
>     ciphers forward into new versions.
>
>     #526 - Richard suggests removing the context from the signature,
>     pointing out that it’s duplicative with membership_tag / AEAD, so
>     it would only be necessary if the signature is to “stand alone”. 
>     Raphael points out that you might want to process the signature
>     alone, e.g., at a delivery server.
>
>     TODO(Théophile) - Update to add context to new_member case, then
>     ready to merge.
>
>     #525 - There are a couple of small things for Richard to fix,
>     otherwise good to merge.
>
>     #524 - Joël presented some analysis that he had done with Marta
>     and Daniel on options here, basically (1) aggressive merge +
>     removing “redundant” parent nodes that have only one child, and
>     (2) careful merge.  While there’s some aesthetic appeal to
>     removing redundancy, it would involve a little complexity.  So
>     there was agreement to do careful truncation for now (to un-break
>     the spec) and then see if we can figure out how to remove
>     redundant nodes.
>
>     #527 - Joël mentioned an alternative approach based on
>     incorporating only leaf nodes (which provides similar properties
>     to including the resolution assuming the tree invariant holds). 
>     This is probably less efficient than tree hashing, though the
>     ambiguities around reconstruction in the tree hash case make it a
>     little hard to tell. There was some discussion about exactly what
>     high-level security properties we get out of a stronger tree hash.
>
>     TODO(Théophile) - Write a note to the list summarizing the
>     tree-hash-based parent hash proposal and its security
>     implications, incorporating fixes to the “right edge of the tree”
>     problems.
>
>
> _______________________________________________
> MLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mls