7.  The proposal relies on identifying and resolving any mDNS-based ICE candidates as part of adding/processing a remote candidate.  ICESDP section 4.1 could be updated to explicitly allow mDNS names in the

PR for
IANA Considerations A. Must specify if IANA has to create a new registry or modify rules for an existing registry. B. Must specify if the document requires IANA to assign or update values in an IANA registry before RFC publication. C. See "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC5226] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.) and in some cases also "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers" [RFC2780] (Bradner, S. and V. Paxson, “IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers,” March 2000.) [RFC5237] (Arkko, J. and S. Bradner, “IANA Allocation Guidelines for the Protocol Field,” February 2008.). In some case "Assigning Experimental and Testing Numbers Considered Useful" [RFC3692] (Narten, T., “Assigning Experimental and Testing Numbers Considered Useful,” January 2004.) may help as well. D. If there is no action for IANA, the section should say that, e.g., including something like "This document has no actions for IANA."
Good catch. Do you want to take a shot at this? JSEP says
Not blocking for today's doc, to be clear.
Fixed by

7. <ins> This document requires no actions from IANA. 8. </ins> The proposal relies on identifying and resolving any mDNS-based ICE candidates as part of adding/processing a remote candidate.  ICESDP section 4.1 could be updated to explicitly allow mDNS names in the


a context that has a different origin than the top-level browsing context), or a private browsing context.  7. 7.1.

Original text: I'm not sure this provides an actual new fingerprinting surface - assuming the interface is in fact exposed to the outside world, a srflx candidate will also be generated for each mDNS candidate - and in the mode we are most concerned about, Mode 2, there will either be 1 or 2 mDNS candidates.
If we decide that this draft only applies to mode 2 or default routes, I agree that there is no fingerprinting surface. However, that assumption hasn't been called out anywhere in this doc AFAIK.
We still get a srflx and TURN candidate for each interface though.
Ok, good point. I agree, we should remove that paragraph. I'll create a PR
If an interface cannot connect to a STUN server, there will be no srflx candidate. I don’t think we can assume that such interface will also not support multicast.
Right, as noted in the OP, but this seems like an edge case.
I think it is better to mention an issue even though this is an edge case. Something like: If there are multiple host candidates with different IP addresses, IPv4 and/or IPv6, each results in a separate mDNS hostname candidate. The number of mDNS hostname candidates might provide a fingerprinting dimension. This is in particular the case for network interfaces whose existence are not exposed through other means like provided STUN servers. No new information is provided when exposing default route candidates.
Filed URL to follow up on that.
Approved with minor suggestions

a context that has a different origin than the top-level browsing context), or a private browsing context. <ins> 6.5. Even when local IP addresses are not exposed, the number of mDNS hostname candidates can still provide a fingerprinting dimension. This is in particular the case for network interfaces with limited connectivity that will not generate server-reflexive or relay candidates. The more mDNS names an endpoint exposes through mDNS hostname candidates, the higher the fingerprinting risk.  One countermeasure is to limit this number to a small value. Note that no additional fingerprinting risk is introduced when restricting mDNS hostname candidates to default route only. </ins> 7. 7.1.


addresses has privacy implications.  This document describes a way to share local IP addresses with other clients while preserving client privacy.  This is achieved by obfuscating IP addresses with <del> dynamically generated Multicast DNS (mDNS) RFC6762 names. </del>  1. not be supported. This document proposes an overall solution to this problem by <del> registering ephemeral mDNS names for each local private IP address, and then providing those names, rather than the IP addresses, to the web application when it gathers ICE candidates.  WebRTC implementations resolve these names to IP addresses and perform ICE processing as usual, but the actual IP addresses are not exposed to the web application. </del>  2.

From the 'nits' link on top of the IETF submitted version. ** The abstract seems to contain references ([RFC6762]), which it shouldn't. Please replace those with straight textual mentions of the documents in question.
Probably can just move the ref to the intro section.
URL
LGTM

addresses has privacy implications.  This document describes a way to share local IP addresses with other clients while preserving client privacy.  This is achieved by obfuscating IP addresses with  <ins> dynamically generated Multicast DNS (mDNS) names. </ins> 1. not be supported. This document proposes an overall solution to this problem by  <ins> registering ephemeral mDNS RFC6762 names for each local private IP address, and then providing those names, rather than the IP addresses, to the web application when it gathers ICE candidates. WebRTC implementations resolve these names to IP addresses and perform ICE processing as usual, but the actual IP addresses are not exposed to the web application. </ins> 2.


4.  In this example, mDNS candidates are exchanged between peers and resolved to obtain the corresponding IP addresses. mDNS resolution for name N2 does not complete until after the STUN checks are received. <del> 5. </del>  The goal of this mechanism is to keep knowledge of private host IP addresses within the ICE agent while continuing to allow the to prevent these IP addresses from being exposed to web applications through other means. <del> 5.1. </del>  Statistics related to ICE candidates that are accessible to the web application MUST NOT contain the IP address of a local or remote mDNS where the signaled candidate is discarded as redundant according to Section 5.1.3 of RFC8445. <del> 5.2. </del>  When sending data to a TURN RFC5766 server, the sending client tells the server the destination IP and port for the data.  This means that they will be unreachable from the TURN server, and as noted above, the reverse path will continue to work normally. <del> 5.3. </del>  It is important that use of registered mDNS hostnames is limited in time and/or scope.  Indefinitely reusing the same mDNS hostname designed to hide.  The use of registered mDNS hostnames SHOULD be scoped by origin, and SHOULD have the lifetime of the page. <del> 5.4. </del>  As noted in IPHandling, privacy may be breached if a web application running in two browsing contexts can determine whether it is running a context that has a different origin than the top-level browsing context), or a private browsing context. <del> 6. </del>  <del> 6.1. </del>  The implementation of this proposal requires the mDNS querying capability of the browser for registering mDNS names or adding remote queries, announcement responses, resolution queries, and goodbye responses associated with mDNS. <del> 6.2. </del>  If the optional probing queries are implemented for the name registration, a malicious endpoint in the local network, which is generic threat, and requires dedicated protocol suites to mitigate, which is beyond the scope of this proposal. <del> 6.3. </del>  A malicious endpoint in the local network may also record other endpoints who are registering, unregistering, and resolving mDNS As above, mitigation of this threat is beyond the scope of this proposal. <del> 7. </del>  This document requires no actions from IANA. <del> 8. </del>  The proposal relies on identifying and resolving any mDNS-based ICE candidates as part of adding/processing a remote candidate.  ICESDP

Added new section on latency, as requested by NAME PTAL - will plan to merge at EOD if there are no outstanding comments.
Include experimental results, if we have them
LGTM

4. <ins> 4.1. With typical ICE, endpoints on the same network will usually be able to establish a direct connection between their local IP addresses. When using the mDNS technique, a direct connection is still possible, but only if at least one side can properly resolve the provided mDNS candidates.  This may not be possible in all scenarios. First, some networks may entirely disable mDNS.  Second, mDNS queries have limited scope.  On large networks, this may mean that an mDNS name cannot be resolved if the remote endpoint is too many segments away. When mDNS fails, ICE will attempt to fall back to either NAT hairpin, if supported, or TURN relay, if not.  As noted in IPHandling, this may result in increased media latency and reduced connectivity/ increased cost (depending on whether the application chooses to use TURN). The exact impact of this technique is being researched experimentally and will be provided before publication of this document. 4.2. As noted in {#principle}, ICE agents using the mDNS technique are responsible for registering and resolving mDNS names as part of the ICE process.  These steps may delay establishment of a direct peer- to-peer connection, compared to when raw local IP addresses are used. Given that these mDNS registrations and queries are typically occurring on a local network, any associated delays should be small. Also, as noted in {#gathering}, pre-registration can be employed to eliminate gathering delays entirely. 4.3. Note that backward compatibility does not present a significant issue for the mDNS technique.  When an endpoint that supports mDNS communicates with an endpoint that does not, the legacy endpoint will still provide its local IP addresses, and accordingly a direct connection can still be attempted, even though the legacy endpoint cannot resolve the mDNS names provided by the new endpoint.  In the event the legacy endpoint attempts to resolve mDNS names using Unicast DNS, this may cause ICE to take somewhat longer to fully complete, but should not have any effect on connectivity or connection setup time. 5. </ins> In this example, mDNS candidates are exchanged between peers and resolved to obtain the corresponding IP addresses. mDNS resolution for name N2 does not complete until after the STUN checks are received.  <ins> 6. </ins> The goal of this mechanism is to keep knowledge of private host IP addresses within the ICE agent while continuing to allow the to prevent these IP addresses from being exposed to web applications through other means.  <ins> 6.1. </ins> Statistics related to ICE candidates that are accessible to the web application MUST NOT contain the IP address of a local or remote mDNS where the signaled candidate is discarded as redundant according to Section 5.1.3 of RFC8445.  <ins> 6.2. </ins> When sending data to a TURN RFC5766 server, the sending client tells the server the destination IP and port for the data.  This means that they will be unreachable from the TURN server, and as noted above, the reverse path will continue to work normally.  <ins> 6.3. </ins> It is important that use of registered mDNS hostnames is limited in time and/or scope.  Indefinitely reusing the same mDNS hostname designed to hide.  The use of registered mDNS hostnames SHOULD be scoped by origin, and SHOULD have the lifetime of the page.  <ins> 6.4. </ins> As noted in IPHandling, privacy may be breached if a web application running in two browsing contexts can determine whether it is running a context that has a different origin than the top-level browsing context), or a private browsing context.  <ins> 7. </ins>  <ins> 7.1. </ins> The implementation of this proposal requires the mDNS querying capability of the browser for registering mDNS names or adding remote queries, announcement responses, resolution queries, and goodbye responses associated with mDNS.  <ins> 7.2. </ins> If the optional probing queries are implemented for the name registration, a malicious endpoint in the local network, which is generic threat, and requires dedicated protocol suites to mitigate, which is beyond the scope of this proposal.  <ins> 7.3. </ins> A malicious endpoint in the local network may also record other endpoints who are registering, unregistering, and resolving mDNS As above, mitigation of this threat is beyond the scope of this proposal.  <ins> 8. </ins> This document requires no actions from IANA.  <ins> 9. </ins> The proposal relies on identifying and resolving any mDNS-based ICE candidates as part of adding/processing a remote candidate.  ICESDP


IPv6 address resolved, if one exists, or the first IPv4 address, if not.  4. 4.1. As above, mitigation of this threat is beyond the scope of this proposal.  8. This document requires no actions from IANA.

As pointed by NAME one can stuff ICE candidates with mDNS names that are not UUID. This may ease exposing some devices (URL) to some unsolicited mDNS/STUN traffic.
To be noted that a web application can currently synthesize candidates with well-known IP addresses/address ranges. Allowing non UUID mDNS resolution might ease such attacks. We should evaluate whether this is fine as is or not. One possibility would be to mandate mDNS resolution for UUID-based names only.
I am inclining towards mandating mDNS resolution for UUID-base names only. My rationale is the technique proposed is essentially intended to expose no handle to applications to tweak. A general name + .local could fall back to the path of FQDN ICE supported by unicast DNS currently, with better security scrutiny.
Implementations might use the same code path for mDNS and unicast DNS, so I am not sure this will be easy to do this distinction in practice. I would do the distinction between applications that trust the source of ICE candidates (in which case any mDNS is fine) from cases where there is no trust (web browsers typically). In the latter case, I would go with a SHOULD statement.
Started PR URL
Fixed via
Approved with a few editorial comments

IPv6 address resolved, if one exists, or the first IPv4 address, if not. <ins> An ICE agent MAY add additional restrictions regarding the ICE candidates it will resolve using mDNS, as this mechanism allows attackers to send ICE traffic to devices with well-known mDNS names. </ins> 4. 4.1. As above, mitigation of this threat is beyond the scope of this proposal. <ins> 7.4. As noted in Section 4.2 of RTCWebSecurity, an attacker may use ICE as a way to send unsolicited network traffic to specific endpoints. While this is not specific to mDNS hostname candidates, this technique makes it easier to target devices with well-known mDNS names. As noted in processing, ICE agents may decide to not resolve mDNS names, for example, if these names are not in the format defined by gathering. </ins> 8. This document requires no actions from IANA.


8. This document requires no actions from IANA. <del> 9. The proposal relies on identifying and resolving any mDNS-based ICE candidates as part of adding/processing a remote candidate.  ICESDP section 4.1 could be updated to explicitly allow mDNS names in the connection-address field. The proposal relies on adding the ability to register mDNS names at ICE gathering time.  This could be described in ICESDP and/or WebRTCSpec. The proposal allows updating IPHandling so that mode 2 is not the mode used by default when user consent is not required.  Instead, the default mode could be defined as mode 3 with mDNS-based ICE candidates. </del>

This work is already in motion in the desired documents.
LGTM
IOW, should this document define the new modes, or just how mDNS should be used to hide local IP addresses? If the latter, we would then also need to write a ip-handling v2 that defined the new modes, and pointed at this doc for details on how the technique should work.
From last meeting discussions, the plan was to define the new modes in this document and add a note in the ip-handling document that new modes might be defined with an informative reference to this document. I think defining the new modes in this document will also ease the authoring work and the review from the RTCWeb WG. In the long run, I think an ip-handling v2 might be a better place for the definition of the modes. For instance the guidelines around a default mode does belong in the ip-handling document, not the mdns-ice-candidate document.
OK. This particular document may be in the wrong WG then, but we can leave those details for later.
Leaving this open to cull the Specification Requirements section once it has been fully incorporated into ip-mdns-ext.


Abstract This document registers the following media types used in APIs on the <del> IANA Media Types registry: text/yaml, application/yaml, application/ </del>  openapi+json, and application/openapi+yaml. Note to Readers To increase interoperability when processing API specifications and leverage content negotiation mechanisms when exchanging OpenAPI Specification resources this specification register the following <del> media-types: "text/yaml", "application/yaml", "application/ openapi+json" and "application/openapi+yaml". </del>  1.1. Additional information: <del> Deprecated alias names for this type: application/x-yaml </del>  Magic number(s): n/a 3.2. <del> Type name: text Subtype name: yaml Required parameters: None Optional parameters: None; unrecognized parameters should be ignored Encoding considerations: Same as Security considerations: see security-considerations of this document Interoperability considerations: None Published specification: (this document) Applications that use this media type: HTTP Fragment identifier considerations: Same as for application/json Additional information: Deprecated alias names for this type: text/x-yaml Magic number(s): n/a File extension(s): yaml, yml Macintosh file type code(s): n/a Person and email address to contact for further information: See Authors' Addresses section. Intended usage: COMMON Restrictions on usage: None. Author: See Authors' Addresses section. Change controller: n/a 3.3. </del> Type name: application Subtype name: openapi+json Change controller: n/a <del> 3.4. </del>  Type name: application

by removing the section, and marking it and as deprecated aliases of . For use cases presenting YAML content as plain text, the media type is more appropriate.
Currently the spec supports fragment identifier based on "named anchors", e.g. references . Today alias nodes syntax is , but in the future alias nodes could support "pathlike" expressions, e.g. . Can "named anchors" fragment identifiers be extended in the future in a backward compatible way to suppot "alias nodes" syntax? Consider the following examples is a valid character for a named anchor, using as a pathlike separator might be non-trivial. Currently many YAML parser do only support though, so future YAML spec might restrict the syntax of named anchors keys might contain non-string characters (e.g. vs ). We need to know how pathlike elements are serialized, to identify a human-readable encoding (e.g. JSON Pointer) another example. A non human-readable encoding such as base64url would solve the issue, since we could just decode the string. This could be supported when pathlike are messy, e.g.
Feedback from NAME Maybe we could use something like
The easiest solution might be to initially restrict valid characters in the fragment identifier to . This would mean that while not all anchors are addressable, most would be. It would also allow relatively easy extension e.g. by making invalid as an fragment identifier, and therefore usable by a schema that extends it. Not sure how to express it, but it might be good to still reserve for future use by later YAML versions?
Or you could do the inverse and just keep = for application-specific fragment identifier schemes. BTW, why don't you include JSON pointer (RFC6901) in the standard set? That is quite useful for the majority of YAML applications (certainly the JSON compatible ones).
WRT sub-mediatypes like openapi and jsonschema, we are discussing in URL jsonschema supports two fragment identifiers: JSON Pointers and . Plain names are just strings, e.g. "foo". We could ask NAME if there is some space to tweak the usage of plain names as fragment identifiers. I think it would be useful, but I think it's YAML community choice (aka NAME ). Probably the easiest way to do it is: use JSONPointers if starts with use alias names if starts with This will allow further space for subtypes, eg. use jsonpath if starts with I am not sure that using unstructured strings as fragment identifiers is an interoperable choice at all. What do you think?
What's the problem that we're trying to solve here? If we're talking about fragment identifiers for , I don't see why we need to consider other specs at all. If we're talking about fragment identifiers for , we currently have this: URL Hence I think the proposal to limit fragment identifiers to makes sense, as that'll allow targeting nearly all real-world YAML anchors while keeping future YAML-spec compatibility good. Which may later bring in "native" support for something like JSON Pointers, and which this mediatype spec should not try to pre-empt. For cases, many formats need to be embeddable in JSON as well and include some form of internal anchor syntax. Those may of may not want to make the YAML anchors addressable by fragment identifiers as well, but they get to make that choice independently, much like they do already for .
Q1. What's the problem that we're trying to solve here? Identify a fragment identifier syntax that is compatible with existing formats like jsonpath and json pointers Q2. Why? Because implementers are accustomed to use json pointers and could for example just ignore our syntax Q3. Shouldn't implementers use JSON Pointers only when using openapi+yaml ? Theoretically yes. In practice, since openapi+yaml is not yet registered, implementers just use application/yaml + JSON Pointers. Using will at the same time: enable support for alias nodes (provided that a suitable encoding is defined in future YAML version) enable implementation to distinguish between json pointers and alias nodes just using the first character. Q4. What happens if we don't find a workaround for JSON Pointers? There's the possibility that implementers will anyway continue to use JSON Pointers for processing fragment identifiers. Q4. Is there some interest in using JSON Pointers in conjunction with ? While I thought there wasn't, iiuc NAME wrote that there could be some interest for that (but please correct me if I'm wrong).
We could ask NAME if there is some space to tweak the usage of plain names as fragment identifiers. There's no reason we couldn't constrain how plain name fragments work in future dialects of JSON Schema, but we still wouldn't be able to change the media type definition because then it wouldn't support the existing dialects that don't have those constraints.
Since with plain names do not overlap with application/yaml fragment syntax, implementers could decide to process fragments where URL(0, "") =~ /^[a-zA-Z]/ as plain names and still be interoperable with YAML. This behavior won't be interoperable with other +yaml media types that redefine fragment syntax though. Question: should we specify that supporting further syntaxes in conjunction with application/yaml could create interoperability issues with future implementations? cc: NAME
Closed in
For context, I'm one of the members of the YAML core team and the author of the . We were approached by NAME primarily to ensure that the parent specification includes a proper discussion of the security considerations inherent in workign with YAML. While I strongly support defining the media type, I do not think that the should be defined at this time. The rationale given for this appears to be based on a current difference in browser behaviour, and a nominal need to communicate consumer intent from the source. Defining more than one media type is superfluous, and creates unnecessary uncertainty. The bare-text presentation of YAML content to a human is already now achievable by presenting YAML as , exactly as is the case with JSON, which canonically uses the media type. If a different medium than GitHub issues is the best way to discuss this, I would be happy to make myself available to any such endeavour.
NAME thanks for your feedback! I think this is the right place to discuss that. Happy to confirm that the yaml community is ok with . Please, integrate the other "deprecated" media types (eg. application/x-yaml, URL, ...) Agree on presenting yaml as : maybe google-chrom just uses for that and does not have a specific behavior wrt and URL I see that has been deprecated. Can you PR that change?
LGTM

Abstract This document registers the following media types used in APIs on the  <ins> IANA Media Types registry: application/yaml, application/ </ins> openapi+json, and application/openapi+yaml. Note to Readers To increase interoperability when processing API specifications and leverage content negotiation mechanisms when exchanging OpenAPI Specification resources this specification register the following  <ins> media-types: "application/yaml", "application/openapi+json" and "application/openapi+yaml". </ins> 1.1. Additional information:  <ins> Deprecated alias names for this type: application/x-yaml, text/yaml, text/x-yaml </ins> Magic number(s): n/a 3.2.  Type name: application Subtype name: openapi+json Change controller: n/a  <ins> 3.3. </ins> Type name: application


2.1. <del> The following information serves as the registration form for the "application/yaml" media type. </del>  application

This might be a bit nitpicky, but I think the draft should explicitly say that contains YAML.
If you are ok with the integration, feel free to squash and merge NAME

2.1.  <ins> The media type for YAML text is "application/yaml"; the following information serves as the registration form for this media type. </ins> application


HTTP <del> None </del>  Additional information:

This defines fragment identifiers to be parsed as YAML aliases, which currently means that they must point to an explicitly defined anchor in the document, a feature natively supported by YAML. The definition intentionally allows for changes in later editions of the YAML spec to be automatically supported, e.g. as we're working towards supporting something like JSON pointers as well. The language in the fragment identifier section seems a bit complex, and I'm not sure if it should be updated as well. Formats should be allowed to define their own rules for fragment identifiers. Is this currently the case?
NAME Can you please add an example YAML URI with fragment identifier, so that we could find a way to provide it?
Struggling a bit to figure out just what you're looking for here. For an example of how this would work, let's presume that we have with the following contents: Then, would be pointing at the node with the value , while would point to the node with the value . Do you want this sort of example to be included in the RFC?
NAME probably it could be useful to add either an example section or a normative section that explicits that. An alternative could be to add this information in the YAML spec. WDYT? I imagine something brief like URL which includes some considerations on percent-encoding and some examples. A couple of question, for example: yaml can be encoded in UTF-8, 16, 32. Can anchor/alias nodes identifier be non-ascii / non-utf8 encoded ?
Let's discuss this topic in the issue
The YAML spec already includes sections on and , which then include some examples of them in use. The intent here is to defer to that spec's definition of alias nodes. At the point where the YAML spec defines anchors and aliases, it's treating its input as a sequence of Unicode code points, i.e. it doesn't care about their encoding. The YAML 1.2 set of acceptable characters for these is tbh far too wide, as it allows for nearly all printable Unicode code points.
reading URL iiuc I need to %encode the string, right? In this case I am not sure how this should work with UTF-8, 16, 32... Can you make some examples? (maybe related to URL)
Merging and moving discussion in
Currently the spec supports fragment identifier based on "named anchors", e.g. references . Today alias nodes syntax is , but in the future alias nodes could support "pathlike" expressions, e.g. . Can "named anchors" fragment identifiers be extended in the future in a backward compatible way to suppot "alias nodes" syntax? Consider the following examples is a valid character for a named anchor, using as a pathlike separator might be non-trivial. Currently many YAML parser do only support though, so future YAML spec might restrict the syntax of named anchors keys might contain non-string characters (e.g. vs ). We need to know how pathlike elements are serialized, to identify a human-readable encoding (e.g. JSON Pointer) another example. A non human-readable encoding such as base64url would solve the issue, since we could just decode the string. This could be supported when pathlike are messy, e.g.
Feedback from NAME Maybe we could use something like
The easiest solution might be to initially restrict valid characters in the fragment identifier to . This would mean that while not all anchors are addressable, most would be. It would also allow relatively easy extension e.g. by making invalid as an fragment identifier, and therefore usable by a schema that extends it. Not sure how to express it, but it might be good to still reserve for future use by later YAML versions?
Or you could do the inverse and just keep = for application-specific fragment identifier schemes. BTW, why don't you include JSON pointer (RFC6901) in the standard set? That is quite useful for the majority of YAML applications (certainly the JSON compatible ones).
WRT sub-mediatypes like openapi and jsonschema, we are discussing in URL jsonschema supports two fragment identifiers: JSON Pointers and . Plain names are just strings, e.g. "foo". We could ask NAME if there is some space to tweak the usage of plain names as fragment identifiers. I think it would be useful, but I think it's YAML community choice (aka NAME ). Probably the easiest way to do it is: use JSONPointers if starts with use alias names if starts with This will allow further space for subtypes, eg. use jsonpath if starts with I am not sure that using unstructured strings as fragment identifiers is an interoperable choice at all. What do you think?
What's the problem that we're trying to solve here? If we're talking about fragment identifiers for , I don't see why we need to consider other specs at all. If we're talking about fragment identifiers for , we currently have this: URL Hence I think the proposal to limit fragment identifiers to makes sense, as that'll allow targeting nearly all real-world YAML anchors while keeping future YAML-spec compatibility good. Which may later bring in "native" support for something like JSON Pointers, and which this mediatype spec should not try to pre-empt. For cases, many formats need to be embeddable in JSON as well and include some form of internal anchor syntax. Those may of may not want to make the YAML anchors addressable by fragment identifiers as well, but they get to make that choice independently, much like they do already for .
Q1. What's the problem that we're trying to solve here? Identify a fragment identifier syntax that is compatible with existing formats like jsonpath and json pointers Q2. Why? Because implementers are accustomed to use json pointers and could for example just ignore our syntax Q3. Shouldn't implementers use JSON Pointers only when using openapi+yaml ? Theoretically yes. In practice, since openapi+yaml is not yet registered, implementers just use application/yaml + JSON Pointers. Using will at the same time: enable support for alias nodes (provided that a suitable encoding is defined in future YAML version) enable implementation to distinguish between json pointers and alias nodes just using the first character. Q4. What happens if we don't find a workaround for JSON Pointers? There's the possibility that implementers will anyway continue to use JSON Pointers for processing fragment identifiers. Q4. Is there some interest in using JSON Pointers in conjunction with ? While I thought there wasn't, iiuc NAME wrote that there could be some interest for that (but please correct me if I'm wrong).
We could ask NAME if there is some space to tweak the usage of plain names as fragment identifiers. There's no reason we couldn't constrain how plain name fragments work in future dialects of JSON Schema, but we still wouldn't be able to change the media type definition because then it wouldn't support the existing dialects that don't have those constraints.
Since with plain names do not overlap with application/yaml fragment syntax, implementers could decide to process fragments where URL(0, "") =~ /^[a-zA-Z]/ as plain names and still be interoperable with YAML. This behavior won't be interoperable with other +yaml media types that redefine fragment syntax though. Question: should we specify that supporting further syntaxes in conjunction with application/yaml could create interoperability issues with future implementations? cc: NAME
Closed in
Compile fragment identifier section [ ] for [x] for ? Can we pospone this?
It seems strange to me that a media type would define a new "language" intrinsic.
I believe the registration should include the fragment identifier. +json does not identify one, which creates problems. It probably should have a registration update to address it. Not registering fragment handling means that a reference to a YAML-borne schema cannot be referenced. The part beyond the # would be formally nonsensical (as it is today). We can take some inspiration from the work on the same issue for JSON Schema. JSON Pointer tells us how to craft fragments. The same format applies to the semantic equivalent in YAML documents. I'll put in a pull request.
NAME we have splitted the two documents. I think that yaml fragment identifiers should probably be delegated to "structured" media types since there are multiple possibilities (eg. json-path, json pointers, ...) WRT openapi+yaml for example, we can state that the fragment uses json pointers.
NAME Can you confirm that the YAML community agrees with the current statement wrt fragment identifiers?
I'm pretty sure that fragment identifiers should not be defined for at least for now. As demonstrated e.g. by the work going on even in this repo, YAML is used to represent multiple different forms of structured data, some of which may at times be represented by other formats, such as JSON. So while YAML 1.1 and 1.2 do explicitly support on nodes that would rather naturally work as fragment identifiers, there's somewhat significant risk that this would complicate usage with sub-formats that natively use different methods, such as JSON Pointers. On the other hand, defining fragment identifiers for to follow the YAML spec for referring to anchors would make sense.
FWIW, I completely agree.
The choice to leave the fragment identifier of the structured syntax suffix to the media type is sensible: I will PR that.

HTTP  <ins> The fragment identifier is parsed as if it were a YAML alias node, but without a leading "*" indicator.  For example, in YAML 1.2, this means that it designates a node which has a correspondingly named anchor.  If multiple nodes would match a fragment identifier, the first such match is selected. </ins> Additional information:


see <del> The syntax and semantics of fragment identifiers specified for +yaml SHOULD be as specified for application-yaml The syntax and semantics for fragment identifiers for a specific "xxx/yyy+yaml" SHOULD be processed as follows: For cases defined in +yaml, where the fragment identifier resolves per the +yaml rules, then process as specified in +yaml. For cases defined in +yaml, where the fragment identifier does not resolve per the +yaml rules, then process as specified in "xxx/yyy+yaml". For cases not defined in +yaml, then process as specified in "xxx/yyy+yaml". </del>  See

no default frag-id for +yaml media types have to explicitly declare syntax and semantics
Compile fragment identifier section [ ] for [x] for ? Can we pospone this?
It seems strange to me that a media type would define a new "language" intrinsic.
I believe the registration should include the fragment identifier. +json does not identify one, which creates problems. It probably should have a registration update to address it. Not registering fragment handling means that a reference to a YAML-borne schema cannot be referenced. The part beyond the # would be formally nonsensical (as it is today). We can take some inspiration from the work on the same issue for JSON Schema. JSON Pointer tells us how to craft fragments. The same format applies to the semantic equivalent in YAML documents. I'll put in a pull request.
NAME we have splitted the two documents. I think that yaml fragment identifiers should probably be delegated to "structured" media types since there are multiple possibilities (eg. json-path, json pointers, ...) WRT openapi+yaml for example, we can state that the fragment uses json pointers.
NAME Can you confirm that the YAML community agrees with the current statement wrt fragment identifiers?
I'm pretty sure that fragment identifiers should not be defined for at least for now. As demonstrated e.g. by the work going on even in this repo, YAML is used to represent multiple different forms of structured data, some of which may at times be represented by other formats, such as JSON. So while YAML 1.1 and 1.2 do explicitly support on nodes that would rather naturally work as fragment identifiers, there's somewhat significant risk that this would complicate usage with sub-formats that natively use different methods, such as JSON Pointers. On the other hand, defining fragment identifiers for to follow the YAML spec for referring to anchors would make sense.
FWIW, I completely agree.
The choice to leave the fragment identifier of the structured syntax suffix to the media type is sensible: I will PR that.

see  <ins> Differently from "application/yaml", there is no fragment identification syntax defined for +yaml.  A specific "xxx/ yyy+yaml" media type needs to define the syntax and semantics for fragment identifiers because the ones in application-yaml do not apply unless explicitly expressed. </ins> See


<del> YAML Media Types </del>  draft-ietf-httpapi-yaml-mediatypes-latest Abstract YAML YAML is a data serialization format that is widely used on the Internet, including in the API sector (e.g. see oas) but the relevant <del> media type and structured syntax suffix are not registered by IANA. </del>  To increase interoperability when exchanging YAML data and leverage content negotiation mechanisms when exchanging YAML resources, this 2. This section describes the information required to register the above <del> media types according to </del>  2.1. media type structured syntax suffix registration form follows.  See MEDIATYPE for definitions of each of the registration form headings. <del> YAML Ain't Markup LanguageML (YAML) </del>  +yaml 3.1. <del> YAML is an evolving language and, in time, some features have been added, and others removed. </del>  <del> While this document is based on a given YAML version YAML, media types registration does not imply a specific version.  This allows </del>  content negotiation of version-independent YAML resources. Implementers concerned about features related to a specific YAML <del> version can specify it in the documents using the "%YAML" directive (see Section 6.8.1 of YAML). </del>  3.2. 5. <del> This specification defines the following new Internet media types </del>  MEDIATYPE. IANA has updated the "Media Types" registry at

addressing (and a few minor editorial changes thrown in as well).
This is probably left over from earlier drafts that did cover multiple media types.
There are a couple more places that use the plural form "media types". Unless I am missing something, these all should be changed to singular form.
It's and . I don't have preferences and the singular is OK to me. Feel free to PR :)
that's what i also thought but then again isn't a media type (as i am sure you know). let's make NAME the tie-breaker!
Let's go with the singular form.
fixed via

<ins> YAML Media Type </ins> draft-ietf-httpapi-yaml-mediatypes-latest Abstract YAML YAML is a data serialization format that is widely used on the Internet, including in the API sector (e.g. see oas) but the relevant  <ins> media type and structured syntax suffix previously had not been registered by IANA. </ins> To increase interoperability when exchanging YAML data and leverage content negotiation mechanisms when exchanging YAML resources, this 2. This section describes the information required to register the above  <ins> media type according to </ins> 2.1. media type structured syntax suffix registration form follows.  See MEDIATYPE for definitions of each of the registration form headings.  <ins> YAML Ain't Markup Language (YAML) </ins> +yaml 3.1.  <ins> YAML is an evolving language and, over time, some features have been added and others removed. </ins>  <ins> While this document is based on a given YAML version YAML, the media type registration does not imply a specific version.  This allows </ins> content negotiation of version-independent YAML resources. Implementers concerned about features related to a specific YAML  <ins> version can specify it in documents using the "%YAML" directive (see Section 6.8.1 of YAML). </ins> 3.2. 5.  <ins> This specification defines the following new Internet media type </ins> MEDIATYPE. IANA has updated the "Media Types" registry at


1.2.  This section describes how to use alias nodes (see Section 3.2.2.2 and 7.1 of YAML) as fragment identifiers to designate nodes. If multiple nodes would match a fragment identifier, the first such match is selected. <del> A fragment identifier is not guaranteed to reference an existing node.  Therefore, applications SHOULD define how an unresolved alias node ought to be handled. </del> Users concerned with interoperability of fragment identifiers: SHOULD limit alias nodes to a set of characters that do not based data serialization language designed around the common native data types of dynamic programming languages. <del> An empty fragment identifier references the root node.  A fragment identifier starting with "*" is to be interpreted as a YAML alias node application-yaml-fragment.  A fragment identifier starting with "/" is to be interpreted as a JSON Pointer JSON-POINTER and is evaluated on the YAML representation graph, walking through alias nodes; this syntax can only reference YAML nodes that are on a path that is made up of nodes interoperable with the JSON data model (see int-yaml-and-json). </del>  Additional information:

includes clarification on JSON Pointer and alias nodes compatibility includes FAQ fragment identifier moved from media type to section empty fragment + are both under JSON Pointer
cc: NAME NAME PTAL
According to NAME this PR should better clarify JSON Pointer use, so I am going to merge it. The decision on forcing +yaml fragment is deferred to that I will rebase.

1.2. <ins> A fragment identifier starting with "*" is to be interpreted as a YAML alias node fragment-alias-node. A fragment identifier that is empty or that starts with "/" is to be interpreted as a JSON Pointer JSON-POINTER and is evaluated on the YAML representation graph, walking through alias nodes; this syntax can only reference YAML nodes that are on a path that is made up of nodes interoperable with the JSON data model (see int-yaml-and-json). A fragment identifier is not guaranteed to reference an existing node.  Therefore, applications SHOULD define how an unresolved alias node ought to be handled. 1.2.1. </ins> This section describes how to use alias nodes (see Section 3.2.2.2 and 7.1 of YAML) as fragment identifiers to designate nodes. If multiple nodes would match a fragment identifier, the first such match is selected.  Users concerned with interoperability of fragment identifiers: SHOULD limit alias nodes to a set of characters that do not based data serialization language designed around the common native data types of dynamic programming languages.  <ins> See </ins> Additional information:


to be interpreted as in URI. The terms "node", "alias node", "anchor" and "named anchor" in this <del> document are to be intepreded as in YAML. </del>  1.2. and 7.1 of YAML) as fragment identifiers to designate nodes. A YAML alias node can be represented in a URI fragment identifier by <del> encoding it into octects using UTF-8 UTF-8, while percent-encoding </del>  those characters not allowed by the fragment rule in Section 3.5 of URI. yaml <del> None </del>  <del> None; unrecognized parameters should be ignored </del>  binary <del> HTTP </del>  An empty fragment identifier references the root node.  A fragment identifier starting with "*" is to be interpreted as a YAML alias Deprecated alias names for this type: application/x-yaml, text/ yaml, text/x-yaml <del> Magic number(s) n/a </del>  File extension(s): yaml, yml <del> Macintosh file type code(s): n/a </del>  See Authors' Addresses section. See Authors' Addresses section. <del> n/a </del>  2.2. See <del> See Authors' Addresses section. </del>  See Authors' Addresses section <del> n/a </del>  3. considerations apply. When using YAML as a more efficient format to serialize information <del> intented to be consumed as JSON, information can be discarded: this </del>  includes comments (see Section 3.2.3.3 of YAML) and alias nodes (see Section 7.1 of YAML), that do not have a JSON counterpart. identifiers.  This is to improve the interoperability of already consolidated practices, such as the one of writing OAS in YAML. <del> ex-fragid provides a non exhaustive list of examples that could help understanding interoperability issues related to fragment identifiers. </del>  4.

Fix typical media type template problems Typos
In general, LGTM. About change controller, I was waiting for the feedback from the media type mailing list.

to be interpreted as in URI. The terms "node", "alias node", "anchor" and "named anchor" in this  <ins> document are to be interpreted as in YAML. </ins> 1.2. and 7.1 of YAML) as fragment identifiers to designate nodes. A YAML alias node can be represented in a URI fragment identifier by  <ins> encoding it into bytes using UTF-8 UTF-8, while percent-encoding </ins> those characters not allowed by the fragment rule in Section 3.5 of URI. yaml  <ins> N/A </ins>  <ins> N/A; unrecognized parameters should be ignored </ins> binary  <ins> Applications that need a human-friendly, cross language, Unicode based data serialization language designed around the common native data types of dynamic programming languages. </ins> An empty fragment identifier references the root node.  A fragment identifier starting with "*" is to be interpreted as a YAML alias Deprecated alias names for this type: application/x-yaml, text/ yaml, text/x-yaml  <ins> Magic number(s) N/A </ins> File extension(s): yaml, yml  <ins> Macintosh file type code(s): N/A </ins> See Authors' Addresses section. See Authors' Addresses section.  <ins> IESG </ins> 2.2. See  <ins> httpapi@ietf.org or art@ietf.org </ins> See Authors' Addresses section  <ins> IESG </ins> 3. considerations apply. When using YAML as a more efficient format to serialize information  <ins> intended to be consumed as JSON, information can be discarded: this </ins> includes comments (see Section 3.2.3.3 of YAML) and alias nodes (see Section 7.1 of YAML), that do not have a JSON counterpart. identifiers.  This is to improve the interoperability of already consolidated practices, such as the one of writing OAS in YAML.  <ins> ex-fragid provides a non-exhaustive list of examples that could help understand interoperability issues related to fragment identifiers. </ins> 4.


to be interpreted as in URI. The terms "presentation", "stream", "YAML document", "representation <del> graph", "node", "alias node", "anchor" and "anchor name" in this document are to be interpreted as in YAML. </del>  1.2. considerations apply. When using YAML as a more efficient format to serialize information <del> intended to be consumed as JSON, information can be discarded: this includes comments (see Section 3.2.3.3 of YAML) and alias nodes (see Section 7.1 of YAML), that do not have a JSON counterpart. </del>  Implementers need to ensure that relevant information will not be lost during the processing.  For example, they might consider

in YAML and JSON, explicits that you need to use only information that is stored in the representation graph, not other. See
mention presentation and serialization details they cannot be used to interoperably convey information comments, ordering and anchor names fall in the above categories.

to be interpreted as in URI. The terms "presentation", "stream", "YAML document", "representation  <ins> graph", "tag", "node", "alias node", "anchor" and "anchor name" in this document are to be interpreted as in YAML. </ins> 1.2. considerations apply. When using YAML as a more efficient format to serialize information  <ins> intended to be consumed as JSON, information not reflected in the representation graph and classified as presentation or serialization detail (see Section 3.2 of YAML) can be discarded.  This includes comments (see Section 3.2.3.3 of YAML), directives, and alias nodes (see Section 7.1 of YAML) that do not have a JSON counterpart. </ins> Implementers need to ensure that relevant information will not be lost during the processing.  For example, they might consider


Magic number(s) N/A <del> File extension(s): yaml, yml </del>  Macintosh file type code(s): N/A 3.3.  When using flow collection styles (see Section 7.4 of YAML) a YAML document could look like JSON JSON, thus similar interoperability considerations apply. types like custom and local tags such as "!!python/object" and "!mytag" (see Section 2.4 of YAML); <del> 3.4. </del>  To allow fragment identifiers to traverse alias nodes, the YAML representation graph needs to be generated before the fragment

looks good to me (with one minor editorial note i left as a comment).
Would it be valuable to express a preference for over for file extensions? I'm assuming 3 character extensions are legacy from DOS file systems that had a 3 character limit. I reviewed the YAML 1.2 spec and there is no mention of using as a file extensions, so this might be a good opportunity to steer the community away from having two extensions.
Pls let's annihilate the DOS zombie!
NAME let's summon NAME and the YAML folks on that. IMHO: agree on expressing a preference disagree on removing references to .yml, since it's used in the wild. My2¢, R.
Discussed with YAML folks. Ok for indicating a preference without normative implications.

Magic number(s) N/A  <ins> File extension(s): "yaml" (preferred), "yml".  See int-yaml- filename-extension. </ins> Macintosh file type code(s): N/A 3.3. <ins> The "yaml" filename extension is the preferred one; it is the most popular and widely used on the web.  The "yml" filename extension is still used.  The simultaneous usage of two filename extensions in the same context might cause interoperability issues (e.g. when both a "config.yaml" and a "config.yml" are present). 3.4. </ins> When using flow collection styles (see Section 7.4 of YAML) a YAML document could look like JSON JSON, thus similar interoperability considerations apply. types like custom and local tags such as "!!python/object" and "!mytag" (see Section 2.4 of YAML);  <ins> 3.5. </ins> To allow fragment identifiers to traverse alias nodes, the YAML representation graph needs to be generated before the fragment


Macintosh file type code(s): N/A  See Authors' Addresses section. COMMON

Adds windows clipboard name
From media type ML Except being exchanged over http and being edited by simple text-editors (as text), I am supposing that YAML content is likely to be exchanged among editors using a copy-and-paste exchange mechanism. Is it the case? If this is the case, I would like to suggest to add uniform type identifiers and windows clipboard names so that future implementations may take part to such an exchange in the Additional Information section. See
There's a few media-type registrations which contain clipboard format names. Among others , , . In general, windows clipboard flavor names are freely choosable. Apple's (macOS and iOS) Universal Type Identifiers (UTIs) are now somewhat governed by Apple documentation, I recommend starting at wikipedia's . In general, it makes a lot of sense to consider existing widespread implementations first.
NAME can the following values work? I read the wikipedia entry, but is seems a very apple-specific stuff: should they "validate" the value? If we need to add them later, we should be able to do it directly with the IANA, no need to publish a new RFC, right? NAME since you are the YAML expert, the decision is up to you and the other YAML folks.
For Windows, I believe this can. For macOS, I am unfortunately unsure. Although several have defined -prefixed UTIs, it appears that Apple now considers these UTIs as being those that the OS defines. This was highlighted in although it kind of contradicts the history of what was done earlier. That thread has not resolved yet. I would feel that is good but it would be important to check with some members at Apple to ensure this or simply use .
Let's wait for NAME . This should be done in coordination with Apple and MS though. If we don't have connections my suggestion is to defer after the publication. NAME can you provide a contact for the windows clipboard identified stuff? Can we use this repo after publication for tracking this kind of activities ?
NAME I will go hunting.
I doubt that waiting on the feedback from Apple or MicroSoft folks will be timely. From I see that the reverse DNS approach is likely the most accepted. May I suggest the following? For windows, my recommendation above stays as no strict specification seem to exist: Hope it helps. Paul
NAME do you think Windows folks will just adapt picking the value we chose? If not, I think that updating the registration afterwards is a sensible choice.
Here is the documentation bit for windows: URL From that page, there seems to be plenty of freedom: either the app chooses something that exists and takes over the same number for its type identifier (they have converged) or they choose to diverge. I think that those who would adapt if decided now or adapted afterwards are the apps that circulate.
I have not got any further information from Microsoft folks, however, what I have seen is that it is it is expected that people who want to adopt a value are responsible for doing their own due diligence to ensure that the value has not been used for alternative purposes. I believe that using the YAML clipboard name is a safe choice and that we can close this issue.
NAME should we register the YAML clipboard name in the media type registration, then?

Macintosh file type code(s): N/A <ins> Windows Clipboard Name: YAML </ins> See Authors' Addresses section. COMMON


For convenience, this document adopts the representation of these services being standalone servers, however the MLS protocol design is <del> made so that it is not necessarily the case. </del>  It is important to note that the Authentication Service functionality can be completely abstract in the case of a Service Provider which

That looks good. Thank you for drafting it.
Thanks Richard!
This is a discussion point for the WG, regarding choice of terminology for the AS / DS. For those within the WG, these terms are clear - there have been several issues/PRs to enhance clarity or functionalities (, , , , , etc.), and the AS / DS describe core functionalities. These are not server components but conceptual representations, e.g. those functionalities could be realized through a "separate directory functionality or service" (spec). However, I have noticed a very strong trend for people reading the documents / determining use-case applicability to interpret the AS / DS "services" as an absolute requirement for centralized "servers". This does not seem to be a set of random side cases; there is a natural association of terminology and that could result in unnecessary avoidance of the protocol under such a restricted interpretation. I suggest that we consider a slight terminology change that could avoid these issues. For example, some options may be AM / DM (Authentication Management / Distribution Management), AP / DM (Authentication Provisioning, Distribution Management). I.e. 'management', 'provider / provisioning', 'function', etc. avoid the key word association to 'server' and leave the reader assumptions open to other options.
Rather than change the terminology, I would prefer we just elaborate on the variety of ways that the "service" could be realized -- centralized vs. decentralized, client vs. server, etc. Changing the terminology everywhere at this point would be a pretty invasive change.
Well, services certainly can be distributed or even federated, as in, for instance, the X.500 directory service, so I don't think that "Service" implies that there is a single server. It's not clear to me that "Function" is better than service and the other alternatives you propose seem more confusing.
There has been discussion in the protocol document on changing out core components that affect cryptographic analysis, so a keyword search-and-replace is relatively not very invasive by comparison. However, I agree that it would be easier to keep changes to a minimum. What we must avoid is burying a description on different ways to realize these somewhere in the architecture document - that is arguably already there and has not mitigated the issue, it seems. If keeping "service" and adding clarification is a preferred way to go, then it needs to be prominently stated with organization to match. The fact that "service" has other uses than an analogous "server" has not evaded misrepresentation/misinterpretation - a clear specification in this is really dependent on the broader community understanding the goal vs any one sense of clarity/confusion.
It would need to be clarified under the General Setting, where the AS/DS are introduced, in particular.
NAME I took a stab at this in

For convenience, this document adopts the representation of these services being standalone servers, however the MLS protocol design is  <ins> made so that it is not necessarily the case.  These services may reside on the same server or different servers; they may be distributed between server and client components; and they may even involve some action by users.  For example: Several secure messaging services today provide a centralized DS, and rely on manual comparison of clients' public keys as the AS. MLS clients connected to a peer-to-peer network could instantiate a decentralized DS by transmitting MLS messages over that network. In an MLS group using a PKI for authentication, the AS would comprise the certificate issuance and validation processes, both of which involve logic inside MLS clients as well as various servers. </ins> It is important to note that the Authentication Service functionality can be completely abstract in the case of a Service Provider which


Upon joining the system, each client stores its initial cryptographic key material with the Delivery Service.  This key material, called a KeyPackage, advertises the functional abilities of the client such as <del> supported protocol versions, extensions, and the following </del>  cryptographic information: A credential from the Authentication Service attesting to the 6. <del> A fully functional deployment of MLS requires a number of infrastructure services to be available, as well as several policies and design trade-offs that are decided by the application.  This section lists all of the dependencies of an MLS deployment that are external to the protocol specification, but would still need to be aligned for two deployments to potentially interoperate. MLS has the built-in ability to negotiate protocol versions, ciphersuites, extensions, and credential types.  For two deployments to interoperate, they must have overlapping support in each of these categories. </del>  MLS relies on the following network services.  These network services <del> would either need to be the same, or compatible at the wire-format level, in order for two different deployments based on them to interoperate. </del>  An *Authentication Service*, described fully in authentication- service, defines the types of credentials which may be used in a Issuing new credentials, <del> Validating existing credentials against a reference identifier, and </del>  Validating whether or not two credentials represent the same user. keys but should still only be considered a single client. A policy on how long to allow a member to stay in a group without <del> updating its leaf keys, and whether there should be any attempt to resolve a stale leaf key before removing the member. </del>  Finally, there are some additional application-defined behaviors that are partially an individual application's decision but may overlap

Replaces Not compact.
When deploying MLS, the deployer/implementer needs a certain set of choices made. For example, authentication authorities, transport choices, how to interpret application data, etc. This draft could create a succinct summary format that a deployer could use as a checklist to make sure they've done the legwork necessary to be able to deploy MLS safely. this came up in the IETF 113 meeting.
If the draft describes such a summary as a template, then maybe some of the existing deployments could try filling it in, so we could see whether it's sufficient.
I actually think the answer here is fairly compact, and mostly laid out in the arch spec, so it's mainly a question of pulling together the threads. Basically, the application needs to define: An authentication service A delivery service What the content of the messages will be
compact is good and it looks like your list aligns roughly with the intuitions i opened this issue with, so that's good too. Are there any choices about cryptographic primitives that need to be decided as well (e.g. ciphersuite limitations or requirements, expected credential types)? What about MLS extensions or MLS proposals that clients connected to this deployment are expected to support or avoid?
I have no idea whether the template i outlined in is correct, let alone exhuastive. I offer it as a starting point, and won't be upset if anyone wants to step in to improve/correct it.
Really like this direction, few small tweaks.This looks good. Thanks Brendan, Thanks Richard!

Upon joining the system, each client stores its initial cryptographic key material with the Delivery Service.  This key material, called a KeyPackage, advertises the functional abilities of the client such as  <ins> supported protocol versions, supported extensions, and the following </ins> cryptographic information: A credential from the Authentication Service attesting to the 6.  <ins> MLS is a security layer that needs to be integrated with an application.  A fully-functional deployment of MLS will have to make a number of decisions about how MLS is configured and operated. Deployments that wish to interoperate will need to make compatible decisions.  This section lists all of the dependencies of an MLS deployment that are external to the protocol specification, but would still need to be aligned within a given MLS deployment, or for two deployments to potentially interoperate. The protocol has a built-in ability to negotiate protocol versions, ciphersuites, extensions, credential types, and additional proposal types.  For two deployments to interoperate, they must have overlapping support in each of these categories.  A "required_capabilities" extension can help maintain interoperability with a wider set of clients by ensuring that certain functionality continues to be supported by a group, even if the clients in the group aren't currently relying on it. </ins> MLS relies on the following network services.  These network services  <ins> would need to be compatible in order for two different deployments based on them to interoperate. </ins> An *Authentication Service*, described fully in authentication- service, defines the types of credentials which may be used in a Issuing new credentials,  <ins> Validating a credential against a reference identifier, and </ins> Validating whether or not two credentials represent the same user. keys but should still only be considered a single client. A policy on how long to allow a member to stay in a group without  <ins> updating its leaf keys before removing them. </ins> Finally, there are some additional application-defined behaviors that are partially an individual application's decision but may overlap


agreement properties of MLS will confirm that all members of the group agree on the content of these extensions. <del> Application messages carried by MLS are opaque; they can contain arbitrary data.  The MLS framing for application messages also provides a field where clients can send information that is authenticated but not encrypted.  Such information can be used by servers that handle the message, but group members are assured that it has not been tampered with. </del> 5.8.  The protocol aims to be compatible with federated environments. While this document does not specify all necessary mechanisms required for federation, multiple MLS implementations can authentication mechanisms, ciphersuites, and infrastructure functionalities. <del> 5.9. </del>  It is important that multiple versions of MLS be able to coexist in the future.  Thus, MLS offers a version negotiation mechanism; this

As discussed in today's interim. This is essentially repushing which should not have been reverted.
URL
Interim 2022-06-09: Informational refence from RFC to a draft is allowed Agreement to just un-revert / re-land
Fixed in

agreement properties of MLS will confirm that all members of the group agree on the content of these extensions.  5.8. <ins> Application messages carried by MLS are opaque to the protocol; they can contain arbitrary data.  Each application which uses MLS needs to define the format of its "application_data" and any mechanism necessary to negotiate the format of that content over the lifetime of an MLS group.  In many applications this means managing format migrations for groups with multiple members who may each be offline at unpredictable times. *RECOMMENDATION:* Use the default content mechanism defined in I- D.mahy-mls-content-neg, unless the specific application defines another mechanism which more appropriately addresses the same requirements for that application of MLS. The MLS framing for application messages also provides a field where clients can send information that is authenticated but not encrypted. Such information can be used by servers that handle the message, but group members are assured that it has not been tampered with. 5.9. </ins> The protocol aims to be compatible with federated environments. While this document does not specify all necessary mechanisms required for federation, multiple MLS implementations can authentication mechanisms, ciphersuites, and infrastructure functionalities.  <ins> 5.10. </ins> It is important that multiple versions of MLS be able to coexist in the future.  Thus, MLS offers a version negotiation mechanism; this


assume this. Users will often use multiple devices, e.g., a phone as well as a <del> laptop.  Different devices are represented as different clients with independent cryptographic state. </del>  3.

Thanks Brendan! I'll merge this modulo the deletion of the paragraph regarding "being a member" since that was specifically discussed during an interim call.

assume this. Users will often use multiple devices, e.g., a phone as well as a  <ins> laptop.  The formal definition of a Group in MLS is the set of clients that have knowledge of the shared group secret established in the group key establishment phase of the protocol and have contributed to it.  Until a Member has been added to the group and contributed to the group secret in a manner verifiable by other members of the group, other members cannot assume that the Member is a member of the group.  Different devices are represented as different clients with independent cryptographic state. </ins> 3.


Issue credentials to clients that attest to bindings between identities and signature key pairs <del> Enable a group member to verify that a credential presented by another member is valid with respect to a reference identifier </del>  Enable a group member to verify that a credential represents the <del> same application-level device as another credential </del>  A member with a valid credential authenticates its MLS messages by signing them with the private key corresponding to the public key epoch and begins the next one. In practice, there's a realistic risk of two members generating <del> Commit messages at the same time, based on the same state, and both </del>  attempting to send them to the group at the same time.  The extent to which this is a problem, and the appropriate solution, depends on the design of the Delivery Service.  Per the CAP theorem, there are two Strategies for sequencing messages in CP and AP systems are described in the next two subsections. <del> However, note that a Delivery Service could also reorder messages or provide an inconsistent view to different users not just accidentally, but maliciously.  The protocol is designed such that this only results in a group no longer being functional and the group members possibly detecting this and requesting reinitialization. </del>  Other forms of Delivery Service misbehavior are still possible that are not easy to detect.  For instance, a Delivery Service can simply

This PR pulls in the CAP theorem-related discussion from URL which is a more helpful way to frame DS design.

Issue credentials to clients that attest to bindings between identities and signature key pairs  <ins> Enable a client to verify that a credential presented by another client is valid with respect to a reference identifier </ins> Enable a group member to verify that a credential represents the  <ins> same application-level device as another credential when possible </ins> A member with a valid credential authenticates its MLS messages by signing them with the private key corresponding to the public key epoch and begins the next one. In practice, there's a realistic risk of two members generating  <ins> Commit messages at the same time, based on the same counter, and both </ins> attempting to send them to the group at the same time.  The extent to which this is a problem, and the appropriate solution, depends on the design of the Delivery Service.  Per the CAP theorem, there are two Strategies for sequencing messages in CP and AP systems are described in the next two subsections.  <ins> However, note that a malicious Delivery Service could also reorder messages or provide an inconsistent view to different users.  The protocol is designed such that this only results in a group no longer being functional and the group members possibly detecting this and requesting reinitialization. </ins> Other forms of Delivery Service misbehavior are still possible that are not easy to detect.  For instance, a Delivery Service can simply


to join who has access to the GroupInfo object.  External joins do not allow for more granular authorization checks to be done before the new member is added to the group, so if an application wishes to <del> both allow external joins and enforce such checks, then the application will need to do such checks when a member joins, and remove them if checks fail. </del>  Application setup may also determine other criteria for membership validity.  For example, per-device signature keys can be signed by an agree on which signers are allowed to send proposals, but any other policies must be assured to be consistent as above. <del> ** RECOMMENDATION:** Have an explicit group policy setting the </del>  conditions under which external joins are allowed. 5.5. While this document does not specify all necessary mechanisms required for federation, multiple MLS implementations can interoperate to form federated systems if they use compatible <del> authentication mechanisms, ciphersuites, and infrastructure functionalities. </del>  5.10.

WGLC comments to Functional Requirements Section: Include text for case when external joins are authorized by members autonomously Fix formatting of one RECOMMENDATION section Reference the mls-federation document (informational)
Following on from discussion in Even once a GroupInfo has been published to a prospective new joiner, there are still a few opportunities to apply authorization policy to the join: The DS can block the external Commit from reaching the group members (requires intelligent DS) The clients in the group can all refuse to apply the external Commit (requires consistent policy) Any client can remove the member after allowing them to join (might expose some group comms to the joiner)
Comment by NAME This seems rather risky? What could such a member do in the short time between getting added and getting kicked? Would they see message history? Group membership? How many devices a user has? When members were last online? Why support such a group type? Wouldn't it be better to not support this and have an automated "special member" being a bot that handles member addition?
Until someone else sends a message, a new joiner doesn't learn anything non-public. If you think about it, how would they? They're outside the group before they send an external join, and the external join just establishes a new shared secret with the group for future communications. More specifically: Message history - MLS's forward secrecy guarantees mean that new joiners don't get message history. Group membership - This is public anyway via the GroupInfo that an external joiner needs to join How many devices - To the degree this is exposed, it would be in the group membership Last online - MLS doesn't have any notion of this As for an "add me bot", it's a useful idea, but not applicable to a bunch of cases. The bot has to be a member of the group and has to be always-online. So now you have the group's secrets on a server somewhere, instead of just in the communicating endpoints, already an additional point of compromise. And it can't be the DS's server, since the whole point is to protect against the DS.
This statement in the draft is just plain wrong. In our implementation, we actually do validation of External joins at the application layer. I addressed this in (dating from WGLC) which says the following: "External joins do not allow for more granular authorization checks to be done before the new member is added to the group, so if an application wishes to both allow external joins and enforce such checks, then either all the members of the group must all have the ability to check and reject invalid External joins autonomously, or the application needs to do such checks when a member joins and remove them if those checks fail."

to join who has access to the GroupInfo object.  External joins do not allow for more granular authorization checks to be done before the new member is added to the group, so if an application wishes to  <ins> both allow external joins and enforce such checks, then either all the members of the group must all have the ability to check and reject invalid External joins autonomously, or the application needs to do such checks when a member joins and remove them if those checks fail. </ins> Application setup may also determine other criteria for membership validity.  For example, per-device signature keys can be signed by an agree on which signers are allowed to send proposals, but any other policies must be assured to be consistent as above.  <ins> *RECOMMENDATION:* Have an explicit group policy setting the </ins> conditions under which external joins are allowed. 5.5. While this document does not specify all necessary mechanisms required for federation, multiple MLS implementations can interoperate to form federated systems if they use compatible  <ins> authentication mechanisms, ciphersuites, application content, and infrastructure functionalities.  Federation is described in more detail in I-D.ietf-mls-federation. </ins> 5.10.


Abstract <del> The Messaging Layer Security (MLS) protocol I-D.ietf-mls-protocol </del>  specification has the role of defining a Group Key Agreement protocol, including all the cryptographic operations and serialization/deserialization functions necessary for scalable and past epoch is received, clients use a deterministic tie-breaking policy to decide if they should continue using the Commit they originally accepted or revert and use the later one.  Note that <del> any copies of previous or forked group states MUST be deleted </del>  within a reasonable amount of time to ensure the protocol provides forward-secrecy.

According to I-D Nits: Checking nits according to URL : The abstract seems to contain references ([I-D.ietf-mls-protocol]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 557: 'URL forked group states MUST be deleted...'
TY!
Thanks NAME

Abstract  <ins> The Messaging Layer Security (MLS) protocol (I-D.ietf-mls-protocol) </ins> specification has the role of defining a Group Key Agreement protocol, including all the cryptographic operations and serialization/deserialization functions necessary for scalable and past epoch is received, clients use a deterministic tie-breaking policy to decide if they should continue using the Commit they originally accepted or revert and use the later one.  Note that  <ins> any copies of previous or forked group states must be deleted </ins> within a reasonable amount of time to ensure the protocol provides forward-secrecy.


Application messages carried by MLS are opaque to the protocol; they can contain arbitrary data.  Each application which uses MLS needs to define the format of its "application_data" and any mechanism <del> necessary to negotiate the format of that content over the lifetime </del>  of an MLS group.  In many applications this means managing format migrations for groups with multiple members who may each be offline at unpredictable times. *RECOMMENDATION:* Use the default content mechanism defined in I- <del> D.mahy-mls-content-neg, unless the specific application defines </del>  another mechanism which more appropriately addresses the same requirements for that application of MLS.

Made minor changes to the section of content and framing. Updated reference draft-mahy-mls-content-neg -> draft-mahy-mls-content-adv The recommended mechanism is advertising content/media types, not a full negotiation mechanism.

Application messages carried by MLS are opaque to the protocol; they can contain arbitrary data.  Each application which uses MLS needs to define the format of its "application_data" and any mechanism  <ins> necessary to determine the format of that content over the lifetime </ins> of an MLS group.  In many applications this means managing format migrations for groups with multiple members who may each be offline at unpredictable times. *RECOMMENDATION:* Use the default content mechanism defined in I-  <ins> D.mahy-mls-content-adv, unless the specific application defines </ins> another mechanism which more appropriately addresses the same requirements for that application of MLS.


This document specifies version 1.0 of the Messaging Layer Security (MLS) protocol.  MLS allows group messaging for a large number of <del> clients over a network with the help of a delivery service for messages, and potentially an authentication service to provide long term identity keys, in a way that is designed to prevent eavesdropping, tampering, and message forgery. </del>  1. End-to-end security is a requirement for instant messaging systems <del> and is commonly deployed in many such systems designed over the past few years.  In this context, what end-to-end means is that the users of the system enjoy some level of security - with the precise level depending on the system design - even when the messaging service they are using misbehaves. </del>  Messaging Layer Security (MLS) specifies an architecture (this document) and an abstract protocol [TODO:XREF] for providing end-to- encodings, such as TLS I-D.ietf-tls-tls13, CBOR RFC7049, and JSON RFC7159.  Implementations which adopt compatible encodings should be able to have some degree of interoperability at the message level <del> (though perhaps not at the authentication level). </del>  2. <del> A Group using a Messaging Service (MS) is a set of participants called Members where each Member is typically expected to own multiple devices called Clients.  In order to communicate securely, Group Members first use services at their disposal to obtain necessary secrets and credentials required for security. </del>  The Messaging Service (MS) presents as two abstract services that <del> allow Members to prepare before sending and receiving messages securely : </del>  An Authentication Service (AS) which is responsible for maintaining user long term identities, issuing credentials which allow them to authenticate to each other, and potentially <del> distributing user signing keying material. </del>  A Delivery Service (DS) which is responsible for receiving and redistributing messages between group members.  In the case of group messaging, the delivery service may also be responsible for acting as an "exploder" where the sender sends a single message to a group which is then forwarded to each recipient in the group. <del> The DS is also responsible to store and deliver initial public keying material required to proceed with the group secret key establishment process. </del>  In many systems, the AS and the DS are actually operated by the same entity and may even be the same server.  However, they are logically <del> distinct and, in other systems, may be operated by different entities so we show them as separate here.  Other partitions are also possible, such as having a separate directory server. </del>  <del> A typical scenario might look something like this: </del>  <del> Alice, Bob, and Charlie create accounts with a messaging service </del>  and obtain credentials from the AS. <del> Alice, Bob, and Charlie authenticate to the DS and store some initial keying material which can be used to encrypt to them for the first time. </del>  When Alice wants to send a message to Bob and Charlie, she contacts the DS and looks up their initial keying material.  She <del> uses those keys to establish a new set of keys which she can use to send to Bob and Charlie.  She then sends the encrypted message(s) to the DS, which forwards them to the ultimate </del>  recipients. Bob and/or Charlie respond to Alice's message.  Their messages might trigger a new key derivation step which allows the shared group key to be updated, thus providing post-compromise security. <del> 2.1. Roles: Clients in groups (and by extension Members) have equal rights for managing groups and sending messages, unless specified otherwise outside the protocol, typically at the application layer. </del>  <del> I want to create a group by inviting other members </del>  <del> I want to add one or more members to an existing group </del>  <del> I want to remove one or more members from an existing group </del>  <del> I want to join an existing group </del>  <del> I want to leave a group </del>  <del> I want to send a message to everyone in the group </del>  <del> I want to receive a message from someone in the group </del>  <del> 2.2. </del>  In MLS a Group is defined as a set of Members who possibly use multiple endpoint devices to interact with the Messaging Service. <del> Only endpoints that are not an AS nor a DS are called Clients.  These </del>  clients will typically correspond to end-user devices such as phones, web clients or other devices running MLS. a phone) or sequentially (e.g., replacing one phone with another), hence the formal definition of a Group in MLS is the set of Clients that has legitimate knowledge of the shared (Encryption) Group Key <del> established throughout the group key establishment phase of the protocol. </del>  MLS has been designed to provide similar security guarantees to all Clients, for all group sizes, even when it reduces to only two Clients. <del> 2.3. </del>  The Delivery Service (DS) is expected to play multiple roles in the Messaging Service architecture. Delivery Service, the functionnal and security guarantees provided by MLS may differ. <del> 2.3.1. </del>  In the MLS group communication establishment process, the first step exercised by the DS is to store the initial cryptographic key examine the KT log, if available, to make sure the keys they will be using are correct. <del> 2.3.2. </del>  Delivery in order and resilience against intermittent message loss are the two main properties expected by MLS from the DS.  Another correct delivery will not be trusted regarding the group membership information either. <del> 2.3.3. </del>  A particularly important security constraint in that an adversary must not be able to gain access to information about the identity of counter measures against potential traffic analysis that could be done at the DS level. <del> 2.3.4. </del>  Clients that have been offline for a long time or not performing mandatory security operations will affect the security of the group to preserve security properties such as forward secrecy of messages or post-compromise security. <del> 2.4. </del>  New Members to the Messaging Service will always need to provide some initial keying material for other users to potentially use when

A few minor edits to (hopefully) improve readability, and a few comments in square braces ([ ]).
Something looks wrong with your text editor... ;)
Arg! Will fix, sorry about this.

This document specifies version 1.0 of the Messaging Layer Security (MLS) protocol.  MLS allows group messaging for a large number of  <ins> networked clients by providing a delivery service for messages, and potentially an authentication service, in a way that is designed to prevent eavesdropping, tampering, and message forgery. </ins> 1. End-to-end security is a requirement for instant messaging systems  <ins> and is commonly deployed in many such systems.  In this context, "end-to-end" captures the notion that users of the system enjoy some level of security - with the precise level depending on the system design - even when the messaging service they are using performs unsatisfactorily. </ins> Messaging Layer Security (MLS) specifies an architecture (this document) and an abstract protocol [TODO:XREF] for providing end-to- encodings, such as TLS I-D.ietf-tls-tls13, CBOR RFC7049, and JSON RFC7159.  Implementations which adopt compatible encodings should be able to have some degree of interoperability at the message level  <ins> (though perhaps not at the authentication level).  [[TvdM: What precisely do we mean by authentication level here?  Also, it's not clear, upon initial reading of this section, what the purpose of this document is.  Perhaps we should be more explicit in explain why it's necessary?]] </ins> 2.  <ins> A Group using a Messaging Service (MS) comprises a set of participants called Members where each Member is typically expected to own multiple devices, called Clients.  In order to communicate securely, Group Members initially use services at their disposal to obtain the necessary secrets and credentials required for security. </ins> The Messaging Service (MS) presents as two abstract services that  <ins> allow Members to prepare for sending and receiving messages securely : </ins> An Authentication Service (AS) which is responsible for maintaining user long term identities, issuing credentials which allow them to authenticate to each other, and potentially  <ins> distributing user signing keys. </ins> A Delivery Service (DS) which is responsible for receiving and redistributing messages between group members.  In the case of group messaging, the delivery service may also be responsible for acting as an "exploder" where the sender sends a single message to a group which is then forwarded to each recipient in the group.  <ins> The DS is also responsible for storing and delivering initial public key material required in order to proceed with the group secret key establishment process. [[ TvdM: "exploder" may be strange term to use here, "message amplifier" maybe?]] </ins> In many systems, the AS and the DS are actually operated by the same entity and may even be the same server.  However, they are logically  <ins> distinct and, in other systems, may be operated by different entities, hence we show them as being separate here.  Other partitions are also possible, such as having a separate directory server. </ins>  <ins> A typical scenario might look like this: </ins>  <ins> Alice, Bob and Charlie create accounts with a messaging service </ins> and obtain credentials from the AS.  <ins> Alice, Bob and Charlie authenticate to the DS and store some initial keying material which can be used to send encrypted messages to them for the first time. </ins> When Alice wants to send a message to Bob and Charlie, she contacts the DS and looks up their initial keying material.  She  <ins> uses these keys to establish a new set of keys which she can use to send encrypted messages to Bob and Charlie.  She then sends the encrypted message(s) to the DS, which forwards them to the </ins> recipients. Bob and/or Charlie respond to Alice's message.  Their messages might trigger a new key derivation step which allows the shared group key to be updated, thus providing post-compromise security.  <ins> Clients in groups (and by extension Members) have equal rights for managing groups and sending messages, unless specified otherwise outside of the messaging protocol, typically at the application layer.  Clients may wish to do the following: </ins>  <ins> create a group by inviting other members </ins>  <ins> add one or more members to an existing group </ins>  <ins> remove one or more members from an existing group </ins>  <ins> join an existing group </ins>  <ins> leave a group </ins>  <ins> send a message to everyone in the group </ins>  <ins> receive a message from someone in the group </ins>  <ins> 2.1. </ins> In MLS a Group is defined as a set of Members who possibly use multiple endpoint devices to interact with the Messaging Service.  <ins> Only endpoints that are not an AS or a DS are called Clients.  These </ins> clients will typically correspond to end-user devices such as phones, web clients or other devices running MLS. a phone) or sequentially (e.g., replacing one phone with another), hence the formal definition of a Group in MLS is the set of Clients that has legitimate knowledge of the shared (Encryption) Group Key  <ins> established in the group key establishment phase of the protocol. </ins> MLS has been designed to provide similar security guarantees to all Clients, for all group sizes, even when it reduces to only two Clients.  <ins> 2.2. </ins> The Delivery Service (DS) is expected to play multiple roles in the Messaging Service architecture. Delivery Service, the functionnal and security guarantees provided by MLS may differ.  <ins> 2.2.1. </ins> In the MLS group communication establishment process, the first step exercised by the DS is to store the initial cryptographic key examine the KT log, if available, to make sure the keys they will be using are correct.  <ins> 2.2.2. </ins> Delivery in order and resilience against intermittent message loss are the two main properties expected by MLS from the DS.  Another correct delivery will not be trusted regarding the group membership information either.  <ins> 2.2.3. </ins> A particularly important security constraint in that an adversary must not be able to gain access to information about the identity of counter measures against potential traffic analysis that could be done at the DS level.  <ins> 2.2.4. </ins> Clients that have been offline for a long time or not performing mandatory security operations will affect the security of the group to preserve security properties such as forward secrecy of messages or post-compromise security.  <ins> 2.3. </ins> New Members to the Messaging Service will always need to provide some initial keying material for other users to potentially use when


Clients should not be able to send messages to groups which appear to be from other Clients  4. As the MLS protocol provides an important service to users, its cryptographic keys for attachments is usually higher than for messages, hence slightly weakening the PCS guarantees for attachments.

As per Jan MLS meetup, malicious insiders should be considered as a potential threat, though perhaps in a restricted set of scenarios. It is probably bad if a malicious group member can trivially DoS people, for example, as in naïve ART.

Clients should not be able to send messages to groups which appear to be from other Clients <ins> Clients should not be able to perform trivial denials of service </ins> 4. As the MLS protocol provides an important service to users, its cryptographic keys for attachments is usually higher than for messages, hence slightly weakening the PCS guarantees for attachments. <ins> 4.2.2.4. In general we do not consider denial of service to be the responsibility of the protocol.  However, it should not be possible for anyone to perform a trivial denial of service from which it is hard to recover. --- back </ins>


As discussed above, MLS provides the highest level of security when its messages are delivered over a secure transport.  Any secure channel can be used as a transport layer to protect MLS messages, <del> such as QUIC, TLS, WireGuard or TOR.  However, the MLS protocol is designed to consider the following threat-model: </del>  The attacker can read, write, and delete arbitrary messages inside the secure transport channel.

I'll add references for QUIC, TLS, IPsec, WireGuard, and TOR. Update: Created
Comment by NAME It is a bit odd to mention a non-IETF VPN protool, but not the IETF VPN protocol. Especially since IPsec also has constant byte stream support via IPTFS that WireGuard does not have :P
This is just a list of examples, it doesn't need to cover everything in the universe. And IETF docs are allowed to mention non-IETF things.

As discussed above, MLS provides the highest level of security when its messages are delivered over a secure transport.  Any secure channel can be used as a transport layer to protect MLS messages,  <ins> such as QUIC RFC9000, TLS RFC8446, IPsec RFC6071, WireGuard WireGuard, or TOR TOR.  However, the MLS protocol is designed to consider the following threat-model: </ins> The attacker can read, write, and delete arbitrary messages inside the secure transport channel.


However, note that a malicious Delivery Service could also reorder messages or provide an inconsistent view to different users.  The <del> protocol is designed such that this only results in a group no longer being functional and the group members possibly detecting this and requesting reinitialization. </del>  Other forms of Delivery Service misbehavior are still possible that are not easy to detect.  For instance, a Delivery Service can simply

Comment by NAME It scares me a bit that this could possibly not be detected at all? What is the scenario where it cannot be detected?
It's actually non-trivial to guarantee detection. Consider a scenario like the following: A, B, C, D are in a group The DS decides to partition the group into (AB) (CD) The DS forwards commits and messages within a partition, but not across partitions. As a result, the two subgroups work fine, but they diverge from each other This will be immediately obvious if two participants in opposite partitions ever try to compare state across the partition boundary, say by checking whether a message arrived or even by comparing the value. But it will be invisible if nobody does -- it just looks like the other partition is offline at the moment. And note that comparing across the partition boundary has to be done out of band, because the DS is blocking in-band comms across the boundary. To prevent this with any reliability, you would need a consensus protocol by which a quorum of members verify that they've received a Commit. And even then, the members outside any particular quorum could be partitioned. In any case, designing a consensus protocol is clearly outside the MLS WG charter. The silver lining here, as the document notes, is that the protocol fails closed. If two members have different views of the group, then they cannot communicate.
This is only true wrt to handshake messages. The DS can still reorder and provide an inconsistent view of application messages. We intentionally punted this to an extension (which I realize now we never specified in the extensions doc) to give applications leeway in the ordering/delivery guarantees provided to application messages. Handshake messages require reliable and in-order but application messages may or may not.

However, note that a malicious Delivery Service could also reorder messages or provide an inconsistent view to different users.  The  <ins> "generation" counter in MLS messages provides per-sender loss detection and ordering that cannot be manipulated by the DS.  A mechanism for more robust protections is discussed in I-D.ietf-mls- extensions.  A DS can cause a partition in the group by partitioning key exchange messages; this can be detected only by out of band comparison (e.g., confirming that all clients have the same "epoch_authenticator" value`). </ins> Other forms of Delivery Service misbehavior are still possible that are not easy to detect.  For instance, a Delivery Service can simply