Bring back more ciphersuites #279

raphaelrobert · 2019-12-28T11:06:55Z

No description provided.

Bren2010

The file no longer compiles, not sure why

draft-ietf-mls-protocol.md

bifurcation · 2019-12-31T23:14:26Z

draft-ietf-mls-protocol.md

+| Component | Contents |
+|:----------|:---------|
+| MLS       | The string "MLS" followed by the major and minor version, e.g. "MLS10" |
+| LVL       | The security level |


This doesn't seem all that useful, I would drop it.

The idea is to give you a rough idea of the overall security level for informational purposes. Maybe @beurdouche can elaborate more on that.

draft-ietf-mls-protocol.md

bifurcation · 2019-12-31T23:14:26Z

draft-ietf-mls-protocol.md

-
-* Hash function: SHA-256
-* AEAD: AES-128-GCM
+The ciphersuites are defined in section {{MLS Ciphersuites}}.


I think you need a bit more description here, just to say what a ciphersuite indicates, namely:

Parameters for an instance of HPKE

A KDF to be used

As a consequence, a Derive-Key-Pair function, as defined below.

Also, does {{MLS Ciphersuites}} actually work? Might need to be {{mls-ciphersuites}}.

That's why I wanted to leave "HPKE" in the name of the ciphersuite

I guess that should then go in line 809

That's what we have in the "Diffie-Hellmann groups section"

Regarding the notation for hyperlinks, I'll take your word for it

I fixed this in mine. The anchor is {#anchor} and then you link in text with {{anchor}}.

bifurcation · 2019-12-31T23:14:26Z

draft-ietf-mls-protocol.md


-When HPKE is used with this ciphersuite, it uses the following
-algorithms:
+### Notes on Diffie-Hellman groups


This extra section heading doesn't seem necessary.

I blew it away in mine.

bifurcation · 2019-12-31T23:14:26Z

draft-ietf-mls-protocol.md

-* Hash function: SHA-256
-* AEAD: AES-128-GCM
+Given an octet string X, the private key produced by the
+Derive-Key-Pair operation is SHA-512(X) truncated to 448 bits (Recall that any 56-octet


Should we use HKDF instead of SHA directly? In other words, make node secrets variable-length, where the length is determined by the KEM in use.

P256, X25519: 32 bytes

X448: 56 bytes

P521: 66 bytes

As a bonus, that would save a couple of hash invocations.

Unless there is a specific reasons not to do it (cc @beurdouche), I think it would be great to harmonise this. Having different hash algorithms in here makes no sense to me if it can be avoided.

bifurcation · 2020-01-03T16:00:47Z

It seems like we have a few separable issues here:

Whether we require a single signature scheme for the whole group
Whether signature schemes are included in the ciphersuite
Whether we have an MTI ciphersuite / signature algorithm
What new ciphersuites should be defined, and what algorithms should go in them

Let's discuss this at the interim and maybe break this PR into a few bits

SHA384 -> SHA512

bifurcation

This seems to accurately reflect the consensus we had at the last interim, and there's nothing I can't live with otherwise.

I will probably file a follow-up to convert the Derive-Key-Pair operations to use HKDF directly, as discussed, avoiding the need for intermediate node_secret values or truncation of SHA-512.

Bren2010

There are some items missing that I believe we agreed on at the last in-person interim:

It's not clear from reading the PR that the signature scheme is now fixed per-group.
- Need to verify that CIKs correspond to current suite and express support for all algorithms currently used.
Recommendation that we be conservative when adding new suites in the future.
Justification for why the current suites are minimal.

seanturner · 2020-02-13T02:37:17Z

Note that specification required registries imply that there is a designated expert pool. I will add some text to create one. The text is very similar to the TLS DE pool text from RFC8447 with some tweaks that, hopefully, address the misunderstandings uncovered during non-standards track registry requests.

Note the process is: (assuming that the IESG eventually approves this draft) When the IESG approves this draft, the responsible AD assigns some DEs (like 2-3 suggested by the WG chairs). These DEs are in charge of all registrations regardless of whether the draft comes from the WG or elsewhere as all requests go to the MLS DEs mailing list.

Bren2010 · 2020-02-18T21:38:20Z

draft-ietf-mls-protocol.md

-    X25519_SHA256_AES128GCM(0x0001),
-    (0xFFFF)
-} CipherSuite;
+The signature algorithm specified in the ciphersuite is the mandatory algorithm to be used for the signatutes in MLSPlaintext and the tree signatures. It can be different from the signature algorithm specified in credential fielf of ClientInitKeys.


Please wrap this at 80-ish chars

"field"

Can it really be different?

Bren2010 · 2020-02-18T21:38:20Z

draft-ietf-mls-protocol.md

-Derive-Key-Pair operation is SHA-256(X).  (Recall that any 32-octet
-string is a valid Curve25519 private key.)  The corresponding public
+Derive-Key-Pair operation is SHA-256(X) (Recall that any 32-octet
+string is a valid X25519 private key). The corresponding public


The punctuation was correct before
Alternatively, lower-case r in "Recall"

Bren2010 · 2020-02-18T21:38:20Z

draft-ietf-mls-protocol.md

+   CipherSuite MLS_LVL_KEM_AEAD_HASH_SIG = VALUE;
+~~~
+
+Where VALUE is a is represented as two 8bit octets:


VALUE is represented
8-bit

Bren2010 · 2020-02-18T21:38:20Z

draft-ietf-mls-protocol.md

+| KEM       | The KEM algorithm used for HPKE in TreeKEM group operations |
+| AEAD      | The AEAD algorithm used for HPKE and message protection |
+| HASH      | The hash algorithm used for HPKE and the MLS KDF |
+| SIG       | The Signature algorithm used for message authentication |


lower-case s in "Signature"

Bren2010 · 2020-02-18T21:38:20Z

draft-ietf-mls-protocol.md

-The initial contents for this registry are as follows:
+The mandatory-to-implement ciphersuite for MLS 1.0 is
+`MLS10\_128\_HPKE25519\_AES128GCM\_SHA256\_Ed25519` which is using
+Curve25519, HKDF over SHA2-256 and AES-128-GCM for HPKE,


HKDF over SHA-256, AES-128-GCM for HPKE,

Bren2010 · 2020-02-18T21:38:20Z

draft-ietf-mls-protocol.md

+`MLS10\_128\_HPKE25519\_AES128GCM\_SHA256\_Ed25519` which is using
+Curve25519, HKDF over SHA2-256 and AES-128-GCM for HPKE,
+and AES-128-GCM with Ed25519 for symmetric encryption and
+signatures.


"message encryption and authentication"

DE-related text

Bring back more ciphersuites

7ac6156

raphaelrobert mentioned this pull request Dec 28, 2019

Review of sections 1-6. #278

Closed

beurdouche added editorial enhancement ready for review (by editors) labels Dec 28, 2019

Bren2010 reviewed Dec 28, 2019

View changes

draft-ietf-mls-protocol.md Show resolved Hide resolved

draft-ietf-mls-protocol.md Show resolved Hide resolved

draft-ietf-mls-protocol.md Outdated Show resolved Hide resolved

draft-ietf-mls-protocol.md Show resolved Hide resolved

draft-ietf-mls-protocol.md Outdated Show resolved Hide resolved

Addressing Brendan's comments

5f69d5f

weekly-digest bot mentioned this pull request Dec 29, 2019

Weekly Digest (22 December, 2019 - 29 December, 2019) #280

Closed

bifurcation requested changes Dec 31, 2019

View changes

weekly-digest bot mentioned this pull request Jan 5, 2020

Weekly Digest (29 December, 2019 - 5 January, 2020) #284

Closed

raphaelrobert and others added 3 commits Jan 20, 2020

Correcting ciphersuite hash after interim discussion

bb89ab8

SHA384 -> SHA512

More from the interim

1d59c9c

Corrected hyperlink

8f27146

bifurcation approved these changes Feb 4, 2020

View changes

bifurcation added today! (?) and removed editorial ready for review (by editors) labels Feb 4, 2020

Bren2010 reviewed Feb 5, 2020

View changes

bifurcation added ready to merge and removed today! (?) labels Feb 6, 2020

bifurcation mentioned this pull request Feb 6, 2020

Use HKDF to derive key pairs #304

Merged

raphaelrobert added 2 commits Feb 12, 2020

Align with TLS ciphersuites

75746b1

Address Brendan's comments

6387082

DE-related text

6161f17

Bren2010 reviewed Feb 18, 2020

View changes

seanturner and others added 2 commits Feb 19, 2020

addressing comments

5a5862a

Merge pull request #307 from seanturner/raphael_ciphersuites

0606ce7

DE-related text

bifurcation merged commit 74380c5 into master Mar 5, 2020
0 of 5 checks passed

bifurcation mentioned this pull request Mar 5, 2020

Clarify signature algorithm requirements #313

Merged

raphaelrobert deleted the raphael_ciphersuites branch Mar 25, 2020

mlswg / mls-protocol Public

Bring back more ciphersuites #279

Bring back more ciphersuites #279

raphaelrobert commented Dec 28, 2019

Bren2010 left a comment

bifurcation Dec 31, 2019

raphaelrobert Jan 2, 2020

bifurcation Dec 31, 2019

bifurcation Dec 31, 2019

raphaelrobert Jan 2, 2020

seanturner Feb 13, 2020

bifurcation Dec 31, 2019

seanturner Feb 13, 2020

bifurcation Dec 31, 2019

raphaelrobert Jan 2, 2020

bifurcation commented Jan 3, 2020

bifurcation left a comment

Bren2010 left a comment

seanturner commented Feb 13, 2020

Bren2010 Feb 18, 2020

Bren2010 Feb 18, 2020

Bren2010 Feb 18, 2020

Bren2010 Feb 18, 2020

Bren2010 Feb 18, 2020

Bren2010 Feb 18, 2020

mlswg / mls-protocol Public

Bring back more ciphersuites #279

Bring back more ciphersuites #279

Conversation

raphaelrobert commented Dec 28, 2019

Bren2010 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bifurcation commented Jan 3, 2020

bifurcation left a comment

Bren2010 left a comment

seanturner commented Feb 13, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment