Skip to content

Commit

Permalink
🔥
Browse files Browse the repository at this point in the history
  • Loading branch information
@expede
expede committed Jul 12, 2023
1 parent d04f74c commit 688d021
Showing 1 changed file with 21 additions and 11 deletions.
32 changes: 21 additions & 11 deletions README.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand All @@ -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

Expand Down Expand Up @@ -195,7 +193,7 @@ If no capabilties are required, the `caps` field MUST be set to an empty map (`{
"caps": {
"mailto:[email protected]": {
"msg/send": [
{"to": ".*@example.com"}
{"to": "/.*@example.com/"}
]
},
"dns:example.com": {
Expand Down Expand Up @@ -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**
Expand All @@ -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

Expand All @@ -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.

Expand Down Expand Up @@ -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?

<!-- External Links -->

[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
Expand All @@ -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
Expand All @@ -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

<!-- Internal Links -->

[ECDH Input]: #1431-ecdh-input

0 comments on commit 688d021

Please sign in to comment.