jiebi/CodeConvo huggingface dataset:
Code change:
Tree hash: The root hash of the above ratchet tree <del> Confirmed transcript hash: the zero-length octet string </del> <ins> Confirmed transcript hash: The zero-length octet string </ins> <del> Interim transcript hash: the zero-length octet string </del> <ins> Interim transcript hash: The zero-length octet string </ins> <del> Init secret: a fresh random value of size "KDF.Nh" </del> <ins> Init secret: A fresh random value of size "KDF.Nh" Extensions: Any values of the creator's choosing </ins> For each member, construct an Add proposal from the KeyPackage for that member (see add)

Related discussion:
text: It gives us better FS guarantees, because the receiver of the can delete the corresponding private key immediately after decryption, while they might have to keep the other key around for a bit until they can actually issue an update. This might also help clarify .
Ties into as well because is an example of an extension that is required and should be a field instead
NAME one concern I have is how is that field in created?
When sending a full , the participant includes a new in the (it replaces the field). It computes the signature with where: corresponds to all the fields of except (the usual thing) comes from
What about the scenario where Alice pulls down Bob's key package to add him to the group? In that case Alice can't do the conversion between formats on Bob's behalf.
Alice don't have to do the conversion, this is why either contain a (when adding someone to the group) or a (when updating your own key package).
Ah somehow I missed that part in your original post. Makes sense
I like this general direction. It solves a few things. Instead of having leaf nodes contain either a prepublished thing or a normal leaf node, how about having the prepublished thing wrap the leaf node thing? As a bonus, we get separation between the key pair used for Welcome encryption and the key pair that goes in the leaf for TreeKEM. Then when Alice adds Bob, she extracts his LeafNodeContent and sends that in the Add. That doesn't let the other members of the group verify that Alice did the right thing w.r.t. expiry, but I'm not heartbroken about that. We might also be able to remove the extensions field from the outer (KeyPackage) wrapping if we turn the extension into KeyPackage field. I expect we probably need leaf extensions, but would be open to making into a field.
Why not keep sending the KeyPackage in the Add? That wouldn't cost much and would allow everyone to validate the lifetime. Note, that the lifetime is crucial in achieving PCS for pre-published key material. If I compromise Bob and get hold of the private key material of a bunch of his KeyPackages, I can add "Bob" to any group I want as long as the Credential inside the LeafNodeContent remains valid and Bob doesn't revoke the LeafNodeContent somehow.
Code change:
Tree hash: The root hash of the above ratchet tree <del> Confirmed transcript hash: the zero-length octet string </del> <ins> Confirmed transcript hash: The zero-length octet string </ins> <del> Interim transcript hash: the zero-length octet string </del> <ins> Interim transcript hash: The zero-length octet string </ins> <del> Init secret: a fresh random value of size "KDF.Nh" </del> <ins> Init secret: A fresh random value of size "KDF.Nh" Extensions: Any values of the creator's choosing </ins> For each member, construct an Add proposal from the KeyPackage for that member (see add)

Related discussion:
text: Also, we'll have to do this if we want to enable any member to send the Welcome message as you proposed here: URL
I agree that including inside is quite clean, but something is bothering me with this approach: I'd like that the is signed by the participant occupying that leaf, to protect against cross-group attacks. In the first message of this issue I did this by including in , but in fact we don't need to store it in the leaf, we just need to include it in the . In any case, if we want to include in the signature, we need a way to differentiate between leaves that triggered a commit and the ones that are "fresh". And for that I think using a tagged-union struct is the cleanest way to do it.
It always feels a bit lazy to use an extension (and implementations have to be careful to check for their presence), but we could use a extension in the same way that we use a extension. You will find both of them only on LeafContents that were updated at least once. Another result of including GroupId in the KeyPackage is that the signature will explicitly sign the and I'm not sure if that doesn't completely destroy any deniability guarantees we can still get from MLS.
I don't think there's really a good way to get the into the leaf. Because of prepublication, it would have to be optional, but in order to prevent attacks, you need rules to decide whether it's required in a given situation. It seems like the best you can do is basically TOFU: When you first get the tree, you can't validate whether the groupid should be in a given leaf or not Once you're a member, you require that groupid is sent in Update and UpdatePath.leafkey_package I could live with a solution of that character, but given it's a bit complex, might prefer to leave it out unless we get a useful property from it. NAME - Re: Sending KeyPackage in Add - Yep, that makes sense. So you would send KeyPackage in Add, and LeafNode in Update.
I tried to worked through what would be necessary to implement this. It looks like it would require some fairly invasive changes to be made to rationalize the document's structure before making this change. But those changes should probably be made anyway.
Code change:
Tree hash: The root hash of the above ratchet tree <del> Confirmed transcript hash: the zero-length octet string </del> <ins> Confirmed transcript hash: The zero-length octet string </ins> <del> Interim transcript hash: the zero-length octet string </del> <ins> Interim transcript hash: The zero-length octet string </ins> <del> Init secret: a fresh random value of size "KDF.Nh" </del> <ins> Init secret: A fresh random value of size "KDF.Nh" Extensions: Any values of the creator's choosing </ins> For each member, construct an Add proposal from the KeyPackage for that member (see add)

Related discussion:
text: Proposal: Preparatory PR: Rationalize layout Move "Cryptograhic Objects" to before "Ratchet Trees" Update "Ratchet Tree Nodes" to define ParentNode and LeafNode structs, with LeafNode initially just equal to KeyPackage Move subsections of "Key Packages" to under "Ratchet Trees" Parent Hash Tree Hashes Update Paths Move Group State to its own top-level section Main PR: Change LeafNode to have the required content: HPKE key for TreeKEM Credential Parent hash Capabilities Extensions Signature Change KeyPackage to refer to LeafNode for internals, plus: HPKE key for Welcome Lifetime Extensions Signature Add continues to send KeyPackage Update and Commit send LeafNode instead of KeyPackage Remove and Sender refer to LeafNodeRef instead of KeyPackageRef We should probably do the preparatory PR regardless of this issue.
Discussion on working call: General agreement on the approach Should sign group_id when possible Include in TBS if we at least have a flag for pre-published / in-group Or we can store it Or we could have independent structs for pre-published / in-group leaves Do we need extensions at both levels? Capabilities / lifetime should probably be promoted to fields
Many protocols which have an extensibility mechanism have a way to indicate that understanding an extension is mandatory for certain behaviors. For MLS, this would mean having a way to require a member understand an MLS extension before it can join a group. The three extension types defined currently are: MLS ciphersuites, MLS extension types, and MLS credential types. One logical way to add mandatory extensions would be to pick one of these types (the MLS extensions type) and use the high order bit or a specific range to indicate that a member must understand and implement the extension to join a group which uses that extension. The IANA values could be changed as follows: Values from 0x8000-0xffff indicate understanding the extension is required 0x7f00 - 0x7fff Reserved for Private Use (not required) 0xff00 - 0xfff Reserved for Private Use (required) If a required ciphersuite or credential becomes necessary, a new extension type could be created to add an extension in the KeyPackage or GroupInfo which would be required and would indicate support for the mandatory ciphersuites or credentials.
Code change:
Tree hash: The root hash of the above ratchet tree <del> Confirmed transcript hash: the zero-length octet string </del> <ins> Confirmed transcript hash: The zero-length octet string </ins> <del> Interim transcript hash: the zero-length octet string </del> <ins> Interim transcript hash: The zero-length octet string </ins> <del> Init secret: a fresh random value of size "KDF.Nh" </del> <ins> Init secret: A fresh random value of size "KDF.Nh" Extensions: Any values of the creator's choosing </ins> For each member, construct an Add proposal from the KeyPackage for that member (see add)

Related discussion:
text: In order to prevent some other entity from adding an MLS client that does not support a mandatory extension, we already have the KeyPackage Client Capabilities, which lists which extensions are supported by the client.
Note that though this might seem "now or never", I don't think it really is. Consider TLS by way of analogy -- it has no mechanism for specifying that extensions are required. But if a server gets a ClientHello that is missing some extension that it requires, it can just abort the handshake. Likewise in MLS, the member adding a new joiner to the group can examine that joiner's KeyPackage to see if they support the extensions needed for the group. So I think you could implement this as a non-mandatory GroupContext extension, which would state the extensions required by the group so that all members apply the same requirements for new joiners.
While you can implement this "out-of-band", that makes it implicit rather than explicit behavior.
Discussed at 20211004 interim, liked this functionality. But, instead of IANA registry use field (or extension) in group context to indicate which extensions are required. NAME to generate PR.
Discussed with NAME and incorporated this functionality into PR
Code change:
The following example shows a case where "example.com" has a server running on port 443, with an alternate port of 8443 for QUIC. <del> 6.1.3. </del> <ins> 6.1.4. </ins> The following examples of Endpoints show common usage patterns.

Related discussion:
text: Explain the different use-cases on specifying interfaces to
There's something obvious I'm not seeing: if I want to specify a multicast or link-local address for an endpoint, why not simply specify that address? What's the use of adding the interface into it? Some addresses will inherently limit interfaces; I thought interface preference was about preferring wifi to 4G, etc.
Like, in section 6.1.1:
Multicast groups can be scoped (see RFC7346), thus, may only be available on certain interfaces or even have different meanings based on the interface. So for Interface- and Link-Local scope, specifying the interface is strictly required. For others use cases (like coping with non-unique use of RFC1918 addresses) this may also be helpful.
Why does the API have both the ability to say LocalSpecifier.WithInterface and to set interface requirements on TransportProperties? Why not just keep the latter and remove the former?
There's history here: LocalSpecifier.WithInterface predates explicitly setting the interface name in interface requirements. There might be reasons to keep this: LocalSpecifier is more likely to show up in application UI than in transport properties. Any text proposed to keep both would need to have an unambiguous way to resolve conflicts between the two. This might be a source of hard-to-debug errors.
To discuss next interim
Code change:
secure delegation.  The zone signing and secure delegation may be performed either by the Homenet Naming Authority or by the Outsourcing Infrastructure. sec-dnssec-deplyment discusses these two <del> alternatives. sec-views discusses the consequences of publishing multiple representations of the same zone also commonly designated as views.  This section provides guidance to limit the risks associated with multiple views.  sec-reverse discusses management of the reverse zone. sec-renumbering discusses how renumbering should be handled. </del> <ins> alternatives. sec-reverse discusses management of the reverse zone. sec-renumbering discusses how renumbering should be handled. </ins> Finally, sec-privacy and sec-security respectively discuss privacy and security considerations when outsourcing the Homenet Zone. <ins> The Homenet Zone is expected to host public information only.  It is not the scope of this DNS service to define local home network boundaries.  Instead, local scope information is expected to be provided to the home network using local scope naming services. mDNS RFC6762 DNS-SD RFC6763 are two examples of these services.  Currently mDNS is limited to a single link network.  However, future protocols are expected to leverage this constraint as pointed out in RFC7558. </ins> 3. Customer Premises Equipment: (CPE) is a router providing

Related discussion:
text: …ument, dealing with issue
handling different views (7.0) .... some would like to have different views, This document deals with the view that the Internet gets from the CPE(s) only.
Code change:
also send-idempotent.  This is a strict requirement.  The default is to not have this option. <del> 5.2.5. </del> <ins> 5.2.6. </ins> Type: Preference

Related discussion:
text: This closed As we have no methods on a connection object that query properties, cansend/canreceive also became connection properties. As with all the other connection properties, these are indeed a little underspecified. I want to keep it that way till we fix it for all connection properties with and
Aehm… that comes surprising – NAME why didn't you bring this up in ? Do you think this pull-request is the right place to discuss this issue? I would prefer we merge it now and make a new issue for the question whether the uni-directional connection should be more reflected in the connection. I am not particularly found on keeping it a selection property but would like to have the concept of unidirectional connections rather sooner than later. Our consensus in was that unidirectional connection should use the same abstraction for QUIC unidirectional streams, multicast sources/sinks, and half-closed connections – despite they are constructed in completely different ways. The Selection property is just for the QUIC style ones…

Aehm… that comes surprising – NAME why didn't you bring this up in ? Do you think this pull-request is the right place to discuss this issue? Happy to move the discussion back over to the issue if you like. Will continue the thread here for now though since you've got points to address below. fine, but keep open then, because adding the selection property is possibly-necessary but definitely-not-sufficient to fully address unidirectional connection semantics. good, I agree with this. then I'm confused why this PR purports to since it only addresses part of the issue...?
NAME agreed. The question (and discussion) was about support for including some support for unidirectional connections (with focus on QUIC and half-closed), but omitted details on multicast, as this has not laned yet. So indeed, this pull-requests does everything requested by , but does not fully capture the topic. I will move the open issues (Multicast support, is the Selection Property enough, find some place for more explanation of Uni/Bidi Streams) to once this PR is merged.
In Section 9 – "Setting and Querying of Connection Properties" – the properties of an established connection and path are heavily underspecified. Should be fixed along with .
I'm working on this issue within our pull request for , using the terminology as simplified there.
Code change:
also send-idempotent.  This is a strict requirement.  The default is to not have this option. <del> 5.2.5. </del> <ins> 5.2.6. </ins> Type: Preference

Related discussion:
text: For Section 9, I'm proposing the following: An application can query Connection Properties on a connection. Connection Properties include the status of the connection and whether it is possible to send and to receive data on it. (One of them might not be possible, e.g., in a unidirectional connection.) Additionally, Connection Properties include the Connection's Transport Properties. Transport Properties include Selection Properties, so the application can know which Protocol Selection Properties had been specified, and which ones are actually supported by the protocol that has been chosen. For Establishing connections (i.e., we are not done racing yet, the final protocols have not been selected yet), the application gets the Selection Properties that had been specified on the Preconnection earlier. For Established, Closing, or Closed connections (i.e., the protocols have been selected), the application learns whether the Selection Properties are actually provided by the selected protocols. For example, if the application specified earlier, "Control Checksum Coverage: Prefer", now it will get "Control checksum coverage: True", indicating that on this connection it can indeed control the checksum coverage. Transport Properties also include Protocol Properties (Generic and Specific). These Protocol Properties can still be modified by the application. Basically, Protocol Properties are the only thing that the application can still set, everything else it can only query at this point. Finally, the application can query properties of the path. Not sure how well we have to specify them, probably this part will be implementation-specific just like, e.g., the Interface Instance or Type. Does everyone agree, or is there anything to discuss here? For me this is not a big change, it's just putting what was already there in terms of . The only thing I'm wondering if whether the Protocol Selection Properties of the finally chosen protocols are still "Selection Properties", as the selection is already done. That's why they were called "Transport Features" before, but now I want less terms and they're almost the same thing...
OK - so I commented on these things before - but in these things I think I agree. I'd personally prefer to keep the features as attributes implemented in the transport (etc) and the properties as the things requested. Indeed this begs the question about what to call the resulting transport when you selected properties and now get a transport. I think still calling them (for consistency) properties seems really good to me. :-).
Code change:
also send-idempotent.  This is a strict requirement.  The default is to not have this option. <del> 5.2.5. </del> <ins> 5.2.6. </ins> Type: Preference

Related discussion:
text: As QUIC has unidirectional streams, we might want to be able to accommodate them in our transport API. Do we want to handle them fundamentally different from a half-closed connection? This should match the decisions made in .
Side note: we don't support half-closed connections to begin with. As for unidirectional streams, is this the final decision in QUIC's design, or might it change? I'd suggest postponing this until we can be sure.
NAME regarding half-closed connections: we don't have any top-level state in the connection for being half-closed. However, being able to express that a message is final in a given direction when sending allows the same functionality. As I've discussed before, we absolutely need the ability to express sending a TCP FIN, but I whole-heartedly agree it doesn't need to be a top level concept. I think this is somewhat different from half-closing, since a unidirectional stream never allows sending on one end. You could imagine that it is a connection object that returns an error if you ever try to send on it, etc. If you wanted it to look like half-closing, you could open a connection (stream), and then mark it complete in a direction immediately? But that's a bit odd.
All ok, I agree with your suggestion to fin-mark a message
I agreee with NAME regarding half-closed. My suggestion is to explicitly state that connections can be uni- or bi-directional and to add a method to query that (cansend / canrecv). This aligns nicely with final messages after which can_send becomes false. I can do a PR for that.
Thanks! I like this
Still missing unidirectional stream for multicast. – please continue discussion of multicast aspects in The connection properties (can send/receive data) are still a little under-specified - please discuss in details in – we should fix this together with .
We need unidirectional connections. You know, for multicast. And ICN. And unidirectional streaming protocols.
This is a dup of , which has more discussion
I am re-opening this ticket as only dealt with unidirectional streams in unicast context (added with PR ): Current status: The current model for unidirectional streams supports half-closed connections and QUIC style unidirectional streams so far.
Code change:
also send-idempotent.  This is a strict requirement.  The default is to not have this option. <del> 5.2.5. </del> <ins> 5.2.6. </ins> Type: Preference

Related discussion:
text: We don't know yet whether it is sufficient to have canread/canwrite property on the connection level to model unidirectional connections We don't have pre-connection methods to create multicast sessions yet
there's a selection property for this, tagged discuss, which we haven't discussed yet. I'm moving this down to the appendix as part of my restructuring in my work on
If help is still wanted here, I'm maybe up for an attempt or 2 at adding multicast support. Has there been some prior discussion I can review about rough ideas on pre-connection methods for multicast sessions, or should I just try making something up?

ok, with the caveat that we need to keep multicast as an open issueLGTM About the multicast concern: I agree that it would be good if this could function for multicast reception too, and I couldn't tell if this is suitable for multicast. I suspect that multicast support is much harder anyway - see RFC 3678... so for now, this is a good step forward IMO, and let's discuss how this relates to multicast when we see a concrete text proposal that addresses it.