Revive draft #2
Revive draft #2
Conversation
draft-ietf-mls-federation.md
Outdated
| strict requirement, the MLS protocol does not have an inherent dependency on one | ||
| single entity and can instead be used between multiple entities. | ||
|
|
||
| This document describes the minimum changes needed to allow different MLS |
There was a problem hiding this comment.
Are there really any "changes" required? This could be interpreted as the protocol spec having to be changed before federation is possible.
draft-ietf-mls-federation.md
Outdated
| document are to be interpreted as described in BCP 14 {{!RFC2119}} {{!RFC8174}} | ||
| when, and only when, they appear in all capitals, as shown here. | ||
|
|
||
| Client: |
There was a problem hiding this comment.
Aren't Client and KeyPackage already defined in the architecture doc and MLS spec respectively? I don't quite see how this adds anything to the definitions in the other documents. If anything it might cause confusion.
draft-ietf-mls-federation.md
Outdated
|
|
||
| Identity Key: | ||
| : A long-lived signing key pair used to authenticate the sender of a | ||
| message. |
There was a problem hiding this comment.
The "Identity Key" definition seems to deviate from the main spec. Is this meant to be an assumption about the AS in the context of federation?
draft-ietf-mls-federation.md
Outdated
| One possible environment is to have different client implementations operated by | ||
| the same delivery service, which will look like the diagram above, another | ||
| environment is to have different or same clients operated By different delivery | ||
| services: |
There was a problem hiding this comment.
Introducing these two different "architectures" seems a bit brief. This section posits the possibility that one could have two different DS in a given group, but there doesn't seem to be a point. As a reader, I'd wonder maybe how this could work, or what considerations or additional assumptions one would have to make.
draft-ietf-mls-federation.md
Outdated
|
|
||
| One Delivery Service MUST be responsible for handshake message ordering at any given point in time, since TreeKEM requires handshake messages to have a total order. It MUST be clear to all clients and Delivery Services of the group which Delivery Service is responsible. The protocol between different delivery services is out of the scope of this document. | ||
| In a federated environment, the different members of a group might use different | ||
| Delivery Services. Each client SHOULD only connect to its respective Deliver |
There was a problem hiding this comment.
Do I understand correctly, that this is an informative document? If so, maybe it would make sense to add some reasoning here, why clients should indeed do this. Alternatively, there could be a few sentences in the beginning of the "Functional Requirements" section sketching the rough federation approach this document is going for.
draft-ietf-mls-federation.md
Outdated
| messages. | ||
|
|
||
| One Delivery Service MUST be responsible for handshake message ordering at any | ||
| given point in time, since TreeKEM requires handshake messages to have a total |
There was a problem hiding this comment.
I don't think TreeKEM is defined in the MLS spec.
draft-ietf-mls-federation.md
Outdated
| Service, which in turn will connect to other Delivery Services to relay | ||
| messages. | ||
|
|
||
| One Delivery Service MUST be responsible for handshake message ordering at any |
There was a problem hiding this comment.
| One Delivery Service MUST be responsible for handshake message ordering at any | |
| One Delivery Service MUST be responsible for handshake message ordering in a given group at any |
draft-ietf-mls-federation.md
Outdated
|
|
||
| In a federated environment, version & ciphersuite negotiation is more critical, | ||
| to avoid forcing a downgrade attack by malicious third party Delivery Services. | ||
| The negotiation can be done at the KeyPackage level. |
There was a problem hiding this comment.
It would be nice to go into a bit more detail here in terms of what such an attack could look like.
| @@ -238,58 +212,15 @@ One Delivery Service MUST be responsible for handshake message ordering at any g | |||
|
|
|||
| ~~~~ | |||
|
|
|||
| OPEN QUESTION: How server assist could be used with multiple servers? how the server state is shared and synced ? | |||
|
|
|||
| ## Authentication Service | |||
There was a problem hiding this comment.
I would imagine that agreeing about certain aspects of the AS is crucial in the context of federation. We don't have to go into a lot of detail here, but we should at least note that there has to be some shared assumptions about how the AS works.
Co-authored-by: raphaelrobert <raphaelrobert@users.noreply.github.com>
Co-authored-by: raphaelrobert <raphaelrobert@users.noreply.github.com>
Notes on the AS in a federated setting
| handshake messages of a specific group at any given time in order to enforce the | ||
| total ordering of handshake messages required by the MLS protocol. | ||
|
|
||
| Depending on the functional requirements (such high availability and |
There was a problem hiding this comment.
| Depending on the functional requirements (such high availability and | |
| Depending on the functional requirements (such as high availability and |
No description provided.