Question:
Attempt to , . Examples and test vectors not yet updated. PTAL at the description. Is the algorithm accurately described Are things clearer or not
NAME Thanks for all the formatting suggestions. It's cleaned up a bit, although I wasn't able to get aasvg to work. PTAL
Correction. I got aasvg to work but it did not look good at all, probably due to user incompetence. If you would like to submit a PR after this that is prettier, I would welcome it.
Stefan Kolbl points out this problem with the 4-pass method: Indeed, there are ways to avoid ugly and error-prone bit shifting while avoiding this property. In particular, we can always use expand-left, but just padding odd-bytes with zeros to preserve byte boundaries and avoid bit-shifting.
Fixed by
Several problems here: A lot of the description relies on examples rather than normative language. The split of a CID that has an odd length produces HEX sequences with an odd number of characters, which in many circumstances will be interpreted as being (left-)padded with 4 zero bits. If that happened, then bad things would occur. You really need to retain the number of bits. Step 3 passes two arguments to , when it has three. The encryption doesn't bind to the configuration that is in use; instead the high bits of the first octet are set to 0. The formatting of the operations wraps awkwardly. The operators that this uses (^ and primarily) aren't defined. The third input to seems to increment without explanation. Given the examples, I could no doubt work this all out satisfactorily, but that shouldn't be necessary.
Fixed by
A lot.
Yes, the new text seems clear, and correct.

(i.e., the nonce is at least as large as the server ID).  If the server ID is longer, a fourth pass is necessary: <del> "right_0 = right_1 ^ truncate_right( AES_ECB(key, expand_left(left_0, cid_len, 1), len(right_1)) " </del> and the load balancer has to concatenate left_0 and right_0 to obtain the complete server ID.


Question:
Added two sections to Security Considerations (Stateless Reset Oracle and Local Configurations Only). and .
Can you speak a little about your reasoning for the recent changes? If this attack is limited to extracting the identity of server instances for other co-hosted entities, that's probably OK, but I'm having trouble connecting the SHOULD here with the preceding text.
Sure. If an attacker has the same QUIC-LB config as the victim, then it can extract the server mapping, which defeats the whole point of the spec. Obviously, an LB must have the QUIC-LB config for servers it routes to. If I'm an attacker within that group of servers I may already see the packet headers that give away the server mapping, so there's little added linkability here (though there is a little). The moment I share configuration among multiple server pools, I'm expanding the number of entities with access to the config, for no operational benefit except to make the administrator's life easier. In the absurd limit, all of AWS has the same QUIC-LB config, and essentially everyone can extract the server mapping from any CID that goes to AWS.
Add a security consideration to avoid the following scenario: MyCloudProvider has a single QUIC-LB config for all its load balancers. It rotates keys periodically, etc, but everyone gets the same config. Obviously, all the attacker has to do is open an account with MyCloudProvider and it is able to recover all the server IDs. Configs ought to be restricted to load balancers serving a finite set of servers. It is possible another MyCloudProvider customer is in the pool behind that load balancer, but that's already a privileged position as already described in the draft. Obviously, this will require some wordsmithing, as the statement above isn't very precise.
As server clusters increase in size, the need to reallocate server identifiers becomes more acute. In one model, the configuration ID is used to indicate a stable routing configuration. Server identifiers for a given configuration ID are routed to the same server, no matter how many other instances are added or removed. In order to allow for changes in the cluster, the configuration ID is used so that old servers can be removed from consideration and new ones added. If these changes happen frequently enough, the number of bits allocated to identifying a configuration might be insufficient. Why not make the length of the identifier flexible? That might mean that you need to make the length of the length similarly configurable.
It was not the intent of these bits to support long-lived configurations, instead supporting key rotation, upgrades, and the like. I would much rather people overprovisioned the server ID space than using this tool, TBH. However, the only cost is limiting the theoretical size of CIDs. At the moment, we can support up to 64B, future-proofing the encodings against future versions of QUIC. I'm open to another bit for this, but how would a configurable number of CR bits work with multiple configurations? How does a config that needs 5 bits and one that needs 2 coexist, especially if the latter needs length self-encoding?
As we talk through the implications of mutually mistrustful servers in , I think the case for adding another bit is compelling. I'm going to remove the needs-discussion label and come up with a PR that takes another bit.
I'm returning this to needs-discussion, as NAME points out there is a privacy tradeoff here. If the config codespace is large, it's straightforward to have each mistrustful server have its own totally unique config. On the other hand, keeping this long-lived config difference leaks the type of flow. Assuming it's routed based on SNI, it leaks the SNI of each CID, and in that sense also increases linkability.
Alright, I've reflected on this a bit more. In general, different server entities will have different external IP addresses and/or ports, so the load balancer can distinguish the correct QUIC-LB config without resorting to the CR bits. As IP and port are visible to everyone, there is no privacy leakage. The problem occurs when mutually mistrustful servers share the same IP/port and are switched on something else. That "something" may be something present only in the client hello, with the classical load balancer simply using the 4tuple after that. The only thing I am aware of in practice is the SNI. If there are others, please say so in this thread. If the SNI is encrypted, the unprivileged LB envisioned in QUIC-LB does not have access to it. So we can assume this use case only applies to unencrypted SNI. Option 1: mistrustful servers share the same config. a third party will be able to extract your server mapping, but in practice it will be hard for an attacker to obtain this position on purpose. If this is the best outcome, we can stick with 2 config rotation bits. Option 2: Issue them different config rotation codepoints. So an observer can see the SNI and associate it with certain CR bits; if the client later migrates, it will still be able to associate that connection with that SNI. If this is better than Option 1, we should probably add a third config rotation bit. Other (minor) costs of having 3 config rotation bits: length self-encoding can only support 31 byte connection IDs, instead of 63 (obviously this is only relevant for hypothetical future versions of QUIC) each config can have its own set of server IDs. So there is considerably more config state at the LB. As SIDs can be up to 18B, it's 18B x (# of servers) x (# of config rotation codepoints). This memory footprint will roughly double by going from 3 to 7 codepoints. I've talked myself into Option 1 as being a mildly better situation, thus sticking with 2 CR bits.
Update: the ECHO design might allow the LB privileged access to the SNI, so it might be encrypted. However, an attacker could connect to the domains at that IP and obtain the config rotation bits. So option 2 actually circumvents ESNI entirely!
Closing -- I have received no pushback on doing nothing (leaving it at 2 bits), so I'm going to do nothing.
The draft doesn't address the impact of each method of connection ID generation on how servers can use stateless resets. Most of this is likely bound up in decisions stemming from . If you can guess a valid but unused connection ID, then you might be able to induce a stateless reset that could be used to kill an open connection. As the draft only includes methods that include an explicit server identifier, it is possible that as long as valid values cannot be guessed, the effect is minimal and each server instance can have its own configured stateless reset key (or a shared key from which a per-server key is derived using a KDF).
I don't understand the attack here. A given CID will deterministically map to a specific server instance. So there is no way for another server to receive a packet with that CID and generate a stateless reset. What am I missing? There might be something here with the differing treatment of long-header vs. short-header packets, (and the option for servers to send resets on long headers), but I'll have to think about it more.
As to the last point, nope: even a long header with a DCID that conforms to the server's expectations (i.e. maps to a real server) will get delivered to that server, so I don't think that's an attack.
NAME Should we talk about this issue more, or are you satisfied enough that I can close it?
I don't see any mention of stateless reset in the draft at all. That's probably something worth addressing, even if it is to say what you have already.

connection if servers make reasonable selections when generating new IDs for that connection. <ins> 10.3. A simple deployment of QUIC-LB in a cloud provider might use the same global QUIC-LB configuration across all its load balancers that route to customer servers.  An attacker could then simply become a customer, obtain the configuration, and then extract server IDs of other customers' connections at will. To avoid this, the configuration agent SHOULD issue QUIC-LB configurations to mutually distrustful servers that have different keys (for the block cipher or stream cipher algorithms) or routing masks and divisors (for the obfuscated algorithm).  The load balancers can distinguish these configurations by external IP address, or by assigning different values to the config rotation bits (config-rotation).  Note that either of these techniques exposes information to outside observers, as traffic destined for each server set can be easily distinguished. These techniques are not necessary for the plaintext algorithm, as it does not attempt to conceal the server ID. 10.4. Section 21.9 of QUIC-TRANSPORT discusses the Stateless Reset Oracle attack.  For a server deployment to be vulnerable, an attacking client must be able to cause two packets with the same Destination CID to arrive at two different servers that share the same cryptographic context for Stateless Reset tokens.  As QUIC-LB requires deterministic routing of DCIDs over the life of a connection, it is a sufficient means of avoiding an Oracle without additional measures. </ins> 11. There are no IANA requirements.


Question:
The encrypted CID format includes a zero-pad field that is used to detect whether the decryption succeeded or not. I suggest merging this field with the server ID field, and test whether the decryption succeed by checking whether the server ID is valid or not. This assumes that the server ID field is sparsely populated. For example, if there are just 256 servers, in theory a 1-octed field would be sufficient; instead, we could use a 4 or 5 octet server ID field that would be sparsely populated, allowing for error detection. This would allow for unified validity detection across all supported methods: clear text: verify that the server ID is valid; obfuscated: the divider need to have the same size as the full length server ID; the modulo is the server ID; validity can be verified there. stream: decrypt and verify that the server-id is valid encrypt: decrypt and verify that the server-id is valid It would also allows for simplification of the configuration for the encrypted method, by specifying just one field instead of two.
Yes, I agree this is simpler with no cost at all. Care to do a PR?

The extracted server mapping might not correspond to an active server. <del> A field that should be all zeroes after decryption may not be so. </del> Load balancers MUST forward packets with long headers with non- compliant DCIDs to an active server using an algorithm of its own choosing.  It need not coordinate this algorithm with the servers.


Question:
The encrypted CID format includes a zero-pad field that is used to detect whether the decryption succeeded or not. I suggest merging this field with the server ID field, and test whether the decryption succeed by checking whether the server ID is valid or not. This assumes that the server ID field is sparsely populated. For example, if there are just 256 servers, in theory a 1-octed field would be sufficient; instead, we could use a 4 or 5 octet server ID field that would be sparsely populated, allowing for error detection. This would allow for unified validity detection across all supported methods: clear text: verify that the server ID is valid; obfuscated: the divider need to have the same size as the full length server ID; the modulo is the server ID; validity can be verified there. stream: decrypt and verify that the server-id is valid encrypt: decrypt and verify that the server-id is valid It would also allows for simplification of the configuration for the encrypted method, by specifying just one field instead of two.
Yes, I agree this is simpler with no cost at all. Care to do a PR?

The server ID will start in the second octet of the decrypted connection ID and occupy continuous octets beyond that. <del> The configuration agent selects a zero-padding length.  This SHOULD be at least four octets to allow detection of non-compliant DCIDs. The server ID and zero- padding length MUST sum to no more than 16 octets.  They SHOULD sum to no more than 12 octets, to provide servers adequate space to encode their own opaque data. </del> <ins> They server ID length MUST be no more than 16 octets and SHOULD sum to no more than 12 octets, to provide servers adequate space to encode their own opaque data. </ins> The configuration agent also selects an 16-octet AES-ECB key to use for connection ID decryption.


Question:
The encrypted CID format includes a zero-pad field that is used to detect whether the decryption succeeded or not. I suggest merging this field with the server ID field, and test whether the decryption succeed by checking whether the server ID is valid or not. This assumes that the server ID field is sparsely populated. For example, if there are just 256 servers, in theory a 1-octed field would be sufficient; instead, we could use a 4 or 5 octet server ID field that would be sparsely populated, allowing for error detection. This would allow for unified validity detection across all supported methods: clear text: verify that the server ID is valid; obfuscated: the divider need to have the same size as the full length server ID; the modulo is the server ID; validity can be verified there. stream: decrypt and verify that the server-id is valid encrypt: decrypt and verify that the server-id is valid It would also allows for simplification of the configuration for the encrypted method, by specifying just one field instead of two.
Yes, I agree this is simpler with no cost at all. Care to do a PR?

octet to obtain the config rotation bits.  It then decrypts the subsequent 16 octets using AES-ECB decryption and the chosen key. <del> The decrypted plaintext contains the server id, zero padding, and opaque server data in that order.  The load balancer uses the server ID octets for routing. </del> <ins> The decrypted plaintext contains the server id and opaque server data in that order.  The load balancer uses the server ID octets for routing. </ins> 4.4.3. When generating a routable connection ID, the server MUST choose a connection ID length between 17 and 20 octets.  The server writes its <del> provided server ID into the server ID octets, zeroes into the zero- padding octets, and arbitrary bits into the remaining bits.  These arbitrary bits MAY encode additional information.  Bits in the first, eighteenth, nineteenth, and twentieth octets SHOULD appear essentially random to observers.  The first octet is reserved as described in first-octet. </del> <ins> provided server ID into the server ID octets and arbitrary bits into the remaining bits.  These arbitrary bits MAY encode additional information.  Bits in the eighteenth, nineteenth, and twentieth octets SHOULD appear essentially random to observers.  The first octet is reserved as described in first-octet. </ins> The server then encrypts the second through seventeenth octets using the 128-bit AES-ECB cipher.


Question: As the config gets more complicated, the C-ish pseudocode is getting more unwieldy. YANG is the standard for configuration models, so I should bite the bullet and just figure out YANG.

state Retry Service also needs the token key, and to be aware if a NAT sits between it and the servers. <del> The following pseudocode describes the data items necessary to store a full QUIC-LB configuration at the server.  It is meant to describe the conceptual range and not specify the presentation of such configuration in an internet packet.  The comments signify the range of acceptable values where applicable. </del> <ins> yang-model provides a YANG Model of the a full QUIC-LB configuration. </ins> 9.


Question:
RFC8299 and RFC8466 use "inbound-bandwidth" and "outbound-bandwidth" from the point of view of the customer site. L3NM also uses this terminology from the point of view of the customer's site. L2NM flips the terminology, for example "inbound" is from PE's perspective. To avoid confusion, it would better in both L3NM and L2NM to use explicit terminology so that the direction is obvious, e.g. "PE-to-CE-bandwidth" "CE-to-PE-bandwidth" In the description field, it would be good to say which field in RFC8299/RFC8466 this corresponds to.
practically it is ingress-Policer and egress-Shaper, because the BW is controlled only from the PE side. in addition there is policer and shaper per CoS/Queue which should be addressed.
I guess you meant "input-bandwidth" and "output-bandwidth". We do have the following for the L3NM: 'inbound-bandwidth': Indicates, in bits per second (bps), the inbound bandwidth of the connection (i.e., download bandwidth from the service provider to the site). 'outbound-bandwidth': Indicates, in bps, the outbound bandwidth of the connection (i.e., upload bandwidth from the site to the service provider). >L2NM flips the terminology, for example "inbound" is from PE's perspective. 'svc-inbound-bandwidth' indicates the inbound bandwidth of the connection (i.e., download bandwidth from the service provider to the site). 'svc-outbound-bandwidth' indicates the outbound bandwidth of the connection (i.e., upload bandwidth from the site to the service provider). Please note that we do already have the following in the common I-D: "Indicates support for the inbound bandwidth in a VPN. That is, support for specifying the download bandwidth from the service provider network to the VPN site. Note that the L3SM uses 'input' to identify the same feature. That terminology should be deprecated in favor of the one defined in this module."; Which was echoed in the L3NM, e.g., "Note that the L3SM uses 'input- -bandwidth' to refer to the same concept.";
Hi Med In URL it says as follows, maybe it is a typo? container svc-outbound-bandwidth { if-feature "vpn-common:outbound-bw"; description "From the PE perspective, the service outbound bandwidth of the connection."; But I would urge you to change the terminology to "PE-to-CE-bandwidth" /"CE-to-PE-bandwidth" to make it super-explicit, the current terminology has been causing endless confusion to implementers (I realise it's inherited from the service models, but changing the terminology in LXNM would cure the problem well)
This is a typo. It needs to be fixed. Will move this one to the list.
Julian, please check the PR at 7e5286a
Med, this is great, thanks! Can it be changed similarly in L3NM as well? Julian

The bandwidth is per L2VPN service. <del> 'svc-inbound-bandwidth' indicates the inbound bandwidth of the </del> <ins> 'svc-pe-to-ce-bandwidth' indicates the inbound bandwidth of the </ins> connection (i.e., download bandwidth from the service provider to the site). <del> 'svc-outbound-bandwidth' indicates the outbound bandwidth of the </del> <ins> 'svc-ce-to-pe-bandwidth' indicates the outbound bandwidth of the </ins> connection (i.e., upload bandwidth from the site to the service provider).


Question:
Let's also consider data use cases here: Fallback to TURN has a severe effect on throughput in many cases.
Sure, could add a brief note on this.
The text here isn't normative, so I don't think we need to have a lengthy discussion of this - a few words should suffice.
Fixed by
LGTM

away. When mDNS fails, ICE will attempt to fall back to either NAT hairpin, <del> 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). </del> <ins> if supported, or TURN relay if not.  This may result in reduced connectivity, reduced throughput and increased latency, as well as increased cost in case of TURN relay. </ins> One potential mitigation, as discussed in {#privacy}, is to not conceal candidates created from RFC4941 IPv6 addresses.  This permits


Question:
PR for I considered referring to RFC6724, but that raises more questions than it answers it seems.
From Tom Pusateri: When more than one IPv4 or more than one IPv6 address is present, it seems like it would be better to first prefer an address that is on a shared network instead of always taking the first one (which doesn’t mean anything in DNS). If you want others to use the same address you should prefer the lowest one or the highest one or something sortable instead of the first one which could be different depending on hashing in a cache.
Discussed and agreement was to find a simple alternate algorithm.
Closed by PR

".local" name may happen through Unicast DNS as noted in RFC6762, Section 3. <del> An ICE agent that supports mDNS candidates MUST support the situation where the hostname resolution results in more than one IP address. In this case, the ICE agent MUST take exactly one of the resolved IP addresses and ignore the others.  The ICE agent SHOULD use the first IPv6 address resolved, if one exists, or the first IPv4 address, if not. </del> <ins> An ICE agent SHOULD ignore candidates where the hostname resolution returns more than one IP address. </ins> An ICE agent MAY add additional restrictions regarding the ICE candidates it will resolve using mDNS, as this mechanism allows


Question:
Fixes URL
See URL for details
I added a step where we ignore the candidate in that case. The term 'ignore' should probable be refined as it is used both here and in the context of URL We might want to update ignore in URL context.
LGTM

not end with ".local" or if the value contains more than one ".", then process the candidate as defined in RFC8445. <ins> If the ICE candidate policy is "relay", as defined in JSEP, ignore the candidate. </ins> Otherwise, resolve the candidate using mDNS.  The ICE agent SHOULD set the unicast-response bit of the corresponding mDNS query message; this minimizes multicast traffic, as the response is


Question:
PR for
Seems all feedback is addresses?
Host ICE candidates, ICE host candidates, or something else?

section 5.1.1, the candidate is processed as follows: Check whether the ICE agent has a usable registered mDNS hostname <del> resolving to the ICE host candidate's IP address.  If one exists, skip ahead to Step 6. </del> <ins> resolving to the ICE candidate's IP address.  If one exists, skip ahead to Step 6. </ins> Generate a unique mDNS hostname.  The unique name MUST consist of a version 4 UUID as defined in RFC4122, followed by ".local".


Question:
PR for
Seems all feedback is addresses?
Host ICE candidates, ICE host candidates, or something else?

Store the mDNS hostname and its related IP address in the ICE agent for future reuse. <del> Replace the IP address of the ICE host candidate with its mDNS </del> <ins> Replace the IP address of the ICE candidate with its mDNS </ins> hostname, and expose the candidate as usual. An ICE agent can implement this procedure in any way so long as it


Question:
PR for
Seems all feedback is addresses?
Host ICE candidates, ICE host candidates, or something else?

2.2. <del> For any remote host ICE candidate received by the ICE agent, the following procedure is used: </del> <ins> For any remote ICE candidate received by the ICE agent, the following procedure is used: </ins> If the connection-address field value of the ICE candidate does not end with ".local" or if the value contains more than one ".",


Question:
PR for
Seems all feedback is addresses?
Host ICE candidates, ICE host candidates, or something else?

Otherwise, resolve the candidate using mDNS. <del> If it resolves to an IP address, replace the value of the ICE host candidate by the resolved IP address and continue processing of the candidate. </del> <ins> If it resolves to an IP address, replace the mDNS hostname of the ICE candidate with the resolved IP address and continue processing of the candidate. </ins> Otherwise, ignore the candidate.


Question:
PR for
Seems all feedback is addresses?
Host ICE candidates, ICE host candidates, or something else?

A peer-reflexive remote candidate could be learned and constructed from the source transport address of the STUN Binding request as an ICE connectivity check.  The peer-reflexive candidate could share the <del> same address as a remote host ICE candidate that will be signaled or has been signaled, received and is in the process of name resolution. In addition to the elimination procedure of redundant candidates defined in Section 5.1.3 of RFC8445, which could remove constructed peer-reflexive remote candidates, the address of any existing peer- reflexive remote candidate should not be exposed to Web applications by ICE agents that implement this proposal, as detailed in Section #guidelines. </del> <ins> same address as a remote mDNS ICE candidate whose name is in the process of being resolved.  In addition to the elimination procedure of redundant candidates defined in Section 5.1.3 of RFC8445, which could remove constructed peer-reflexive remote candidates, the address of any existing peer-reflexive remote candidate should not be exposed to Web applications by ICE agents that implement this proposal, as detailed in Section #guidelines. </ins> 3.


Question:
PR for
Seems all feedback is addresses?
Host ICE candidates, ICE host candidates, or something else?

When there is no user consent, the following filtering should be done to prevent private IP address leakage: <del> host ICE candidates with an IP address are not exposed as ICE candidate events. </del> <ins> ICE candidates with an IP address are not exposed as ICE candidate events. </ins> Server reflexive ICE candidate raddr field is set to 0.0.0.0 and rport to 0. <del> SDP does not expose any a=candidate line corresponding to a host ICE candidate which contains an IP address. </del> <ins> SDP does not expose any a=candidate line corresponding to an ICE candidate which contains an IP address. </ins> Statistics related to ICE candidates MUST NOT contain the resolved IP address of a remote mDNS candidate or the IP address of a peer-


Question:
Also wrap long lines for #processing section.
Comments addressed, PTAL.
Will wait for NAME approval before merging.
LGTM, updated PR for line wrapping.
The changes to ICE candidate gathering are targeted to web browsers; the changes to ICE candidate processing affect all WebRTC endpoints.
If we add this indication, do we also need to clarify the use case for lite ICE agents?
What did you have in mind?
{{#gathering}} starts with "For any host candidate gathered by an ICE agent as part of {{RFC8445}} section 5.1.1," it seems the place we need to revise to resolve this issue. I was thinking of allowing ICE lite implementation to skip the mDNS wrapping, since lite agents only use host candidates (8445, section 2.5). The lite implementation is however not required restricted to ICE agents that always have public IPs from my reading of that section, but rather an alternative to simplify the implementation when possible. So I am still not sure if it makes sense to say lite ICE can be exempted from wrapping; or instead indicating mDNS wrapping can be skipped if host candidates are equivalent to srflx candidates, and automatically the intended use of lite ICE satisfies this condition.
Right, the public IPs exception probably covers this. also indicates that this is really for web browsers, which are not allowed to implement ICE Lite.
Started writing this up today, but realized it's not totally clear how this should work. The idea would be to use STUN to figure out if an IP is public or not, but... Should we wait to hand out the mDNS candidate until we determine if the IP is private (i.e., STUN finishes)? Should we not hand out the mDNS candidate if we get a srflx candidate that shows the IP is not private? If we hand out the mDNS candidate and then get a srflx candidate that matches the local IP, should we make that a host candidate? Once we learn an IP is not public, should we cache that for future ICE gathering sessions (i.e., not give out mDNS candidates?) The easiest thing would probably be to recommend handing out the mDNS and srflx candidates as usual, but allow implementations to skip mDNS for IPs it has learned are public. (Except for RFC1918 addresses, which would always be treated as private.)
Partially addressed in , will probably include some additional clarifying text once it lands
LGTM

1. As detailed in IPHandling, exposing client private IP addresses by <del> default maximizes the probability of successfully creating direct peer-to-peer connection between two clients, but creates a significant surface for user fingerprinting.  IPHandling recognizes </del> <ins> default to web applications maximizes the probability of successfully creating direct peer-to-peer connections between clients, but creates a significant surface for user fingerprinting.  IPHandling recognizes </ins> this issue, but also admits that there is no current solution to this problem; implementations that choose to use Mode 3 to address the privacy concerns often suffer from failing or suboptimal connections


Question:
Also wrap long lines for #processing section.
Comments addressed, PTAL.
Will wait for NAME approval before merging.
LGTM, updated PR for line wrapping.
The changes to ICE candidate gathering are targeted to web browsers; the changes to ICE candidate processing affect all WebRTC endpoints.
If we add this indication, do we also need to clarify the use case for lite ICE agents?
What did you have in mind?
{{#gathering}} starts with "For any host candidate gathered by an ICE agent as part of {{RFC8445}} section 5.1.1," it seems the place we need to revise to resolve this issue. I was thinking of allowing ICE lite implementation to skip the mDNS wrapping, since lite agents only use host candidates (8445, section 2.5). The lite implementation is however not required restricted to ICE agents that always have public IPs from my reading of that section, but rather an alternative to simplify the implementation when possible. So I am still not sure if it makes sense to say lite ICE can be exempted from wrapping; or instead indicating mDNS wrapping can be skipped if host candidates are equivalent to srflx candidates, and automatically the intended use of lite ICE satisfies this condition.
Right, the public IPs exception probably covers this. also indicates that this is really for web browsers, which are not allowed to implement ICE Lite.
Started writing this up today, but realized it's not totally clear how this should work. The idea would be to use STUN to figure out if an IP is public or not, but... Should we wait to hand out the mDNS candidate until we determine if the IP is private (i.e., STUN finishes)? Should we not hand out the mDNS candidate if we get a srflx candidate that shows the IP is not private? If we hand out the mDNS candidate and then get a srflx candidate that matches the local IP, should we make that a host candidate? Once we learn an IP is not public, should we cache that for future ICE gathering sessions (i.e., not give out mDNS candidates?) The easiest thing would probably be to recommend handing out the mDNS and srflx candidates as usual, but allow implementations to skip mDNS for IPs it has learned are public. (Except for RFC1918 addresses, which would always be treated as private.)
Partially addressed in , will probably include some additional clarifying text once it lands
LGTM

not be supported. This document proposes an overall solution to this problem by <del> 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. </del> <ins> providing a mechanism for WebRTC implementations to register ephemeral mDNS RFC6762 names for local private IP addresses, and then provide those names, rather than the IP addresses, in their ICE candidates.  While this technique is intended to benefit WebRTC implementations in web browsers, by preventing collection of private IP addresses by arbitrary web pages, it can also be used by any endpoint that wants to avoid disclosing information about its local network to remote peers on other networks. WebRTC and WebRTC-compatible endpoints Overview that receive ICE candidates with mDNS names will resolve these names to IP addresses and perform ICE processing as usual.  In the case where the endpoint is a web application, the WebRTC implementation will manage this resolution internally and will not disclose the actual IP addresses to the application. </ins> 2.


Question:
Also wrap long lines for #processing section.
Comments addressed, PTAL.
Will wait for NAME approval before merging.
LGTM, updated PR for line wrapping.
The changes to ICE candidate gathering are targeted to web browsers; the changes to ICE candidate processing affect all WebRTC endpoints.
If we add this indication, do we also need to clarify the use case for lite ICE agents?
What did you have in mind?
{{#gathering}} starts with "For any host candidate gathered by an ICE agent as part of {{RFC8445}} section 5.1.1," it seems the place we need to revise to resolve this issue. I was thinking of allowing ICE lite implementation to skip the mDNS wrapping, since lite agents only use host candidates (8445, section 2.5). The lite implementation is however not required restricted to ICE agents that always have public IPs from my reading of that section, but rather an alternative to simplify the implementation when possible. So I am still not sure if it makes sense to say lite ICE can be exempted from wrapping; or instead indicating mDNS wrapping can be skipped if host candidates are equivalent to srflx candidates, and automatically the intended use of lite ICE satisfies this condition.
Right, the public IPs exception probably covers this. also indicates that this is really for web browsers, which are not allowed to implement ICE Lite.
Started writing this up today, but realized it's not totally clear how this should work. The idea would be to use STUN to figure out if an IP is public or not, but... Should we wait to hand out the mDNS candidate until we determine if the IP is private (i.e., STUN finishes)? Should we not hand out the mDNS candidate if we get a srflx candidate that shows the IP is not private? If we hand out the mDNS candidate and then get a srflx candidate that matches the local IP, should we make that a host candidate? Once we learn an IP is not public, should we cache that for future ICE gathering sessions (i.e., not give out mDNS candidates?) The easiest thing would probably be to recommend handing out the mDNS and srflx candidates as usual, but allow implementations to skip mDNS for IPs it has learned are public. (Except for RFC1918 addresses, which would always be treated as private.)
Partially addressed in , will probably include some additional clarifying text once it lands
LGTM

3.1. <ins> This section outlines how mDNS should be used by ICE agents to conceal local IP addresses.  Naturally, if the ICE agent does not want to conceal its IPs, e.g., if it has a priori knowledge that its addresses are in fact public, this processing is unnecessary. </ins> For any host candidate gathered by an ICE agent as part of RFC8445, Section 5.1.1, the candidate is handled as follows:


Question:
Also wrap long lines for #processing section.
Comments addressed, PTAL.
Will wait for NAME approval before merging.
LGTM, updated PR for line wrapping.
The changes to ICE candidate gathering are targeted to web browsers; the changes to ICE candidate processing affect all WebRTC endpoints.
If we add this indication, do we also need to clarify the use case for lite ICE agents?
What did you have in mind?
{{#gathering}} starts with "For any host candidate gathered by an ICE agent as part of {{RFC8445}} section 5.1.1," it seems the place we need to revise to resolve this issue. I was thinking of allowing ICE lite implementation to skip the mDNS wrapping, since lite agents only use host candidates (8445, section 2.5). The lite implementation is however not required restricted to ICE agents that always have public IPs from my reading of that section, but rather an alternative to simplify the implementation when possible. So I am still not sure if it makes sense to say lite ICE can be exempted from wrapping; or instead indicating mDNS wrapping can be skipped if host candidates are equivalent to srflx candidates, and automatically the intended use of lite ICE satisfies this condition.
Right, the public IPs exception probably covers this. also indicates that this is really for web browsers, which are not allowed to implement ICE Lite.
Started writing this up today, but realized it's not totally clear how this should work. The idea would be to use STUN to figure out if an IP is public or not, but... Should we wait to hand out the mDNS candidate until we determine if the IP is private (i.e., STUN finishes)? Should we not hand out the mDNS candidate if we get a srflx candidate that shows the IP is not private? If we hand out the mDNS candidate and then get a srflx candidate that matches the local IP, should we make that a host candidate? Once we learn an IP is not public, should we cache that for future ICE gathering sessions (i.e., not give out mDNS candidates?) The easiest thing would probably be to recommend handing out the mDNS and srflx candidates as usual, but allow implementations to skip mDNS for IPs it has learned are public. (Except for RFC1918 addresses, which would always be treated as private.)
Partially addressed in , will probably include some additional clarifying text once it lands
LGTM

3.2. <ins> This section outlines how received ICE candidates with mDNS names are processed by ICE agents, and is relevant to all endpoints. </ins> For any remote ICE candidate received by the ICE agent, the following procedure is used:


Question:
Also wrap long lines for #processing section.
Comments addressed, PTAL.
Will wait for NAME approval before merging.
LGTM, updated PR for line wrapping.
The changes to ICE candidate gathering are targeted to web browsers; the changes to ICE candidate processing affect all WebRTC endpoints.
If we add this indication, do we also need to clarify the use case for lite ICE agents?
What did you have in mind?
{{#gathering}} starts with "For any host candidate gathered by an ICE agent as part of {{RFC8445}} section 5.1.1," it seems the place we need to revise to resolve this issue. I was thinking of allowing ICE lite implementation to skip the mDNS wrapping, since lite agents only use host candidates (8445, section 2.5). The lite implementation is however not required restricted to ICE agents that always have public IPs from my reading of that section, but rather an alternative to simplify the implementation when possible. So I am still not sure if it makes sense to say lite ICE can be exempted from wrapping; or instead indicating mDNS wrapping can be skipped if host candidates are equivalent to srflx candidates, and automatically the intended use of lite ICE satisfies this condition.
Right, the public IPs exception probably covers this. also indicates that this is really for web browsers, which are not allowed to implement ICE Lite.
Started writing this up today, but realized it's not totally clear how this should work. The idea would be to use STUN to figure out if an IP is public or not, but... Should we wait to hand out the mDNS candidate until we determine if the IP is private (i.e., STUN finishes)? Should we not hand out the mDNS candidate if we get a srflx candidate that shows the IP is not private? If we hand out the mDNS candidate and then get a srflx candidate that matches the local IP, should we make that a host candidate? Once we learn an IP is not public, should we cache that for future ICE gathering sessions (i.e., not give out mDNS candidates?) The easiest thing would probably be to recommend handing out the mDNS and srflx candidates as usual, but allow implementations to skip mDNS for IPs it has learned are public. (Except for RFC1918 addresses, which would always be treated as private.)
Partially addressed in , will probably include some additional clarifying text once it lands
LGTM

An ICE agent that supports mDNS candidates MUST support the situation where the hostname resolution results in more than one IP address. In this case, the ICE agent MUST take exactly one of the resolved IP <del> addresses and ignore the others.  The ICE agent SHOULD, if available, use the first IPv6 address resolved, otherwise the first IPv4 address. </del> <ins> addresses and ignore the others.  The ICE agent SHOULD use the first IPv6 address resolved, if one exists, or the first IPv4 address, if not. </ins> 4.


Question:
I think this is good to go, will plan to land at EOD.
Does it obfuscate, conceal, or obscure local IP addresses? My vote is for conceal.
Conceal/concealment sgtm.
As noted in , we don't need to use the same term in every case, but the terms should have the same meaning. conceal and hide are fairly synonymous, but conceal and obfuscate have slightly different meanings.
This section is largely normative, so it might make more sense to put some parts from it immediately after Principle, namely the various adjustments to the technique that need to be considered (TURN, IPv6, stats) Things where we merely provide discussion (e.g., session monitoring) rather than normative guidance could remain in the privacy section.
Due to their different sensitivity and lifetime.
If we add this indication, do we also need to clarify the use case for lite ICE agents?
What did you have in mind?
{{#gathering}} starts with "For any host candidate gathered by an ICE agent as part of {{RFC8445}} section 5.1.1," it seems the place we need to revise to resolve this issue. I was thinking of allowing ICE lite implementation to skip the mDNS wrapping, since lite agents only use host candidates (8445, section 2.5). The lite implementation is however not required restricted to ICE agents that always have public IPs from my reading of that section, but rather an alternative to simplify the implementation when possible. So I am still not sure if it makes sense to say lite ICE can be exempted from wrapping; or instead indicating mDNS wrapping can be skipped if host candidates are equivalent to srflx candidates, and automatically the intended use of lite ICE satisfies this condition.
Right, the public IPs exception probably covers this. also indicates that this is really for web browsers, which are not allowed to implement ICE Lite.
Started writing this up today, but realized it's not totally clear how this should work. The idea would be to use STUN to figure out if an IP is public or not, but... Should we wait to hand out the mDNS candidate until we determine if the IP is private (i.e., STUN finishes)? Should we not hand out the mDNS candidate if we get a srflx candidate that shows the IP is not private? If we hand out the mDNS candidate and then get a srflx candidate that matches the local IP, should we make that a host candidate? Once we learn an IP is not public, should we cache that for future ICE gathering sessions (i.e., not give out mDNS candidates?) The easiest thing would probably be to recommend handing out the mDNS and srflx candidates as usual, but allow implementations to skip mDNS for IPs it has learned are public. (Except for RFC1918 addresses, which would always be treated as private.)
Partially addressed in , will probably include some additional clarifying text once it lands
The rest LGTM

want to conceal its IPs, e.g., if it has a priori knowledge that its addresses are in fact public, this processing is unnecessary. <del> For any host candidate gathered by an ICE agent as part of RFC8445, Section 5.1.1, the candidate is handled as follows: </del> <ins> This section outlines how mDNS should be used by ICE agents to conceal local IP addresses. For each host candidate gathered by an ICE agent as part of the gathering process described in RFC8445, Section 5.1.1, the candidate is handled as described below. Check whether this IP address satisfies the ICE agent's policy regarding whether an address is safe to expose.  If so, expose the candidate and abort this process. </ins> Check whether the ICE agent has a usable registered mDNS hostname resolving to the ICE candidate's IP address.  If one exists, skip


Question:
I think this is good to go, will plan to land at EOD.
Does it obfuscate, conceal, or obscure local IP addresses? My vote is for conceal.
Conceal/concealment sgtm.
As noted in , we don't need to use the same term in every case, but the terms should have the same meaning. conceal and hide are fairly synonymous, but conceal and obfuscate have slightly different meanings.
This section is largely normative, so it might make more sense to put some parts from it immediately after Principle, namely the various adjustments to the technique that need to be considered (TURN, IPv6, stats) Things where we merely provide discussion (e.g., session monitoring) rather than normative guidance could remain in the privacy section.
Due to their different sensitivity and lifetime.
If we add this indication, do we also need to clarify the use case for lite ICE agents?
What did you have in mind?
{{#gathering}} starts with "For any host candidate gathered by an ICE agent as part of {{RFC8445}} section 5.1.1," it seems the place we need to revise to resolve this issue. I was thinking of allowing ICE lite implementation to skip the mDNS wrapping, since lite agents only use host candidates (8445, section 2.5). The lite implementation is however not required restricted to ICE agents that always have public IPs from my reading of that section, but rather an alternative to simplify the implementation when possible. So I am still not sure if it makes sense to say lite ICE can be exempted from wrapping; or instead indicating mDNS wrapping can be skipped if host candidates are equivalent to srflx candidates, and automatically the intended use of lite ICE satisfies this condition.
Right, the public IPs exception probably covers this. also indicates that this is really for web browsers, which are not allowed to implement ICE Lite.
Started writing this up today, but realized it's not totally clear how this should work. The idea would be to use STUN to figure out if an IP is public or not, but... Should we wait to hand out the mDNS candidate until we determine if the IP is private (i.e., STUN finishes)? Should we not hand out the mDNS candidate if we get a srflx candidate that shows the IP is not private? If we hand out the mDNS candidate and then get a srflx candidate that matches the local IP, should we make that a host candidate? Once we learn an IP is not public, should we cache that for future ICE gathering sessions (i.e., not give out mDNS candidates?) The easiest thing would probably be to recommend handing out the mDNS and srflx candidates as usual, but allow implementations to skip mDNS for IPs it has learned are public. (Except for RFC1918 addresses, which would always be treated as private.)
Partially addressed in , will probably include some additional clarifying text once it lands
The rest LGTM

Replace the IP address of the ICE candidate with its mDNS hostname and provide the candidate to the web application. <del> An ICE agent can implement this procedure in any way so long as it produces equivalent results to this procedure. </del> <ins> ICE agents can implement this procedure in any way as long as it produces equivalent results.  An implementation may for instance pre- register mDNS hostnames by executing steps 3 to 6 and prepopulate an ICE agent accordingly.  By doing so, only step 7 of the above procedure will be executed at the time of gathering candidates. </ins> <del> An implementation may for instance pre-register mDNS hostnames by executing steps 3 to 5 and prepopulate an ICE agent accordingly.  By doing so, only step 6 of the above procedure will be executed at the time of gathering candidates. </del> <ins> ICE agents may also decide that certain local IP addresses are safe to expose.  This may be because the ICE agent has a priori knowledge that the address is in fact public, or because the agent has made a policy decision to not conceal certain types of IP addresses (e.g., those with built-in privacy protections) as a calculated choice to improve connectivity.  This topic is discussed further in {#privacy} below. </ins> An implementation may also detect that mDNS is not supported by the <del> available network interfaces.  The ICE agent may skip steps 2 and 3 </del> <ins> available network interfaces.  The ICE agent may skip steps 3 and 4 </ins> and directly decide to not expose the host candidate. This procedure ensures that an mDNS name is used to replace only one


Question:
I think this is good to go, will plan to land at EOD.
Does it obfuscate, conceal, or obscure local IP addresses? My vote is for conceal.
Conceal/concealment sgtm.
As noted in , we don't need to use the same term in every case, but the terms should have the same meaning. conceal and hide are fairly synonymous, but conceal and obfuscate have slightly different meanings.
This section is largely normative, so it might make more sense to put some parts from it immediately after Principle, namely the various adjustments to the technique that need to be considered (TURN, IPv6, stats) Things where we merely provide discussion (e.g., session monitoring) rather than normative guidance could remain in the privacy section.
Due to their different sensitivity and lifetime.
If we add this indication, do we also need to clarify the use case for lite ICE agents?
What did you have in mind?
{{#gathering}} starts with "For any host candidate gathered by an ICE agent as part of {{RFC8445}} section 5.1.1," it seems the place we need to revise to resolve this issue. I was thinking of allowing ICE lite implementation to skip the mDNS wrapping, since lite agents only use host candidates (8445, section 2.5). The lite implementation is however not required restricted to ICE agents that always have public IPs from my reading of that section, but rather an alternative to simplify the implementation when possible. So I am still not sure if it makes sense to say lite ICE can be exempted from wrapping; or instead indicating mDNS wrapping can be skipped if host candidates are equivalent to srflx candidates, and automatically the intended use of lite ICE satisfies this condition.
Right, the public IPs exception probably covers this. also indicates that this is really for web browsers, which are not allowed to implement ICE Lite.
Started writing this up today, but realized it's not totally clear how this should work. The idea would be to use STUN to figure out if an IP is public or not, but... Should we wait to hand out the mDNS candidate until we determine if the IP is private (i.e., STUN finishes)? Should we not hand out the mDNS candidate if we get a srflx candidate that shows the IP is not private? If we hand out the mDNS candidate and then get a srflx candidate that matches the local IP, should we make that a host candidate? Once we learn an IP is not public, should we cache that for future ICE gathering sessions (i.e., not give out mDNS candidates?) The easiest thing would probably be to recommend handing out the mDNS and srflx candidates as usual, but allow implementations to skip mDNS for IPs it has learned are public. (Except for RFC1918 addresses, which would always be treated as private.)
Partially addressed in , will probably include some additional clarifying text once it lands
The rest LGTM

increased cost (depending on whether the application chooses to use TURN). <del> The exact impact of this technique is being researched experimentally and will be provided before publication of this document. </del> <ins> One potential mitigation, as discussed in {#privacy}, is to not conceal candidates created from RFC4941 IPv6 addresses.  This permits connectivity even in large internal networks or where mDNS is disabled. The exact impact of the mDNS technique is being researched experimentally and will be provided before publication of this document. </ins> 4.2.


Question:
I think this is good to go, will plan to land at EOD.
Does it obfuscate, conceal, or obscure local IP addresses? My vote is for conceal.
Conceal/concealment sgtm.
As noted in , we don't need to use the same term in every case, but the terms should have the same meaning. conceal and hide are fairly synonymous, but conceal and obfuscate have slightly different meanings.
This section is largely normative, so it might make more sense to put some parts from it immediately after Principle, namely the various adjustments to the technique that need to be considered (TURN, IPv6, stats) Things where we merely provide discussion (e.g., session monitoring) rather than normative guidance could remain in the privacy section.
Due to their different sensitivity and lifetime.
If we add this indication, do we also need to clarify the use case for lite ICE agents?
What did you have in mind?
{{#gathering}} starts with "For any host candidate gathered by an ICE agent as part of {{RFC8445}} section 5.1.1," it seems the place we need to revise to resolve this issue. I was thinking of allowing ICE lite implementation to skip the mDNS wrapping, since lite agents only use host candidates (8445, section 2.5). The lite implementation is however not required restricted to ICE agents that always have public IPs from my reading of that section, but rather an alternative to simplify the implementation when possible. So I am still not sure if it makes sense to say lite ICE can be exempted from wrapping; or instead indicating mDNS wrapping can be skipped if host candidates are equivalent to srflx candidates, and automatically the intended use of lite ICE satisfies this condition.
Right, the public IPs exception probably covers this. also indicates that this is really for web browsers, which are not allowed to implement ICE Lite.
Started writing this up today, but realized it's not totally clear how this should work. The idea would be to use STUN to figure out if an IP is public or not, but... Should we wait to hand out the mDNS candidate until we determine if the IP is private (i.e., STUN finishes)? Should we not hand out the mDNS candidate if we get a srflx candidate that shows the IP is not private? If we hand out the mDNS candidate and then get a srflx candidate that matches the local IP, should we make that a host candidate? Once we learn an IP is not public, should we cache that for future ICE gathering sessions (i.e., not give out mDNS candidates?) The easiest thing would probably be to recommend handing out the mDNS and srflx candidates as usual, but allow implementations to skip mDNS for IPs it has learned are public. (Except for RFC1918 addresses, which would always be treated as private.)
Partially addressed in , will probably include some additional clarifying text once it lands
The rest LGTM

6.4. <ins> Naturally, an address that is already exposed to the Internet does not need to be protected by mDNS, as it can be trivially observed by the web server or remote endpoint.  However, determining this ahead of time is not straightforward; while the fact that an IPv4 address is private can sometimes be inferred by its value, e.g., whether it is an RFC1918 address, the reverse is not necessarily true.  IPv6 addresses present their own complications, e.g., private IPv6 addresses as a result of NAT64 RFC6146. Instead, the determination of whether an address is public can be reliably made as part of the ICE gathering process, namely, if the query to the STUN RFC5389 server returns the same value as the local address.  This can be done for both IPv4 and IPv6 local addresses, provided that the application has configured both IPv4 and IPv6 STUN servers.  If this situation occurs, i.e., STUN returns the same IP address value for an address that has already been communicated as an mDNS candidate during the current ICE gathering phase, the ICE agent MUST NOT eliminate the candidate as redundant and MUST send the IP address as a server-reflexive candidate.  This allows the ICE agent to send mDNS candidates immediately (i.e., without waiting for STUN), even if the associated addresses may not be private. Once an address has been identified as public, the ICE agent MAY cache this information and omit mDNS protection for that address in future ICE gathering phases. 6.5. As noted in IPHandling, private IPv4 addresses are especially problematic because of their unbounded lifetime.  However, the RFC4941 IPv6 addresses recommended for WebRTC have inherent privacy protections, namely a short lifetime and the lack of any stateful information.  Accordingly, implementations MAY choose to not conceal RFC4941 addresses with mDNS names as a tradeoff for improved peer-to- peer connectivity. 6.6. </ins> As noted in IPHandling, privacy may be breached if a web application running in two browsing contexts can determine whether it is running on the same device.  While the approach in this document prevents the


Question:
I think this is good to go, will plan to land at EOD.
Does it obfuscate, conceal, or obscure local IP addresses? My vote is for conceal.
Conceal/concealment sgtm.
As noted in , we don't need to use the same term in every case, but the terms should have the same meaning. conceal and hide are fairly synonymous, but conceal and obfuscate have slightly different meanings.
This section is largely normative, so it might make more sense to put some parts from it immediately after Principle, namely the various adjustments to the technique that need to be considered (TURN, IPv6, stats) Things where we merely provide discussion (e.g., session monitoring) rather than normative guidance could remain in the privacy section.
Due to their different sensitivity and lifetime.
If we add this indication, do we also need to clarify the use case for lite ICE agents?
What did you have in mind?
{{#gathering}} starts with "For any host candidate gathered by an ICE agent as part of {{RFC8445}} section 5.1.1," it seems the place we need to revise to resolve this issue. I was thinking of allowing ICE lite implementation to skip the mDNS wrapping, since lite agents only use host candidates (8445, section 2.5). The lite implementation is however not required restricted to ICE agents that always have public IPs from my reading of that section, but rather an alternative to simplify the implementation when possible. So I am still not sure if it makes sense to say lite ICE can be exempted from wrapping; or instead indicating mDNS wrapping can be skipped if host candidates are equivalent to srflx candidates, and automatically the intended use of lite ICE satisfies this condition.
Right, the public IPs exception probably covers this. also indicates that this is really for web browsers, which are not allowed to implement ICE Lite.
Started writing this up today, but realized it's not totally clear how this should work. The idea would be to use STUN to figure out if an IP is public or not, but... Should we wait to hand out the mDNS candidate until we determine if the IP is private (i.e., STUN finishes)? Should we not hand out the mDNS candidate if we get a srflx candidate that shows the IP is not private? If we hand out the mDNS candidate and then get a srflx candidate that matches the local IP, should we make that a host candidate? Once we learn an IP is not public, should we cache that for future ICE gathering sessions (i.e., not give out mDNS candidates?) The easiest thing would probably be to recommend handing out the mDNS and srflx candidates as usual, but allow implementations to skip mDNS for IPs it has learned are public. (Except for RFC1918 addresses, which would always be treated as private.)
Partially addressed in , will probably include some additional clarifying text once it lands
The rest LGTM

a context that has a different origin than the top-level browsing context), or a private browsing context. <del> 6.5. </del> <ins> 6.7. </ins> Even when local IP addresses are not exposed, the number of mDNS hostname candidates can still provide a fingerprinting dimension.


Question:
On line 421: "that this specification is designed to hide". Could edit that as well.
My take is that we don't need to use the same term in every case, but the terms should have the same meaning. conceal and hide are fairly synonymous, but conceal and obfuscate have slightly different meanings.
Does it obfuscate, conceal, or obscure local IP addresses? My vote is for conceal.
Conceal/concealment sgtm.
As noted in , we don't need to use the same term in every case, but the terms should have the same meaning. conceal and hide are fairly synonymous, but conceal and obfuscate have slightly different meanings.

included in this candidate collection.  However, disclosure of these addresses has privacy implications.  This document describes a way to share local IP addresses with other clients while preserving client <del> privacy.  This is achieved by obfuscating IP addresses with </del> <ins> privacy.  This is achieved by concealing IP addresses with </ins> dynamically generated Multicast DNS (mDNS) names. 1.


Question:
Thanks both, I'll have a look today.
Looks good ! Thanks Richard!
The architecture document mentions PSKs in several places, but does not discuss the security of them. Nor does it discuss the security of External Proposals and External Commits. Notably, the third paragraph of 5.1 Membership Changes says "…the set of devices controlled by the user can only be altered by an authorized member of the group." The set of devices could be altered via an External Commit by a non-member. At the end of 5.2 Parallel Groups there is a vague mention of "using the PSK mechanism to link healing properties among parallel groups.", but no discussion of the security. Likewise Section 5.5 Recovery After State Loss talks about PSKs as the solution to a problem but the risks are not discussed. External Proposals and External Commits should be discussed in section 5.4 Access Control.
NAME I fixed the specific problems you note in

addition or removal of group members without informing all other members. <del> Membership of an MLS group is the managed at the level of individual </del> <ins> Membership of an MLS group is managed at the level of individual </ins> clients.  In most cases, a client corresponds to a specific device used by a user.  If a user has multiple devices, the user will be represented in a group by multiple clients.  If an application wishes


Question:
Thanks both, I'll have a look today.
Looks good ! Thanks Richard!
The architecture document mentions PSKs in several places, but does not discuss the security of them. Nor does it discuss the security of External Proposals and External Commits. Notably, the third paragraph of 5.1 Membership Changes says "…the set of devices controlled by the user can only be altered by an authorized member of the group." The set of devices could be altered via an External Commit by a non-member. At the end of 5.2 Parallel Groups there is a vague mention of "using the PSK mechanism to link healing properties among parallel groups.", but no discussion of the security. Likewise Section 5.5 Recovery After State Loss talks about PSKs as the solution to a problem but the risks are not discussed. External Proposals and External Commits should be discussed in section 5.4 Access Control.
NAME I fixed the specific problems you note in

among parallel groups.  For example, suppose a common member M of two groups A and B has performed a key update in group A but not in group B.  The key update provides PCS with regard to M in group A.  If a <del> PSK exported from group A and injected into group B, then some of </del> <ins> PSK is exported from group A and injected into group B, then some of </ins> these PCS properties carry over to group B, since the PSK and secrets derived from it are only known to the new, updated version of M, not to the old, possibly compromised version of M.


Question:
Thanks both, I'll have a look today.
Looks good ! Thanks Richard!
The architecture document mentions PSKs in several places, but does not discuss the security of them. Nor does it discuss the security of External Proposals and External Commits. Notably, the third paragraph of 5.1 Membership Changes says "…the set of devices controlled by the user can only be altered by an authorized member of the group." The set of devices could be altered via an External Commit by a non-member. At the end of 5.2 Parallel Groups there is a vague mention of "using the PSK mechanism to link healing properties among parallel groups.", but no discussion of the security. Likewise Section 5.5 Recovery After State Loss talks about PSKs as the solution to a problem but the risks are not discussed. External Proposals and External Commits should be discussed in section 5.4 Access Control.
NAME I fixed the specific problems you note in

its prior membership with a PSK. There are a few practical challenges to this approach.  For example, <del> the application will need to ensure that the new members have the </del> <ins> the application will need to ensure that all members have the </ins> required PSK, including any new members that have joined the group since the epoch in which the PSK was issued.


Question: Reverts mlswg/mls-architecture This has not been merged for a reason, namely I don’t want the dependency on an unpublished draft.

agreement properties of MLS will confirm that all members of the group agree on the content of these extensions. <del> 5.8. 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. </del> <ins> 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. </ins> <del> 5.9. </del> <ins> 5.8. </ins> The protocol aims to be compatible with federated environments. While this document does not specify all necessary mechanisms


Question: Reverts mlswg/mls-architecture This has not been merged for a reason, namely I don’t want the dependency on an unpublished draft.

authentication mechanisms, ciphersuites, and infrastructure functionalities. <del> 5.10. </del> <ins> 5.9. </ins> It is important that multiple versions of MLS be able to coexist in the future.  Thus, MLS offers a version negotiation mechanism; this


Question:
Particularly in multi-device scenarios (where a user has more than one device), we should recommend that clients correlate the set of devices of each user across groups. This would make it much harder for a malicious AS to issue fake device credentials for a particular user because clients would expect the credential to appear in all groups of which the user is a member. If a device credential does not appear in all groups after a while, clients have an indication that the credential might have been created without the user's knowledge. This should however only be a recommendation since it might not be a desirable property in all scenarios. In practical terms, users might also need some time to add their new device to all of the groups, therefore a grace period might be needed. Taking the latter into account, correlating users' devices across groups is more of a detection mechanism than a prevention mechanism.
"In many uses of MLS, there are multiple MLS clients which represent a single user (for example a human user with a mobile and desktop version of an application). Often the same set of clients is represented in exactly the same list groups. In applications where this is the case, clients can compare the set of devices of each user across groups. This would make it much harder for a malicious AS to issue fake device credentials for a particular user because clients would expect the credential to appear in all groups of which the user is a member. If a device credential does not appear in all groups after some relatively short period of time, clients have an indication that the credential might have been created without the user's knowledge. As this may take some time, correlating users' devices across groups is more of a detection mechanism than a prevention mechanism."
I lightly edited NAME prose and turned it into PR .
Made a quick pass. I think we should stick with "clients" rather than "devices".

relatively short period of time, clients have an indication that the credential might have been created without the user's knowledge.  Due to the asynchronous nature of MLS, however, there may be transient <del> inconsistencies in a user's device set, so correlating users' clients </del> <ins> inconsistencies in a user's client set, so correlating users' clients </ins> across groups is more of a detection mechanism than a prevention mechanism.


Question: The references at the end of the Security Considerations weren't in kramdown format. Fixed.

Various academic works have analyzed MLS and the different security guarantees it aims to provide.  The security of large parts of the <del> protocol has been analyzed by [BBN19] (draft 7), [ACDT21] (draft 11) and [AJM20] (draft 12). </del> <ins> protocol has been analyzed by BBN19 (draft 7), ACDT21 (draft 11) and AJM20 (draft 12). </ins> Individual components of various drafts of the MLS protocol have been analyzed in isolation and with differing adversarial models, for <del> example, [BBR18], [ACDT19], [ACCKKMPPWY19], [AJM20] and [ACJM20] </del> <ins> example, BBR18, ACDT19, ACCKKMPPWY19, AJM20, ACJM20, and AHKM21 </ins> analyze the ratcheting tree as the sub-protocol of MLS that <del> facilitates key agreement, while [BCK21] analyzes the key derivation paths in the ratchet tree and key schedule.  Finally, [CHK21] analyzes the authentication and cross-group healing guarantees provided by MLS. </del> <ins> facilitates key agreement, while BCK21 analyzes the key derivation paths in the ratchet tree and key schedule.  Finally, CHK21 analyzes the authentication and cross-group healing guarantees provided by MLS. </ins> 8. <del> ACCKKMPPWY19: https://eprint.iacr.org/2019/1489 ACDT19: https://eprint.iacr.org/2019/1189 ACDT21: https://eprint.iacr.org/2021/1083 ACJM20: https://eprint.iacr.org/2020/752 AHKM21: https://eprint.iacr.org/2021/1456 AJM20: https://eprint.iacr.org/2020/1327 BBN19: https://hal.laas.fr/INRIA/hal-02425229 BBR18: https://hal.inria.fr/hal-02425247 BCK21: https://eprint.iacr.org/2021/137 CHK21: https://www.usenix.org/system/files/sec21-cremers.pdf 9. </del> This document makes no requests of IANA.


Question:
For the authors' consideration: Section 3 A member with a valid credential authenticates its MLS messages by signing them with the s/its/it's/ mechanisms for a user to monitor and control which keys are associated to their identity. s/to their/with their/ Operational Requirements A extension can help maintain interoperability s/A extension/An extension/ Whether there should be a extension in groups. s/a extension/an extension/ Forward and Post-Compromise Security MLS partially defend against this problem by active member including freshness, however not s/defend/defends/ s/member/members/ Mandate a key updates from clients that are not otherwise sending messages s/a key/key/ Compromise of AEAD key material authentication is not affected in neither of these s/neither/either/ Compromise of the Group Secrets of a single group for one or more group epochs of the compromised party with no ability to an honest group to recover message secrecy. s/to an/for an/ Compromise by an active adversary with the ability to sign messages the attacker can perform all operations which are available to an legitimate client s/an legitmate/a legitimate/ Compromise of the authentication with access to a signature key Beware that in both oracle and private key access, an active adaptive attacker, can follow th s/attacker, can/attacker can/ Security consideration in the context of a full state compromise They also are providing the strong authentication guarantees to other clients s/providing the strong/providing strong/ hence we consider that their protection by additional security mechanism should be a priority. s/mechanism/mechanisms/ Overall there is no way to detect or prevent these compromise, as discussed s/compromise/compromises/ Privacy of delivery and push notifications For secure messaging systems, push notification are often sent real-time s/notification/notifications/ Authentication Service Compromise MLS client (which is under the control of the user) have often the ability s/have often/often have/
Approved with nits.These changes look good to me.

KT log under a user's identity.  The verification function would correspond to verifying a key's inclusion in the log for a claimed identity, together with the KT log's mechanisms for a user to <del> monitor and control which keys are associated to their identity. </del> <ins> monitor and control which keys are associated with their identity. </ins> By the nature of its roles in MLS authentication, the AS is invested with a large amount of trust and the compromise of one of its


Question:
For the authors' consideration: Section 3 A member with a valid credential authenticates its MLS messages by signing them with the s/its/it's/ mechanisms for a user to monitor and control which keys are associated to their identity. s/to their/with their/ Operational Requirements A extension can help maintain interoperability s/A extension/An extension/ Whether there should be a extension in groups. s/a extension/an extension/ Forward and Post-Compromise Security MLS partially defend against this problem by active member including freshness, however not s/defend/defends/ s/member/members/ Mandate a key updates from clients that are not otherwise sending messages s/a key/key/ Compromise of AEAD key material authentication is not affected in neither of these s/neither/either/ Compromise of the Group Secrets of a single group for one or more group epochs of the compromised party with no ability to an honest group to recover message secrecy. s/to an/for an/ Compromise by an active adversary with the ability to sign messages the attacker can perform all operations which are available to an legitimate client s/an legitmate/a legitimate/ Compromise of the authentication with access to a signature key Beware that in both oracle and private key access, an active adaptive attacker, can follow th s/attacker, can/attacker can/ Security consideration in the context of a full state compromise They also are providing the strong authentication guarantees to other clients s/providing the strong/providing strong/ hence we consider that their protection by additional security mechanism should be a priority. s/mechanism/mechanisms/ Overall there is no way to detect or prevent these compromise, as discussed s/compromise/compromises/ Privacy of delivery and push notifications For secure messaging systems, push notification are often sent real-time s/notification/notifications/ Authentication Service Compromise MLS client (which is under the control of the user) have often the ability s/have often/often have/
Approved with nits.These changes look good to me.

is persistently offline may still be holding old keying material and thus be a threat to both FS and PCS if it is later compromised. <del> MLS partially defend against this problem by active member including freshness, however not much can be done on the inactive side especially in the case where the client has not processed messages. </del> <ins> MLS partially defends against this problem by active members including freshness, however not much can be done on the inactive side especially in the case where the client has not processed messages. </ins> <del> *RECOMMENDATION:* Mandate a key updates from clients that are not </del> <ins> *RECOMMENDATION:* Mandate key updates from clients that are not </ins> otherwise sending messages and evict clients which are idle for too long.


Question:
For the authors' consideration: Section 3 A member with a valid credential authenticates its MLS messages by signing them with the s/its/it's/ mechanisms for a user to monitor and control which keys are associated to their identity. s/to their/with their/ Operational Requirements A extension can help maintain interoperability s/A extension/An extension/ Whether there should be a extension in groups. s/a extension/an extension/ Forward and Post-Compromise Security MLS partially defend against this problem by active member including freshness, however not s/defend/defends/ s/member/members/ Mandate a key updates from clients that are not otherwise sending messages s/a key/key/ Compromise of AEAD key material authentication is not affected in neither of these s/neither/either/ Compromise of the Group Secrets of a single group for one or more group epochs of the compromised party with no ability to an honest group to recover message secrecy. s/to an/for an/ Compromise by an active adversary with the ability to sign messages the attacker can perform all operations which are available to an legitimate client s/an legitmate/a legitimate/ Compromise of the authentication with access to a signature key Beware that in both oracle and private key access, an active adaptive attacker, can follow th s/attacker, can/attacker can/ Security consideration in the context of a full state compromise They also are providing the strong authentication guarantees to other clients s/providing the strong/providing strong/ hence we consider that their protection by additional security mechanism should be a priority. s/mechanism/mechanisms/ Overall there is no way to detect or prevent these compromise, as discussed s/compromise/compromises/ Privacy of delivery and push notifications For secure messaging systems, push notification are often sent real-time s/notification/notifications/ Authentication Service Compromise MLS client (which is under the control of the user) have often the ability s/have often/often have/
Approved with nits.These changes look good to me.

the secrets themselves are protected by HPKE encryption. Note that under that compromise scenario, authentication is not <del> affected in neither of these cases.  As every member of the group can </del> <ins> affected in either of these cases.  As every member of the group can </ins> compute the AEAD keys for all the chains (they have access to the Group Secrets) in order to send and receive messages, the authentication provided by the AEAD encryption layer of the common


Question:
For the authors' consideration: Section 3 A member with a valid credential authenticates its MLS messages by signing them with the s/its/it's/ mechanisms for a user to monitor and control which keys are associated to their identity. s/to their/with their/ Operational Requirements A extension can help maintain interoperability s/A extension/An extension/ Whether there should be a extension in groups. s/a extension/an extension/ Forward and Post-Compromise Security MLS partially defend against this problem by active member including freshness, however not s/defend/defends/ s/member/members/ Mandate a key updates from clients that are not otherwise sending messages s/a key/key/ Compromise of AEAD key material authentication is not affected in neither of these s/neither/either/ Compromise of the Group Secrets of a single group for one or more group epochs of the compromised party with no ability to an honest group to recover message secrecy. s/to an/for an/ Compromise by an active adversary with the ability to sign messages the attacker can perform all operations which are available to an legitimate client s/an legitmate/a legitimate/ Compromise of the authentication with access to a signature key Beware that in both oracle and private key access, an active adaptive attacker, can follow th s/attacker, can/attacker can/ Security consideration in the context of a full state compromise They also are providing the strong authentication guarantees to other clients s/providing the strong/providing strong/ hence we consider that their protection by additional security mechanism should be a priority. s/mechanism/mechanisms/ Overall there is no way to detect or prevent these compromise, as discussed s/compromise/compromises/ Privacy of delivery and push notifications For secure messaging systems, push notification are often sent real-time s/notification/notifications/ Authentication Service Compromise MLS client (which is under the control of the user) have often the ability s/have often/often have/
Approved with nits.These changes look good to me.

secrecy. If the adversary is active, the adversary can follow the protocol and <del> perform updates on behalf of the compromised party with no ability to an honest group to recover message secrecy.  However, MLS provides PCS against active adaptive attackers through its Remove group operation.  This means that, as long as other members of the group are honest, the protocol will guarantee message secrecy for all </del> <ins> perform updates on behalf of the compromised party with no ability for an honest group to recover message secrecy.  However, MLS provides PCS against active adaptive attackers through its Remove group operation.  This means that, as long as other members of the group are honest, the protocol will guarantee message secrecy for all </ins> messages exchanged in the epochs after the compromised party has been removed.


Question:
For the authors' consideration: Section 3 A member with a valid credential authenticates its MLS messages by signing them with the s/its/it's/ mechanisms for a user to monitor and control which keys are associated to their identity. s/to their/with their/ Operational Requirements A extension can help maintain interoperability s/A extension/An extension/ Whether there should be a extension in groups. s/a extension/an extension/ Forward and Post-Compromise Security MLS partially defend against this problem by active member including freshness, however not s/defend/defends/ s/member/members/ Mandate a key updates from clients that are not otherwise sending messages s/a key/key/ Compromise of AEAD key material authentication is not affected in neither of these s/neither/either/ Compromise of the Group Secrets of a single group for one or more group epochs of the compromised party with no ability to an honest group to recover message secrecy. s/to an/for an/ Compromise by an active adversary with the ability to sign messages the attacker can perform all operations which are available to an legitimate client s/an legitmate/a legitimate/ Compromise of the authentication with access to a signature key Beware that in both oracle and private key access, an active adaptive attacker, can follow th s/attacker, can/attacker can/ Security consideration in the context of a full state compromise They also are providing the strong authentication guarantees to other clients s/providing the strong/providing strong/ hence we consider that their protection by additional security mechanism should be a priority. s/mechanism/mechanisms/ Overall there is no way to detect or prevent these compromise, as discussed s/compromise/compromises/ Privacy of delivery and push notifications For secure messaging systems, push notification are often sent real-time s/notification/notifications/ Authentication Service Compromise MLS client (which is under the control of the user) have often the ability s/have often/often have/
Approved with nits.These changes look good to me.

epochs until an honest update from the compromised client happens. Note that under this compromise scenario, the attacker can perform <del> all operations which are available to an legitimate client even </del> <ins> all operations which are available to a legitimate client even </ins> without access to the actual value of the signature key. Without access to the group secrets, the adversary will not have the


Question:
For the authors' consideration: Section 3 A member with a valid credential authenticates its MLS messages by signing them with the s/its/it's/ mechanisms for a user to monitor and control which keys are associated to their identity. s/to their/with their/ Operational Requirements A extension can help maintain interoperability s/A extension/An extension/ Whether there should be a extension in groups. s/a extension/an extension/ Forward and Post-Compromise Security MLS partially defend against this problem by active member including freshness, however not s/defend/defends/ s/member/members/ Mandate a key updates from clients that are not otherwise sending messages s/a key/key/ Compromise of AEAD key material authentication is not affected in neither of these s/neither/either/ Compromise of the Group Secrets of a single group for one or more group epochs of the compromised party with no ability to an honest group to recover message secrecy. s/to an/for an/ Compromise by an active adversary with the ability to sign messages the attacker can perform all operations which are available to an legitimate client s/an legitmate/a legitimate/ Compromise of the authentication with access to a signature key Beware that in both oracle and private key access, an active adaptive attacker, can follow th s/attacker, can/attacker can/ Security consideration in the context of a full state compromise They also are providing the strong authentication guarantees to other clients s/providing the strong/providing strong/ hence we consider that their protection by additional security mechanism should be a priority. s/mechanism/mechanisms/ Overall there is no way to detect or prevent these compromise, as discussed s/compromise/compromises/ Privacy of delivery and push notifications For secure messaging systems, push notification are often sent real-time s/notification/notifications/ Authentication Service Compromise MLS client (which is under the control of the user) have often the ability s/have often/often have/
Approved with nits.These changes look good to me.

compromised parties refresh their credentials securely. Beware that in both oracle and private key access, an active adaptive <del> attacker, can follow the protocol and request to update its own </del> <ins> attacker can follow the protocol and request to update its own </ins> credential.  This in turn induces a signature key rotation which could provide the attacker with part or the full value of the private key depending on the architecture of the service provider.


Question:
For the authors' consideration: Section 3 A member with a valid credential authenticates its MLS messages by signing them with the s/its/it's/ mechanisms for a user to monitor and control which keys are associated to their identity. s/to their/with their/ Operational Requirements A extension can help maintain interoperability s/A extension/An extension/ Whether there should be a extension in groups. s/a extension/an extension/ Forward and Post-Compromise Security MLS partially defend against this problem by active member including freshness, however not s/defend/defends/ s/member/members/ Mandate a key updates from clients that are not otherwise sending messages s/a key/key/ Compromise of AEAD key material authentication is not affected in neither of these s/neither/either/ Compromise of the Group Secrets of a single group for one or more group epochs of the compromised party with no ability to an honest group to recover message secrecy. s/to an/for an/ Compromise by an active adversary with the ability to sign messages the attacker can perform all operations which are available to an legitimate client s/an legitmate/a legitimate/ Compromise of the authentication with access to a signature key Beware that in both oracle and private key access, an active adaptive attacker, can follow th s/attacker, can/attacker can/ Security consideration in the context of a full state compromise They also are providing the strong authentication guarantees to other clients s/providing the strong/providing strong/ hence we consider that their protection by additional security mechanism should be a priority. s/mechanism/mechanisms/ Overall there is no way to detect or prevent these compromise, as discussed s/compromise/compromises/ Privacy of delivery and push notifications For secure messaging systems, push notification are often sent real-time s/notification/notifications/ Authentication Service Compromise MLS client (which is under the control of the user) have often the ability s/have often/often have/
Approved with nits.These changes look good to me.

and changed with each message received by a client. However, the signature private keys are mostly used by clients to <del> send a message.  They also are providing the strong authentication guarantees to other clients, hence we consider that their protection by additional security mechanism should be a priority. </del> <ins> send a message.  They also provide strong authentication guarantees to other clients, hence we consider that their protection by additional security mechanisms should be a priority. </ins> <del> Overall there is no way to detect or prevent these compromise, as </del> <ins> Overall there is no way to detect or prevent these compromises, as </ins> discussed in the previous sections, performing separation of the application secret states can help recovery after compromise, this is the case for signature keys but similar concern exists for the


Question:
For the authors' consideration: Section 3 A member with a valid credential authenticates its MLS messages by signing them with the s/its/it's/ mechanisms for a user to monitor and control which keys are associated to their identity. s/to their/with their/ Operational Requirements A extension can help maintain interoperability s/A extension/An extension/ Whether there should be a extension in groups. s/a extension/an extension/ Forward and Post-Compromise Security MLS partially defend against this problem by active member including freshness, however not s/defend/defends/ s/member/members/ Mandate a key updates from clients that are not otherwise sending messages s/a key/key/ Compromise of AEAD key material authentication is not affected in neither of these s/neither/either/ Compromise of the Group Secrets of a single group for one or more group epochs of the compromised party with no ability to an honest group to recover message secrecy. s/to an/for an/ Compromise by an active adversary with the ability to sign messages the attacker can perform all operations which are available to an legitimate client s/an legitmate/a legitimate/ Compromise of the authentication with access to a signature key Beware that in both oracle and private key access, an active adaptive attacker, can follow th s/attacker, can/attacker can/ Security consideration in the context of a full state compromise They also are providing the strong authentication guarantees to other clients s/providing the strong/providing strong/ hence we consider that their protection by additional security mechanism should be a priority. s/mechanism/mechanisms/ Overall there is no way to detect or prevent these compromise, as discussed s/compromise/compromises/ Privacy of delivery and push notifications For secure messaging systems, push notification are often sent real-time s/notification/notifications/ Authentication Service Compromise MLS client (which is under the control of the user) have often the ability s/have often/often have/
Approved with nits.These changes look good to me.

notification provider have to be trusted to avoid making correlation on which devices are recipients of the same message. <del> For secure messaging systems, push notification are often sent real- </del> <ins> For secure messaging systems, push notifications are often sent real- </ins> time as it is not acceptable to create artificial delays for message retrieval.


Question:
For the authors' consideration: Section 3 A member with a valid credential authenticates its MLS messages by signing them with the s/its/it's/ mechanisms for a user to monitor and control which keys are associated to their identity. s/to their/with their/ Operational Requirements A extension can help maintain interoperability s/A extension/An extension/ Whether there should be a extension in groups. s/a extension/an extension/ Forward and Post-Compromise Security MLS partially defend against this problem by active member including freshness, however not s/defend/defends/ s/member/members/ Mandate a key updates from clients that are not otherwise sending messages s/a key/key/ Compromise of AEAD key material authentication is not affected in neither of these s/neither/either/ Compromise of the Group Secrets of a single group for one or more group epochs of the compromised party with no ability to an honest group to recover message secrecy. s/to an/for an/ Compromise by an active adversary with the ability to sign messages the attacker can perform all operations which are available to an legitimate client s/an legitmate/a legitimate/ Compromise of the authentication with access to a signature key Beware that in both oracle and private key access, an active adaptive attacker, can follow th s/attacker, can/attacker can/ Security consideration in the context of a full state compromise They also are providing the strong authentication guarantees to other clients s/providing the strong/providing strong/ hence we consider that their protection by additional security mechanism should be a priority. s/mechanism/mechanisms/ Overall there is no way to detect or prevent these compromise, as discussed s/compromise/compromises/ Privacy of delivery and push notifications For secure messaging systems, push notification are often sent real-time s/notification/notifications/ Authentication Service Compromise MLS client (which is under the control of the user) have often the ability s/have often/often have/
Approved with nits.These changes look good to me.

The attacker can publish or distribute credentials Infrastructures that provide cryptographic material or credentials in <del> place of the MLS client (which is under the control of the user) have often the ability to use the associated secrets to perform operations on behalf of the user, which is unacceptable in many situations. Other mechanisms can be used to prevent this issue, such as the service blessing cryptographic material used by an MLS client. </del> <ins> place of the MLS client (which is under the control of the user) often have the ability to use the associated secrets to perform operations on behalf of the user, which is unacceptable in many situations.  Other mechanisms can be used to prevent this issue, such as the service blessing cryptographic material used by an MLS client. </ins> *RECOMMENDATION:* Make clients submit signature public keys to the AS, this is usually better than the AS generating public key pairs