Note-taker: Jonathan Hammell
Rohan has a couple slides for additional extensions. Can likely include
them. No other agenda bashing.
Prior discussion occured on the mailing list.
No additional opinions raised in the room.
Eric Rescorla will perform the merge.
Document will be sent to AD for publication.
Three approaches for confidentiality:
Rohan Mahy: Does Approach 2 provide protection against harvest now,
decrypt later?
Britta Hale: It protects against quantum attackers outside the group PQ
session.
Richard Barnes: Implemented a ciphersuite with X25519/ML-KEM. It didn't
seem too expensive in experiments. Processing times were low double
digit percentage slower. Remove commits were bigger. Maybe not super
urgent to do optimizations. Approach 3 seems more appealing and might be
done in a single ciphersuite.
Sean Turner: What is the impact on size between the approaches. But that
was answered.
Rohan Mahy: Implemented X25519/Kyber and it was faster than
implementation of P-256. Things got marginally larger in comparison to
certificates. We should definitely do Approach 1. The only thing needed
from the WG for Approach 2 is to register a ciphersuite, but given the
hybrid is so fast, it could be used here as well. Joel had expressed
some ideas on Approach 3 that would reuse parameters across groups. Any
comment on that?
Eric Rescorla: Agree with Richard's comments on support of Approach 1.
Don't want a combinatoric explosion of ciphers. Approach 2 may be two
hard to analyze and manage. Approach 3 seems close to 1. No use cases
requiring a small bandwidth.
Daniel Khan Gillmor: Approach 1 seems like the obvious thing to do. Do
think we should do Approach 2. Approach 3 has too many mechanics which
could confuse user or policy.
PQ Authenticity. The approaches chosen above have impacts. What are the
PQ authenticity concerns and how urgently is it needed?
Rohan Mahy: Is there a difference between importance of PQ signatures
for identity versus ephemeral signature?
Britta: Time separation, likely. Identity rolls less frequently. But
down the road, the difference may be less.
Rohan: A PQ signature for a key package valid for three months is more
important than signatures within the group where I can update it more
frequently. In favour of Approach 2 (eventually).
Eric Rescorla: If there is a viable cryptographically-relevant quantum
computer, then all signatures must be post-quantum, right?
Britta: There may be partial attacks in the timeline of QC development.
We are considering protection now with PQ KEMs, so makes sense to
consider signatures.
Eric: There is a harvest now, decrypt later concern for KEMs. There is a
concern to get deployment ahead of the QC development. What are you
getting by doing traditional some of the time and PQ some of the time.
The credentials are a short term consideration.
Britta: One consideration is trust in new PQ algorithms. Suppose there
is a QC available to a state adversary. The quantum threat is restricted
to that state adversary, but every other adversary is still bound to
classical attacks. In a few years from now, where are the concerns going
to be?
Eric: The PQ algorithm is expensive, but the classical is not in
comparison. The versions where you use PQ some of the time does not make
sense.
Deirdre Connolly: Having PQ-only for signatures are simpler to write
down for those that may wish to use them. Are there any concerns with
credentials being hard to rotate between conventional and PQ
ciphersuites.
Richard: It is not obvious there is a barrier to rotating the
ciphersuite. The bigger question is how to design/share PQ credentials.
They may look very different. A certificate with a SLH-DSA or ML-DSA
public key could be used in MLS. But there is a bunch of uncertainty
regarding how the credential will look like.
Slides:
https://datatracker.ietf.org/meeting/119/materials/slides-119-mls-additional-credentials-00
Successful adoption call post-IETF 117, but waiting on formal adoption
post-recharter.
slides:
https://datatracker.ietf.org/meeting/119/materials/slides-119-mls-more-mls-extensions-00
Extensions for MIMI
Eric Rescorla: Not finding the motivation convincing. Why can't you do
the same thing with the application layer?
Rohan: What do we say in MIMI to the client to get this established
between providers? MIMI does not have a place to go between the provider
and client to establish it for a proprietary protocol.
Eric: Not understanding. We'll take the discussion offline.
Cullen Jennings: MIMI has lots of things that trust the providers. But
we do not trust them with information that allows them to read message.
We should not embed MLS in MIMI. What does a domain end up meaning in
the MLS context? This extension assume things not agreed upon via MIMI.
Rohan: MLS architecture assumes agreement on the domain between a client
and provider.
Cullen: Not seeing the motivation.
Rohan: Something needs to be communicated about the key package context
between providers.
Brendan McMillion: With the abstractions of MIMI, wouldn't provider A
communicate context to provider B? If there is a security consideration
about ensuring the key package cannot be forged, then this needs to be
described in the security considerations; otherwise, it could be just
communicated via the existing MIMI provider communications.
Richard Barnes: Never liked SelfRemove. It looks like allowing arbitrary
proposals in External Commits. How do we prevent this from opening up?
Rohan: The draft will say the order which you establish and check
validity. Could imagine a way that does not have a centralized DS--for
example, they could take turns.
Brendan MicMillion: Currently, the users can determine what is valid,
but this moves it to the DS. One thing in favour of SelfRemove is that
it is easier for clients outside the group.
Options sending Ratchet Tree and GroupInfo
PQ Security Extensions
Richard Barnes: Lets do it.
Sean: It is depended on some ciphersuites that are not yet finalized by
CFRG.
Eric Rescorla: ... Application logic has to be involved in order to
determine an update.
Rohan Mahy: Does MLS need to consult the application beyond just okay or
not okay for updating group context?
Richard: Not asking for WG adoption right now.
Konrad Kohbrok: Will Bob never recover from compromise?
Richard: Light clients can send an update proposal.
Not proposing for WG adoption today.
Daniel Khan Gillmor: Worried about using this for small to medium-sized
groups. For a very large group, this makes sense. Wary about using the
light mode for a small group of size (say 12) and the security risks. We
should have a size cutoff.
Richard: Yes, we need to add security considerations discussing the
tradeoffics. We would only use the light client temporarily.
Bob Moskowitz: I have a use case with very low bandwidth on the radio
spectrum. If there is low trust of clients requesting to join, this may
make it impossible to join. Could use this proposal.
Brendan McMillion: Security issue based on not seeing the whole ratchet
tree. May not trust until you receive a message from them. UI may not be
able to display level of trust between clients.
Richard: Karthik did some formal models and encourage discussion with
him about the security model.
One or more clients collaborate in "emulating" a virtual MLS client.
How to deal with application messages sent by two emulator clients at
the same time? Three potential solutions have been proposed:
Rohan Mahy: In terms of leakage, even if the group is stable and people
send multiple messages in a row, it is not a significant problem leaking
which emulator client sent it. Sending decoys could even hide things
further.
Brendan McMillion: Does each client's state grow linearly with the
application state based on the PRF?
Konrad: Not just the sending client, but also the receivng client. That
is another trade-off.
Brendan: Preventing key re-use doesn't require anything special from the
DS. If you have a strongly consistent DS, then application messages will
be ordered consistently and the user ratchet can be moved forward as
needed.
Konrad: If two clients send messages at the same time, is it still not a
problem.
Brendan: That is a race condition, but for a strongly consistent DS, the
ordering should be enforced.
Konrad: Don't we only have strong consistency on the DS for commits, not
application messages?
Daniel Khan Gillmor: Sounds like Brendan is not thinking of the DS as
part of the threat model. The DS can simply allow two clients to send
the same message with key and nonce and break it.
Brendan: The DS can intentionally not tell you that another client has
sent a message, but this will not result in nonce reuse due to the reuse
guard (four byte value XORed into the nonce). Two clients will never use
the same nonce.
DKG: Is the reuse guard invisible to everyone in the group.
Brendan: Yes, the reuse guard is secret for those not in the partition.
Solution 1 has an obligation on other members of the group to hold onto
keys. Whereas, with the reuse guard you don't need to keep these keys.
DKG: Why do we need the DS assistance?
Brendan: DS assistance helps protect against key reuse. Without it,
clients may have already deleted an encryption key and fail to decrypt.
Authors would like guidance on what direction to go.
DKG: Greatly support this work. It is a mistake that MLS is leaking the
number of clients to the rest of the group.
Brendan: To summarize list discussion. It may be possible to select more
than one of these solutions. In comparison between Solutions 2 and 3,
Solution 3 is simpler. In certain use cases, you could run out of
entropy in the reuse guard, so that you may want to go with Solution 2
in that case.
DKG: That distinction seems to conflict with the design goal of MLS.
Sean: Discussions will continue on the mailing list.