[MLS] All commits = external commit?

[Joel Alwen <[e-mail]>]

Hey people,

To follow up on the discussion at the end of the Interim about whether to use
the new "asymmetric external commit" (AEC) mechanism for internal commits I
wanted to summarize my thoughts here. For brevity let SIC be our current
"symmetric internal commit" mechanism.

- AEC requires extra asymmetric crypto operations (both for committer and
receiver) compared to SIC which I think we should avoid if we can, even at the
cost of some code complexity.

- AEC doesn't ensure the committer knows the old epoch's key schedule. This can
play a deciding role in several types of attacks.

Consider this execution:

1. Alice is in a group. Her state leaks (including her signining key).
2. Alice commits (to arbitrary propal).

At this point, the adversary can still forge a new AEC from Alice but not an SIC.

Worse, step 2 could have instead been "Alice sends an update proposal replacing
her leaf HPKE but keeping the her sig keys (e.g. because new credentials are
costly to come by). Someone commits to the new proposal." At this point I'd
expect PCS to have kicked in for Alice (as it does when using SIC). But not for
AECs since Alice's signing key is all thats needed to forge a new AEC.

I think it is not worth weakening security this way if we dont have to.
(Especially, since in some deployments external commits may not be a supported
feature at all.)

- As for what may or may not be displaid to users, that's really up to the
implementation. IMO our goal should be to make the protocol as secure as we can
subject to reasonable costs. Which aspects of the resulting security properties
are ultimately communicated to users should, in principle, be left up to
implementations. That means we shouldn't be designing away security features
only because we think they might be hard to communicate. (Nor does it seem that
inconceivable to me that some implementation may end up explicitly signaling
whether a commit was external vs internal.)

- Joël