From 688d021fc41e3b8a14474adfc78df1ea7415a713 Mon Sep 17 00:00:00 2001 From: Brooklyn Zelenka Date: Wed, 12 Jul 2023 12:29:16 -0700 Subject: [PATCH] :fire: --- README.md | 32 +++++++++++++++++++++----------- 1 file changed, 21 insertions(+), 11 deletions(-) diff --git a/README.md b/README.md index 9189a6f..caddea7 100644 --- a/README.md +++ b/README.md @@ -66,13 +66,13 @@ All symmetric keys SHOULD be non-extractable where possible. ### 2.3.2 Symmetric Keys -All symmetric encryption in the pre-MLS AWAKE handshake MUST use [XChaCha-Poly1305]. These keys MUST be generated by the [KDF](#143-diffie-hellman-key-derivation), and SHOULD be non-extractable where possible. +All symmetric encryption in the pre-MLS AWAKE handshake MUST use [XChaCha-Poly1305]. These keys MUST be generated by the [AWAKE KDF], and SHOULD be non-extractable where possible. Each encrypted payload MUST include a unique 24-byte [initialization vector][IV]. ### 2.3.3 Diffie-Hellman Key Derivation -AWAKE MUST use [HKDF](https://datatracker.ietf.org/doc/html/rfc5869) to derive keys. Key derivation in the AWAKE handshake MUST use the following algorithms: +AWAKE MUST use [HKDF] to derive keys. Key derivation in the AWAKE handshake MUST use the following algorithms: FIXME @@ -81,9 +81,7 @@ FIXME - - -The [ECDH](https://en.wikipedia.org/wiki/Elliptic-curve_Diffie%E2%80%93Hellman) secret MUST be generated using [X25519]. Non-extractable keys SHOULD be used where available. The sender MUST rotate their public key on every send. +The shared secret MUST be generated using [X25519]. Non-extractable keys SHOULD be used where available. The sender MUST rotate their public key on every send. ## 2.4 Messagaging Layer Security @@ -195,7 +193,7 @@ If no capabilties are required, the `caps` field MUST be set to an empty map (`{ "caps": { "mailto:me@example.com": { "msg/send": [ - {"to": ".*@example.com"} + {"to": "/.*@example.com/"} ] }, "dns:example.com": { @@ -329,6 +327,12 @@ At this stage, the Provider has been validated, but the Requestor is still untru The Requestor now MUST provide their actual DID over the secure channel, and MUST prove that they are a trusted party rather than a PITM, eavesdropper, or phisher. This is accomplished in the [MLS Certificate] step. +> In order to ensure that MLS provides meaningful authentication it is important that each member is able to authenticate some identity information for each other member. Identity information is encoded in Credentials, so this property is provided by ensuring that members use compatible credential types. +> +> The types of credential that may be used in a group is restricted to what all members of the group support, as specified by the capabilities field of each LeafNode in the ratchet tree. An application can introduce new credential types by choosing an unallocated identifier from the registry in Section 17.5 and indicating support for the credential type in published LeafNodes, whether in Update proposals to existing groups or KeyPackages that are added to new groups. Once all members in a group indicate support for the credential type, members can start using LeafNodes with the new credential. Application may enforce that certain credential types always remain supported by adding a required_capabilities extension to the group's GroupContext, which would prevent any member from being added to the group that doesn't support them. +> +> — [MLS Protocol Specification], [13.3. Credential Extensibility] + ## 5.3.1 Requestor Challenge **NOTE: The Requestor is not yet trusted at this step, and MUST be treated as a possible impersonator or PITM** @@ -342,9 +346,9 @@ sequenceDiagram Requestor ->> Provider: MLS Handshake (UCAN or Challenge) ``` -The Requestor MUST provide the proof of authorization set by the Provider payload in [§3.3.2](#332-validation-ucan). The RECOMMENDED authorization methods are PIN validation (`pin`) and UCAN (`ucan`). Note that if the Requestor does not know how to respond to fulfill an authorization method, the AWAKE connection MUST fail with an [`unknown-challenge` message](#62-unknown-challenge-error). +The Requestor MUST provide the proof of authorization set by the Provider payload in [§3.3.2]. The RECOMMENDED authorization methods are PIN validation (`pin`) and UCAN (`ucan`). -When using PIN validation, it is RECOMMENDED that the handshake fail after a maximum number of failed validation attempts, or the attempts be rate limited with exponential backoff. +It is RECOMMENDED that the handshake fail after a maximum number of failed validation attempts, or the attempts be rate limited with exponential backoff. #### 5.3.1.1 Out-of-Band PIN Challenge @@ -366,7 +370,7 @@ The PIN values MUST be within the UTF-8 character set. The PIN MUST be included #### 5.3.1.2 Direct UCAN Challenge -If UCAN auth is required by the Provider, the Requestor MUST provide a UCAN. This is the same strategy as the one used by the Provider in [§3.3](#33-responder-es tablishes-point-to-point-session): the UCAN MUST be encrypted with the session key and the IV from the enclosing payload, MUST be given in a raw format, and MUST be inline (without a JSON object wrapper or similar). +If UCAN auth is required by the Provider, the Requestor MUST provide a UCAN. This is the same strategy as the one used by the Provider in [§3.3]: the UCAN MUST be encrypted with the session key and the IV from the enclosing payload, MUST be given in a raw format, and MUST be inline (without a JSON object wrapper or similar). The UCAN MUST be issued (`iss`) by the Requestor's DID (not the temporary DID), and its audience (`aud`) MUST be the Provider's DID. The `att` field MUST be set to an empty array (i.e. it MUST NOT delegate any capabilities). The `prf` array MUST fulfill the capabilities set by the Provider. @@ -401,8 +405,11 @@ This is absolutely an option! However, it would require implementing a special c ## 7.2 Why not use more established cryptography, such as P-256 or RSA? +## 7.3 Why HKDF instead of the BLAKE3 key derivation function? + +[13.3. Credential Extensibility]: https://messaginglayersecurity.rocks/mls-protocol/draft-ietf-mls-protocol.html#section-13.3 [AKE]: https://en.wikipedia.org/wiki/Authenticated_Key_Exchange [Base64]: https://datatracker.ietf.org/doc/html/rfc4648 [Bluesky]: https://blueskyweb.xyz @@ -412,6 +419,9 @@ This is absolutely an option! However, it would require implementing a special c [Double Ratchet]: https://signal.org/docs/specifications/doubleratchet/ [Elliptic Curve Diffie-Hellman]: https://en.wikipedia.org/wiki/Elliptic-curve_Diffie%E2%80%93Hellman [Fission]: https://fission.codes +[HKDF]: https://datatracker.ietf.org/doc/html/rfc5869 +[IV]: https://en.wikipedia.org/wiki/Initialization_vector +[MLS Protocol Specification]: https://messaginglayersecurity.rocks/mls-protocol/draft-ietf-mls-protocol.html [MLS]: https://messaginglayersecurity.rocks/ [Quinn Wilton]: https://github.com/QuinnWilton [RFC 2119]: https://datatracker.ietf.org/doc/html/rfc2119 @@ -421,12 +431,12 @@ This is absolutely an option! However, it would require implementing a special c [WireGuard]: https://www.wireguard.com/ [X25519]: https://cryptography.io/en/latest/hazmat/primitives/asymmetric/x25519/ [XChaCha-Poly1305]: https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-xchacha -[`did:key`]: https://w3c-ccg.github.io/did-method-key/#ed25519-x25519 -[IV]: https://en.wikipedia.org/wiki/Initialization_vector [ZTA]: https://en.wikipedia.org/wiki/Zero_trust_security_model +[`did:key`]: https://w3c-ccg.github.io/did-method-key/#ed25519-x25519 [local-first]: https://www.inkandswitch.com/local-first/ [mTLS]: https://datatracker.ietf.org/doc/html/rfc8705 [mutual authentication]: https://en.wikipedia.org/wiki/Mutual_authentication + [ECDH Input]: #1431-ecdh-input