Server.  On the other hand, if the HNA signs the Homenet Zone itself, the zone would be collected by the Synchronization Server and directly transferred to the Public Authoritative Server(s).  These <del> policies are discussed and detailed in sec-dnssec-deplyment and sec- views. </del> <ins> policies are discussed and detailed in sec-dnssec-deplyment. </ins> 4.2.


As depicted in fig-naming-arch and fig-auth-servers, the Public Homenet Zone is hosted on the Public Authoritative Server(s), whereas <del> the Homenet Zone is hosted on the HNA.  Motivations for keeping these two zones identical are detailed in sec-views, and this section considers that the HNA builds the zone that will be effectively published on the Public Authoritative Server(s).  In other words "Homenet to Public Zone transformation" is the identity also commonly designated as "no operation" (NOP). </del> <ins> the Homenet Zone is hosted on the HNA.  This section considers that the HNA builds the zone that will be effectively published on the Public Authoritative Server(s).  In other words "Homenet to Public Zone transformation" is the identity also commonly designated as "no operation" (NOP). </ins> In that case, the Homenet Zone should configure its Name Server RRset (NS) and Start of Authority (SOA) with the values associated with the


Reasons for signing the zone by the HNA are: <del> 1) Keeping the Homenet Zone and the Public Homenet Zone equal to </del> <ins> Keeping the Homenet Zone and the Public Homenet Zone equal to </ins> securely optimize DNS resolution.  As the Public Zone is signed with DNSSEC, RRsets are authenticated, and thus DNS responses can be validated even though they are not provided by the


otherwise a resolution with the Public Authoritative Server(s) would be performed. <del> 2) Keeping the Homenet Zone and the Public Homenet Zone equal to </del> <ins> Keeping the Homenet Zone and the Public Homenet Zone equal to </ins> securely address the connectivity disruption independence detailed in RFC7368 section 4.4.1 and 3.7.5.  As local lookups are possible in case of network disruption, communications within the home


lookup would provide DNS as opposed to DNSSEC responses provided by the Public Authoritative Server(s). <del> 3) Keeping the Homenet Zone and the Public Homenet Zone equal to guarantee coherence between DNS responses.  Using a unique zone is one way to guarantee uniqueness of the responses among servers and places.  Issues generated by different views are discussed in more details in sec-views. 4) Privacy and Integrity of the DNSSEC Homenet Zone are better guaranteed.  When the Zone is signed by the HNA, it makes modification of the DNS data -- for example for flow redirection -- impossible.  As a result, signing the Homenet Zone by the HNA provides better protection for end user privacy. </del> <ins> Privacy and Integrity of the DNSSEC Homenet Zone are better guaranteed.  When the Zone is signed by the HNA, it makes modification of the DNS data -- for example for flow redirection -- impossible.  As a result, signing the Homenet Zone by the HNA provides better protection for end user privacy. </ins> Reasons for signing the zone by the Outsourcing Infrastructure are:


7. <del> The Homenet Zone provides information about the home network.  Some users may be tempted to have provide responses dependent on the origin of the DNS query.  More specifically, some users may be tempted to provide a different view for DNS queries originating from the home network and for DNS queries coming from the Internet.  Each view could then be associated with a dedicated Homenet Zone. <!--Regarding {{fig-naming-arch}}, an example of an implementation of two distinct view could be the Homenet Zone that describes the homenet view and the Public Homenet Zone that contains the Internet view, with these two zones being different.--> Note that this document does not specify how DNS queries originating from the home network are addressed to the Homenet Zone.  This could be done via hosting the DNS resolver on the HNA for example. This section is not normative. sec-reasons details why some nodes may only be reachable from the home network and not from the global Internet. sec-consequences briefly describes the consequences of having distinct views such as a "home network view" and an "Internet view".  Finally, sec-guidance provides guidance on how to resolve names that are only significant in the home network, without creating different views. 7.1. The motivation for supporting different views is to provide different answers dependent on the origin of the DNS query, for reasons such as: 1: An end user may want to have services not published on the Internet.  Services like the HNA administration interface that provides the GUI to administer your HNA might not seem advisable to publish on the Internet.  Similarly, services like the mapper that registers the devices of your home network may also not be desirable to be published on the Internet.  In both cases, these services should only be known or used by the network administrator.  To restrict the access of such services, the home network administrator may choose to publish these pieces of information only within the home network, where it might be assumed that the users are more trusted than on the Internet.  Even though this assumption may not be valid, at least this may reduce the surface of any attack. 2: Services within the home network may be reachable using non global IP addresses.  IPv4 and NAT may be one reason.  On the other hand IPv6 may favor link-local or site-local IP addresses.  These IP addresses are not significant outside the boundaries of the home network.  As a result, they MAY be published in the home network view, and SHOULD NOT be published in the Public Homenet Zone. 7.2. Enabling different views leads to a non-coherent naming system. Depending on where resolution is performed, some services will not be available.  This may be especially inconvenient with devices with multiple interfaces that are attached both to the Internet via a 3G/4G interface and to the home network via a WLAN interface. Devices may also cache the results of name resolution, and these cached entries may no longer be valid if a mobile device moves between a homenet connection and an internet connection e.g. a device temporarily loses wifi signal and switches to 3G. Regarding local-scope IP addresses, such devices may end up with poor connectivity.  Suppose, for example, that DNS resolution is performed via the WLAN interface attached to the HNA, and the response provides local-scope IP addresses, but the communication is initiated on the 3G/4G interface.  Communications with local-scope addresses will be unreachable on the Internet, thus aborting the communication.  The same situation occurs if a device is flip / flopping between various WLAN networks. Regarding DNSSEC, if the HNA does not sign the Homenet Zone and outsources the signing process, the two views are different, because one is protected with DNSSEC whereas the other is not.  Devices with multiple interfaces will have difficulty securing the naming resolution, as responses originating from the home network may not be signed. For devices with all its interfaces attached to a single administrative domain, that is to say the home network, or the Internet.  Incoherence between DNS responses may still also occur if the device is able to perform DNS resolutions both using the DNS resolving server of the home network, or one of the ISP.  DNS resolution performed via the HNA or the ISP resolver may be different than those performed over the Internet. 7.3. As documented in sec-consequences, it is RECOMMENDED to avoid different views.  If network administrators choose to implement multiple views, impacts on devices' resolution SHOULD be evaluated. As a consequence, the Homenet Zone is expected to be an exact copy of the Public Homenet Zone.  As a result, services that are not expected to be published on the Internet SHOULD NOT be part of the Homenet Zone, local-scope addresses SHOULD NOT be part of the Homenet Zone, and when possible, the HNA SHOULD sign the Homenet Zone. The Homenet Zone is expected to host public information only.  It is not the scope of the DNS service to define local home network boundaries.  Instead, local scope information is expected to be provided to the home network using local scope naming services. mDNS RFC6762 DNS-SD RFC6763 are two examples of these services.  Currently mDNS is limited to a single link network.  However, future protocols are expected to leverage this constraint as pointed out in RFC7558. 7.4. </del> This section is focused on the Homenet Reverse Zone. Firstly, all considerations for the Homenet Zone apply to the Homenet


This document uses the following terms: Appraisal Policy for Evidence: A set of rules that direct how a <del> verifier evaluates the validity of information about an Attester. </del> <ins> Verifier evaluates the validity of information about an Attester. </ins> Compare /security policy/ in [RFC4949]. Appraisal Policy for Attestation Result: A set of rules that <del> direct how a Relying Party evaluates the validity of information about an Attester.  Compare /security policy/ in [RFC4949]. </del> <ins> direct how a Relying Party uses the evaluation results about an Attester generated by the Verifiers.  Compare /security policy/ in [RFC4949]. </ins> Attestation Result: The evaluation results generated by a Verifier, typically including information about an Attester, where


then accepts B as trustworthy, it can choose to accept B as a Verifier for other Attesters. <ins> As another example, the Relying Party can establish trust in the Verifier by out of band establishment of key material, combined with a protocol like TLS to communicate.  There is an assumption that between the establishment of the trusted key material and the creation of the Evidence, that the Verifier has not been compromised. </ins> Similarly, the Relying Party also needs to trust the Relying Party Owner for providing its Appraisal Policy for Attestation Results, and in some scenarios the Relying Party might even require that the


Relying Party(s). In some cases where Evidence contains sensitive information, an <del> Attester might even require that a Verifier first go through a remote attestation procedure with it before the Attester will send the sensitive Evidence.  This can be done by having the Attester first act as a Verifier/Relying Party, and the Verifier act as its own Attester, as discussed above. </del> <ins> Attester might even require that a Verifier first go through a TLS authentication or a remote attestation procedure with it before the Attester will send the sensitive Evidence.  This can be done by having the Attester first act as a Verifier/Relying Party, and the Verifier act as its own Attester, as discussed above. </ins> 7.3.


first act as an Attester, providing Evidence that the Owner can appraise, before the Owner would give the Relying Party an updated policy that might contain sensitive information.  In such a case, <del> mutual attestation might be needed, in which case typically one side's Evidence must be considered safe to share with an untrusted entity, in order to bootstrap the sequence. </del> <ins> mutual authentication or attestation might be needed, in which case typically one side's Evidence must be considered safe to share with an untrusted entity, in order to bootstrap the sequence. </ins> 7.4.


Verifier Owner may need to trust the Verifier before giving the Endorsement, Reference Values, or Appraisal Policy to it.  This can be done similarly to how a Relying Party might establish trust in a <del> Verifier as discussed above, and in such a case, mutual attestation might even be needed as discussed in rpowner-trust. </del> <ins> Verifier as discussed above, and in such a case, mutual authentication or attestation might even be needed as discussed in rpowner-trust. </ins> 8.


transitively via an Endorser (e.g., the Verifier puts the Endorser's public key into its trust anchor store).  In layered attestation, a root of trust is the initial Attesting Environment.  Claims can be <del> collected from or about each layer.  The corresponding claims can be </del> <ins> collected from or about each layer.  The corresponding Claims can be </ins> structured in a nested fashion that reflects the nesting of the <del> Attester's layers. </del> <ins> Attester's layers.  Normally, Claims are not self-asserted, rather a previous layer acts as the Attesting Environment for the next layer. Claims about a root of trust typically are asserted by Endorsers. </ins> The device illustrated in layered includes (A) a BIOS stored in read- only memory, (B) an updatable bootloader, and (C) an operating system


different _Strength of Function_ strengthoffunction, which results in the Attestation Results being qualitatively different in strength. <del> A result that indicates non-compliance can be used by an Attester (in the passport model) or a Relying Party (in the background-check model) to indicate that the Attester should not be treated as authorized and may be in need of remediation.  In some cases, it may even indicate that the Evidence itself cannot be authenticated as being correct. An Attestation Result that indicates compliance can be used by a Relying Party to make authorization decisions based on the Relying Party's appraisal policy.  The simplest such policy might be to simply authorize any party supplying a compliant Attestation Result signed by a trusted Verifier.  A more complex policy might also entail comparing information provided in the result against Reference Values, or applying more complex logic on such information. </del> <ins> An Attestation Result that indicates non-compliance can be used by an Attester (in the passport model) or a Relying Party (in the background-check model) to indicate that the Attester should not be treated as authorized and may be in need of remediation.  In some cases, it may even indicate that the Evidence itself cannot be authenticated as being correct. By default, the Relying Party does not believe the Attester to be compliant.  Upon receipt of an authentic Attestation Result and given the Appraisal Policy for Attestation Results is satisfied, then the Attester is allowed to perform the prescribed actions or access.  The simplest such Appraisal Policy might authorize granting the Attester full access or control over the resources guarded by the Relying Party. A more complex Appraisal Policy might involve using the information provided in the Attestation Result to compare against expected values, or to apply complex analysis of other information contained in the Attestation Result. </ins> Thus, Attestation Results often need to include detailed information about the Attester, for use by Relying Parties, much like physical


Relying Party or for a Verifier, then integrity of the process is compromised. <del> The security of conveyed information may be applied at different layers, whether by a conveyance protocol, or an information encoding format.  This architecture expects attestation messages (i.e., Evidence, Attestation Results, Endorsements, Reference Values, and Policies) are end-to-end protected based on the role interaction </del> <ins> The security protecting conveyed information may be applied at different layers, whether by a conveyance protocol, or an information encoding format.  This architecture expects attestation messages (i.e., Evidence, Attestation Results, Endorsements, Reference Values, and Policies) are end-to-end protected based on the role interaction </ins> context.  For example, if an Attester produces Evidence that is relayed through some other entity that doesn't implement the Attester or the intended Verifier roles, then the relaying entity should not


measures appropriate for its value. The degree of protection afforded to this key material can vary by <del> device, based upon considerations as to a cost/benefit evaluation of the intended function of the device.  The confidentiality protection is fundamentally based upon some amount of physical protection: while </del> <ins> the intended function of the device and the specific practices of the device manufacturer or integrator.  The confidentiality protection is fundamentally based upon some amount of physical protection: while </ins> encryption is often used to provide confidentiality when a key is conveyed across a factory, where the attestation key is created or applied, it must be available in an unencrypted form.  The physical


constrain the types of information for which the trust anchor is authoritative."  The trust anchor may be a certificate or it may be a raw public key along with additional data if necessary such as its <del> public key algorithm and parameters. </del> <ins> public key algorithm and parameters.  In the context of this document, a trust anchor may also be a symmetric key, as in TCG-DICE- SIBDA or the symmetric mode described in I-D.tschofenig-rats-psa- token. </ins> Thus, trusting a Verifier might be expressed by having the Relying <del> Party store the Verifier's public key or certificate in its trust anchor store, or might be expressed by storing the public key or certificate of an entity (e.g., a Certificate Authority) that is in the Verifier's certificate path.  For example, the Relying Party can </del> <ins> Party store the Verifier's key or certificate in its trust anchor store, or might be expressed by storing the public key or certificate of an entity (e.g., a Certificate Authority) that is in the Verifier's certificate path.  For example, the Relying Party can </ins> verify that the Verifier is an expected one by out of band establishment of key material, combined with a protocol like TLS to communicate.  There is an assumption that between the establishment


As noted in trustmodel, Verifiers and Relying Parties have trust anchor stores that must be secured.  RFC6024 contains more discussion <del> of trust anchor store requirements.  Specifically, a trust anchor store must resist modification against unauthorized insertion, deletion, and modification. </del> <ins> of trust anchor store requirements for protecting public keys. Section 6 of NIST-800-57-p1 contains a comprehensive treatment of the topic, including the protection of symmetric key material. Specifically, a trust anchor store must resist modification against unauthorized insertion, deletion, and modification.  Additionally, if the trust anchor is a symmetric key, the trust anchor store must not allow unauthorized read. </ins> If certificates are used as trust anchors, Verifiers and Relying Parties are also responsible for validating the entire certificate


9. <ins> The conveyance of Evidence and the resulting Attestation Results reveal a great deal of information about the internal state of a device.  In many cases, the whole point of the Attestation process is to provide reliable information about the type of the device and the firmware/software that the device is running.  This information is particularly interesting to many attackers.  For example, knowing that a device is running a weak version of firmware provides a way to aim attacks better. Protocols that convey Evidence or Attestation Results are responsible for detailing what kinds of information are disclosed, and to whom they are exposed. </ins> 10. 11.


2. <ins> The document defines the term "Remote Attestation" as follows: A process by which one entity (the "Attester") provides evidence about its identity and state to another remote entity (the "Relying Party"), which then assesses the Attester's trustworthiness for the Relying Party's own purposes. This document then uses the following terms: Appraisal Policy for Evidence: A set of rules that direct how a verifier evaluates the validity of information about an Attester. Compare /security policy/ in [RFC4949]. Appraisal Policy for Attestation Result: A set of rules that direct how a Relying Party evaluates the validity of information about an Attester.  Compare /security policy/ in [RFC4949]. Attestation Result: The evaluation results generated by a Verifier, typically including information about an Attester, where the Verifier vouches for the validity of the results. Attester: An entity whose attributes must be evaluated in order to determine whether the entity is considered trustworthy, such as when deciding whether the entity is authorized to perform some operation. Endorsement: A secure statement that some entity (typically a manufacturer) vouches for the integrity of an Attester's signing capability. Endorser: An entity that creates Endorsements that can be used to help evaluate trustworthiness of Attesters. Evidence: A set of information about an Attester that is to be evaluated by a Verifier. Relying Party: An entity that depends on the validity of information about another entity, typically for purposes of authorization.  Compare /relying party/ in [RFC4949]. Relying Party Owner: An entity, such as an administrator, that is authorized to configure Appraisal Policy for Attestation Results in a Relying Party. Verifier: An entity that evaluates the validity of Evidence about an Attester. Verifier Owner: An entity, such as an administrator, that is authorized to configure Appraisal Policy for Evidence in a Verifier. [EDITORIAL NOTE] The term Attestation and Remote Attestation are not defined in this document, at this time.  This document will include pointers to industry uses of the terms, in an attempt to gain consensus around the term, and be consistent with the charter text defining this term. </ins> 3. 4. <ins> dataflow depicts the data that flows between different roles, independent of protocol or use case. An Attester creates Evidence that is conveyed to a Verifier. The Verifier uses the Evidence, and any Endorsements from Endorsers, by applying an Evidence Appraisal Policy to assess the trustworthiness of the Attester, and generates Attestation Results for use by Relying Parties.  The Evidence Appraisal Policy might be obtained from an Endorser along with the Endorsements, or might be obtained via some other mechanism such as being configured in the Verifier by an administrator. The Relying Party uses Attestation Results by applying its own Appraisal Policy to make application-specific decisions such as authorization decisions.  The Attestation Result Appraisal Policy might, for example, be configured in the Relying Party by an administrator. </ins> 5. 6. <ins> An Attester consists of at least one Attesting Environment and Attested Environment.  In some implementations, the Attesting and Attested Environments might be combined.  Other implementations might have multiple Attesting and Attested Environments. </ins> 7. <ins> The scope of this document is scenarios for which a Relying Party trusts a Verifier that can evaluate the trustworthiness of information about an Attester.  Such trust might come by the Relying Party trusting the Verifier (or its public key) directly, or might come by trusting an entity (e.g., a Certificate Authority) that is in the Verifier's certificate chain.  The Relying Party might implicitly trust a Verifier (such as in the Verifying Relying Party combination).  Or, for a stronger level of security, the Relying Party might require that the Verifier itself provide information about itself that the Relying Party can use to evaluate the trustworthiness of the Verifier before accepting its Attestation Results. In solutions following the background-check model, the Attester is assumed to trust the Verifier (again, whether directly or indirectly via a Certificate Authority that it trusts), since the Attester relies on an Attestation Result it obtains from the Verifier, in order to access resources. The Verifier trusts (or more specifically, the Verifier's security policy is written in a way that configures the Verifier to trust) a manufacturer, or the manufacturer's hardware, so as to be able to evaluate the trustworthiness of that manufacturer's devices.  In solutions with weaker security, a Verifier might be configured to implicitly trust firmware or even software (e.g., a hypervisor). That is, it might evaluate the trustworthiness of an application component, or operating system component or service, under the assumption that information provided about it by the lower-layer hypervisor or firmware is true.  A stronger level of security comes when information can be vouched for by hardware or by ROM code, especially if such hardware is physically resistant to hardware tampering.  The component that is implicitly trusted is often referred to as a Root of Trust. </ins> 8. 9. <ins> 10. </ins> The conveyance of Evidence and the resulting Attestation Results reveal a great deal of information about the internal state of a device.  In many cases, the whole point of the Attestation process is


for detailing what kinds of information are disclosed, and to whom they are exposed. <del> 10. </del> 11. <ins> 12. </ins> This document does not require any actions by IANA. <del> 12. </del> <ins> 13. </ins> Special thanks go to David Wooten, Joerg Borchert, Hannes Tschofenig, Laurence Lundblade, Diego Lopez, Jessica Fitzgerald-McKay, Frank Xia,


obtained via some other mechanism such as being configured in the Verifier by an administrator. <ins> For example, for some claims the Verifier might check the values of claims in the Evidence against constraints specified in the Appraisal Policy for Evidence.  Such constraints might involve a comparison for equality against reference values, or a check for being in a range bounded by reference values, or membership in a set of reference values, or a check against values in other claims, or any other test. Such reference values might be specified as part of the Appraisal Policy for Evidence itself, or might be obtained from a separate source, such as an Endorsement, and then used by the Appraisal Policy for Evidence.  The actual data format and semantics of a known-good value are specific to claims and implementations.  There is no general purpose format for them or general means for comparison defined in this architecture document.  Similarly, for some claims the Verifier might check the values of claims in the Evidence for membership in a set, or against a range of values, or against known- bad values such as an expiration time.  These reference values may be conveyed to the Verifier as part of an Endorsement or as part of Appraisal Policy or both as these are the two input paths to the Verifier. </ins> The Relying Party uses Attestation Results by applying its own Appraisal Policy to make application-specific decisions such as authorization decisions.  The Attestation Result Appraisal Policy


Issuer completes the issuance flow by computing a blinded response as follows: <ins> This is encoded and transmitted to the client in the following TokenResponse structure: </ins> The rsabssa_blind_sign function is defined in BLINDRSA, Section 5.1.2..  The Issuer generates an HTTP response with status <del> code 200 whose body consists of "blind_sig", with the content type </del> <ins> code 200 whose body consists of TokenResponse, with the content type </ins> set as "message/token-response". 6.3.


TokenChallenge message, along with information about what keys to use when requesting a token from the issuer. <ins> Origins that support this authentication scheme need to handle the following tasks: Select which issuer to use, and configure the issuer name and token-key to include in WWW-Authenticate challenges. Determine a redemption context construction to include in the TokenChallenge, as discussed in context-construction. Select the origin information to include in the TokenChallenge. This can be empty to allow fully cross-origin tokens, a single origin name that matches the origin itself, or a list of origin names containing the origin. </ins> The TokenChallenge message has the following structure: The structure fields are defined as follows:


names for which current connection is not authoritative (according to the TLS certificate). <del> Note that it is possible for the WWW-Authenticate header to include multiple challenges, in order to allow the client to fetch a batch of multiple tokens for future use. For example, the WWW-Authenticate header could look like this: </del> <ins> Caching and pre-fetching of tokens is discussed in caching. </ins> <del> If a client fetches a batch of multiple tokens for future use that are bound to a specific redemption context (the redemption_context in the TokenChallenge was not empty), clients SHOULD discard these tokens upon flushing state such as HTTP cookies COOKIES, or changing networks.  Using these tokens in a context that otherwise would not be linkable to the original context could allow the origin to recognize a client. </del> <ins> Note that it is possible for the WWW-Authenticate header to include multiple challenges.  This allows the origin to indicate support for different token types, issuers, or to include multiple redemption contexts.  For example, the WWW-Authenticate header could look like this: </ins> 2.1.1.


address prefix). An empty redemption context is not bound to any property of the <del> client session. </del> <ins> client session.  Preventing double spending on tokens requires the origin to keep state associated with the redemption context.  The size of this state varies based on the size of the redemption context.  For example, double spend state for unique, per-request redemption contexts does only needs to exist within the scope of the request connection or session.  In contrast, double spend state for empty redemption contexts must be stored and shared across all requests until token-key expiration or rotation. 2.1.2. Clients can generate multiple tokens from a single TokenChallenge, and cache them for future use.  This improves privacy by separating the time of token issuance from the time of token redemption, and also allows clients to avoid any overhead of receiving new tokens via the issuance protocol. Cached tokens can only be redeemed when they match all of the fields in the TokenChallenge: token_type, issuer_name, redemption_context, and origin_info.  Clients ought to store cached tokens based on all of these fields, to avoid trying to redeem a token that does not match.  Note that each token has a unique client nonce, which is sent in token redemption (redemption). If a client fetches a batch of multiple tokens for future use that are bound to a specific redemption context (the redemption_context in the TokenChallenge was not empty), clients SHOULD discard these tokens upon flushing state such as HTTP cookies COOKIES, or changing networks.  Using these tokens in a context that otherwise would not be linkable to the original context could allow the origin to recognize a client. </ins> 2.2.


empty redemption contexts must be stored and shared across all requests until token-key expiration or rotation. <ins> Origins that share redemption contexts, i.e., by using the same redemption context, choosing the same issuer, and providing the same origin_info field in the TokenChallenge, must necessarily share state required to enforce double spend prevention.  Origins should consider the operational complexity of this shared state before choosing to share redemption contexts.  Failure to successfully synchronize this state and use it for double spend prevention can allow Clients to redeem tokens to one Origin that were issued after an interaction with another Origin that shares the context. </ins> 2.1.2. Clients can generate multiple tokens from a single TokenChallenge,


Issuer identity.  Tokens identify which issuers are trusted for a given issuance protocol. <del> Interactive or non-interactive.  Tokens can either be interactive or not.  An interactive token is one which requires a freshly issued token based on the challenge, whereas a non-interactive token can be issued proactively and cached for future use. </del> <ins> Redemption context.  Tokens can be bound to a given redemption context, which influences a client's ability to pre-fetch and cache tokens.  For example, an empty redemption context always allows tokens to be issued and redeemed non-interactively, whereas a fresh and random redemption context means that the redeemed token must be issued only after the client receives the challenge. See Section 2.1.1 of HTTP-Authentication for more details. </ins> Per-origin or cross-origin.  Tokens can be constrained to the Origin for which the challenge originated, or can be used across Origins. Depending on the use case, Origins may need to maintain state to <del> track redeemed tokens.  For example, Origins that accept non- interactive, cross-origin tokens SHOULD track which tokens have been redeemed already, since these tokens can be issued and then spent multiple times in response to any such challenge.  See double-spend for discussion. </del> <ins> track redeemed tokens.  For example, Origins that accept cross-origin across shared redemption contexts tokens SHOULD track which tokens have been redeemed already in those redemption contexts, since these tokens can be issued and then spent multiple times in response to any such challenge.  See Section 2.1.1 of HTTP-Authentication for discussion. </ins> Origins that admit cross-origin tokens bear some risk of allowing tokens issued for one Origin to be spent in an interaction with


reconstruct a Client's browsing history. Attestation and redemption context unlinkability requires that these <del> events be separated over time, e.g., through the use of non- interactive tokens that can be issued without a fresh Origin challenge, or over space, e.g., through the use of an anonymizing proxy when connecting to the Origin. </del> <ins> events be separated over time, e.g., through the use of tokens with an empty redemption context, or over space, e.g., through the use of an anonymizing proxy when connecting to the Origin. </ins> 4.2.


6.1. <del> When applicable for non-interactive tokens, all Origins SHOULD implement a robust storage-query mechanism for checking that tokens sent by clients have not been spent before.  Such tokens only need to be checked for each Origin individually.  But all Origins must perform global double-spend checks to avoid clients from exploiting the possibility of spending tokens more than once against distributed token checking systems.  For the same reason, the global data storage must have quick update times.  While an update is occurring it may be possible for a malicious client to spend a token more than once. 6.2. </del> When a Client holds tokens for an Issuer, it is possible for any verifier to invoke that client to redeem tokens for that Issuer. This can lead to an attack where a malicious verifier can force a


previous variant in two important ways: The output tokens are publicly verifiable by anyone with the <del> Issuer public key; and </del> <ins> Issuer public key. </ins> The issuance protocol does not admit public or private metadata to bind additional context to tokens. <del> Otherwise, this variant is nearly identical.  In particular, Issuers provide a Private and Public Key, denoted skI and pkI, respectively, used to produce tokens as input to the protocol.  See public-issuer- configuration for how this key pair is generated. </del> <ins> The first property means that any Origin can select a given Issuer to produce tokens, as long as the Origin has the Issuer public key, without explicit coordination or permission from the Issuer.  This is because the Issuer does not learn the Origin that requested the token during the issuance protocol. Beyond these differences, the publicly verifiable issuance protocol variant is nearly identical to the privately verifiable issuance protocol variant.  In particular, Issuers provide a Private and Public Key, denoted skI and pkI, respectively, used to produce tokens as input to the protocol.  See public-issuer-configuration for how this key pair is generated. </ins> Clients provide the following as input to the issuance protocol:


Issuer portrayed in fig-overview can be instantiated and deployed in a number of ways.  This section covers some expected deployment models and their corresponding security and privacy considerations. <del> The discussion below assumes non-collusion between entities when operated by separate parties.  Mechanisms for enforcing non-collusion are out of scope for this architecture. </del> <ins> The discussion below assumes non-collusion between entities that have access to the attestation context and entities that have access to the redemption context, as collusion between such entities would enable linking of these contexts.  Generally, this means that entities operated by separate parties do not collude.  Mechanisms for enforcing non-collusion are out of scope for this architecture. </ins> 4.1.


used later as described in private-finalize.  The Client then generates an HTTP POST request to send to the Issuer, with the TokenRequest as the body.  The media type for this request is <del> "message/token-request".  An example request is shown below. </del> <ins> "application/private-token-request".  An example request is shown below. </ins> Upon receipt of the request, the Issuer validates the following conditions:


where Ns is as defined in OPRF, Section 4. The Issuer generates an HTTP response with status code 200 whose body <del> consists of TokenResponse, with the content type set as "message/ token-response". </del> <ins> consists of TokenResponse, with the content type set as "application/ private-token-response". </ins> 5.3.


The Client then generates an HTTP POST request to send to the Issuer, with the TokenRequest as the body.  The media type for this request <del> is "message/token-request".  An example request is shown below, where Nk = 512. </del> <ins> is "application/private-token-request".  An example request is shown below, where Nk = 512. </ins> Upon receipt of the request, the Issuer validates the following conditions:


The rsabssa_blind_sign function is defined in BLINDRSA, Section 5.1.2..  The Issuer generates an HTTP response with status code 200 whose body consists of TokenResponse, with the content type <del> set as "message/token-response". </del> <ins> set as "application/private-token-response". </ins> 6.3.


This specification defines the following protocol messages, along with their corresponding media types: <del> TokenRequest: "message/token-request" </del> <ins> TokenRequest: "application/private-token-request" </ins> <del> TokenResponse: "message/token-response" </del> <ins> TokenResponse: "application/private-token-response" </ins> The definition for each media type is in the following subsections. 8.2.1. <del> message </del> <ins> application </ins> <del> token-request </del> <ins> private-token-request </ins> N/A


8.2.2. <del> message </del> <ins> application </ins> <del> access-token-response </del> <ins> private-token-response </ins> N/A


its own name as one of the names in the list. When used in an authentication challenge, the "PrivateToken" scheme <del> uses the following attributes: </del> <ins> uses the following parameters: </ins> "challenge", which contains a base64url-encoded RFC4648 TokenChallenge value.  Since the length of the challenge is not


and might be required to be a quoted-string if the base64url string includes "=" characters.  This challenge value MUST be unique for every 401 HTTP response to prevent replay attacks. <del> This attribute is required for all challenges. </del> <ins> This parameter is required for all challenges. </ins> "token-key", which contains a base64url encoding of the public key for use with the issuance protocol indicated by the challenge.


include padding.  As an Authentication Parameter ("auth-param" from RFC9110, Section 11.2), the value can be either a token or a quoted-string, and might be required to be a quoted-string if the <del> base64url string includes "=" characters.  This attribute MAY be </del> <ins> base64url string includes "=" characters.  This parameter MAY be </ins> omitted in deployments where clients are able to retrieve the issuer key using an out-of-band mechanism. <del> "max-age", an optional attribute that consists of the number of </del> <ins> "max-age", an optional parameter that consists of the number of </ins> seconds for which the challenge will be accepted by the origin. Clients can ignore the challenge if the token-key is invalid or otherwise untrusted. <del> The header field MAY also include the standard "realm" attribute, if desired.  Issuance protocols MAY require other attributes. </del> <ins> The header field MAY also include the standard "realm" parameter, if desired.  Issuance protocols MAY require other parameters.  Clients SHOULD ignore unknown parameters in challenges, except if otherwise specified by issuance protocols. </ins> As an example, the WWW-Authenticate header field could look like this:


obtains a token at time T2, a colluding issuer and origin can link this to the same client if T2 is unique to the client.  This linkability is less feasible as the number of issuance events at time <del> T2 increases.  Depending on the "max-age" token challenge attribute, </del> <ins> T2 increases.  Depending on the "max-age" token challenge parameter, </ins> clients MAY try to augment the time between getting challenged then redeeming a token so as to make this sort of linkability more difficult.  For more discussion on correlation risks between token


Server functionality: <del> "PP_Server_Setup": Generates server configuration and keys </del> <ins> "ServerSetup": Generates server configuration and keys </ins> <del> "PP_Issue": Run on the contents of the client message in the </del> <ins> "Issue": Run on the contents of the client message in the </ins> issuance phase. <del> "PP_Verify": Run on the contents of the client message in the </del> <ins> "Verify": Run on the contents of the client message in the </ins> redemption phase. Client functionality: <del> "PP_Client_Setup": Generates the client configuration based on the configuration used by a given server. </del> <ins> "ClientSetup": Generates the client configuration based on the configuration used by a given server. </ins> <del> "PP_Generate": Generates public and private data associated with the contents of the client message in the issuance phase. </del> <ins> "Generate": Generates public and private data associated with the contents of the client message in the issuance phase. </ins> <del> "PP_Process": Processes the contents of the server response in the issuance phase. </del> <ins> "Process": Processes the contents of the server response in the issuance phase. </ins> <del> "PP_Redeem": Generates the data that forms the client message in the redemption phase. </del> <ins> "Redeem": Generates the data that forms the client message in the redemption phase. </ins> We will use each of the functions internally in the description of the interfaces that follows.


Steps: <del> Run "(cfg, update) = PP_Server_Setup(id)". </del> <ins> Run "(cfg, update) = ServerSetup(id)". </ins> Construct a "config_update" message.


Run by the client when processing the server response in the issuance phase of the protocol.  The output of this function is an array of "RedemptionToken" objects that are unlinkable from the server's <del> computation in "PP_Issue". </del> <ins> computation in "Issue". </ins> Inputs:


Formally speaking the security model is the following: <del> The adversary runs "PP_Server_Setup" and generates a key-pair "(key, pub_key)". </del> <ins> The adversary runs "ServerSetup" and generates a key-pair "(key, pub_key)". </ins> The adversary specifies a number "Q" of issuance phases to initiate, where each phase "i in 1..Q" consists of "m_i" server evaluations. <del> The adversary runs "PP_Issue" using the key-pair that it generated on each of the client messages in the issuance phase. </del> <ins> The adversary runs "Issue" using the key-pair that it generated on each of the client messages in the issuance phase. </ins> When the adversary wants, it stops the issuance phase, and a random number "l" is picked from "1..Q".


The security model takes the following form: <del> A server is created that runs "PP_Server_Setup" and broadcasts the </del> <ins> A server is created that runs "ServerSetup" and broadcasts the </ins> "ServerUpdate" message "s_update". <del> The adversary runs "PP_Client_Setup" on "s_update". </del> <ins> The adversary runs "ClientSetup" on "s_update". </ins> The adversary specifies a number "Q" of issuance phases to initiate with the server, where each phase "i in 1..Q" consists of


encoded SubjectPublicKeyInfo (SPKI) object carrying pkI.  The SPKI object MUST use the RSASSA-PSS OID RFC5756, which specifies the hash algorithm and salt size.  The salt size MUST match the output size of <del> the hash function associated with the public key and token type. </del> <ins> the hash function associated with the public key and token type.  The parameters field for the digest used in the mask generation function and the digest being signed MUST be omitted. An example sequence of the SPKI object (in ASN.1 format) for a 2048-bit key is below: "$ cat spki.bin | xxd -r -p | openssl asn1parse -dump -inform DER 0:d=0 hl=4 l= 338 cons: SEQUENCE 4:d=1 hl=2 l= 61 cons: SEQUENCE 6:d=2 hl=2 l= 9 prim: OBJECT :rsassaPss 17:d=2 hl=2 l= 48 cons: SEQUENCE 19:d=3 hl=2 l= 13 cons: cont [ 0 ] 21:d=4 hl=2 l= 11 cons: SEQUENCE 23:d=5 hl=2 l= 9 prim: OBJECT :sha384 34:d=3 hl=2 l= 26 cons: cont [ 1 ] 36:d=4 hl=2 l= 24 cons: SEQUENCE 38:d=5 hl=2 l= 9 prim: OBJECT :mgf1 49:d=5 hl=2 l= 11 cons: SEQUENCE 51:d=6 hl=2 l= 9 prim: OBJECT :sha384 62:d=3 hl=2 l= 3 cons: cont [ 2 ] 64:d=4 hl=2 l= 1 prim: INTEGER :30 67:d=1 hl=4 l= 271 prim: BIT STRING " </ins> Since Clients truncate "token_key_id" in each "TokenRequest", Issuers should ensure that the truncated form of new key IDs do not collide


<del> Privacy Pass: The Protocol draft-davidson-pp-protocol-latest </del> <ins> Privacy Pass Protocol Specification draft-ietf-privacypass-protocol-latest </ins> Abstract


<del> Privacy Pass: HTTP API draft-svaldez-pp-http-api-latest </del> <ins> Privacy Pass HTTP API draft-ietf-privacypass-http-api-latest </ins> Abstract


<del> Privacy Pass: Architectural Framework draft-davidson-pp-architecture-latest </del> <ins> Privacy Pass Architectural Framework draft-ietf-privacypass-architecture-latest </ins> Abstract


sections as one BUNDLE group.  However, whether the m= sections are bundle-only or not depends on the BUNDLE policy. <ins> The next step is to generate session-level lip sync groups as defined in RFC5888, Section 7.  For each MediaStream with more than one MediaStreamTrack, a group of type "LS" MUST be added that contains the mid values for each MediaStreamTrack in that MediaStream. </ins> Attributes which SDP permits to either be at the session level or the media level SHOULD generally be at the media level even if they are identical.  This promotes readability, especially if one of a set of


contain all m= sections that were previously bundled, as long as they are still alive, as well as any new m= sections. <ins> The "LS" groups are generated in the same way as with initial offers. </ins> 5.2.3. The createOffer method takes as a parameter an RTCOfferOptions


session-level attributes.  The process here is identical to that indicated in the Initial Offers section above. <ins> The next step is to generate lip sync groups as defined in RFC5888, Section 7.  For each MediaStream with more than one MediaStreamTrack, a group of type "LS" MUST be added that contains the mid values for each MediaStreamTrack in that MediaStream.  In some cases this may result in adding a mid to a given LS group that was not in that LS group in the associated offer.  Although this is not allowed by RFC5888, it is allowed when implementing this specification. </ins> The next step is to generate m= sections for each m= section that is present in the remote offer, as specified in RFC3264, Section 6.  For the purposes of this discussion, any session-level attributes in the


in RFC5956, section 4.3.  For simplicity, if both RTX and FEC are supported, the FEC SSRC MUST be the same as the RTX SSRC. <del> [OPEN ISSUE: Handling of a=imageattr] </del> If the BUNDLE policy for this PeerConnection is set to "max- bundle", and this is not the first m= section, or the BUNDLE policy is set to "balanced", and this is not the first m= section


maximum supported frame sizes out of all codecs included above, as specified in RFC4566, Section 6. <del> If this m= section is for video media, an "a=imageattr" line, as specified in sec.imageattr. </del> <ins> If this m= section is for video media, and there are known limitations on the size of images which can be decoded, an "a=imageattr" line, as specified in sec.imageattr. </ins> If "rtx" is present in the offer, for each primary codec where RTP retransmission should be used, a corresponding "a=rtpmap" line


section 4.3.  For simplicity, if both RTX and FEC are supported, the FEC SSRC MUST be the same as the RTX SSRC. <del> [OPEN ISSUE: Handling of a=imageattr] </del> If a data channel m= section has been offered, a m= section MUST also be generated for data.  The <media> field MUST be set to "application" and the <proto> field MUST be set to exactly match the


Each "m=" and c=" line MUST be filled in with the port, protocol, and address of the default candidate for the m= section, as <del> described in RFC5245, Section 4.3.  Each "a=rtcp" attribute line MUST also be filled in with the port and address of the appropriate default candidate, either the default RTP or RTCP candidate, depending on whether RTCP multiplexing is currently active or not.  Note that if RTCP multiplexing is being offered, but not yet active, the default RTCP candidate MUST be used, as indicated in RFC5761, section 5.1.3.  In each case, if no candidates of the desired type have yet been gathered, dummy values MUST be used, as described above. </del> <ins> described in RFC5245, Section 4.3.  If ICE checking has already completed for one or more candidate pairs and a candidate pair is in active use, then that pair MUST be used, even if ICE has not yet completed.  Note that this differs from the guidance in RFC5245, Section 9.1.2.2, which only refers to offers created when ICE has completed.  Each "a=rtcp" attribute line MUST also be filled in with the port and address of the appropriate default candidate, either the default RTP or RTCP candidate, depending on whether RTCP multiplexing is currently active or not.  Note that if RTCP multiplexing is being offered, but not yet active, the default RTCP candidate MUST be used, as indicated in RFC5761, section 5.1.3.  In each case, if no candidates of the desired type have yet been gathered, dummy values MUST be used, as described above. </ins> Each "a=mid" line MUST stay the same.


For any specified "TIAS" bandwidth value, set this value as a constraint on the maximum RTP bitrate to be used when sending <del> media as specified in RFC3890.  If a "TIAS" value is not </del> <ins> media, as specified in RFC3890.  If a "TIAS" value is not </ins> present, but an "AS" value is specified, generate a "TIAS" value using this formula:


to RTCP.  If more accurate control of bandwidth is needed, "TIAS" should be used instead of "AS". <ins> For any "RR" or "RS" bandwidth values, handle as specified in RFC3556, Section 2. </ins> Any specified "CT" bandwidth value MUST be ignored, as the meaning of this construct at the media level is not well defined. <del> For any "RR" or "RS" bandwidth values, handle as specified in RFC3556, Section 2. </del> [TODO: handling of CN, telephone-event, "red"] If the media section if of type audio:


following restriction: The fields of the "o=" line MUST stay the same except for the <del> <session-version> field, which MUST increment if the session description changes in any way, including the addition of ICE candidates. </del> <ins> <session-version> field, which MUST increment by one on each call to createOffer if the offer might differ from the output of the previous call to createOffer; implementations MAY opt to increment <session-version> on every call.  The value of the generated <session-version> is independent of the <session-version> of the current local description; in particular, in the case where the current version is N, an offer is created with version N+1, and then that offer is rolled back so that the current version is again N, the next generated offer will still have version N+2. Note that if the application creates an offer by reading currentLocalDescription instead of calling createOffer, the returned SDP may be different than when setLocalDescription was originally called, due to the addition of gathered ICE candidates, but the <session-version> will not have changed.  There are no known scenarios in which this causes problems, but if this is a concern, the solution is simply to use createOffer to ensure a unique <session-version>. </ins> If the initial offer was applied using setLocalDescription, but an answer from the remote side has not yet been applied, meaning the


all streams other than the first will be marked as bundle-only. This policy aims to minimize candidate gathering and maximize multiplexing, at the cost of less compatibility with legacy <del> endpoints.  When acting as answerer, if there if no bundle group in the offer, the implementation will reject all but the first m= section. </del> <ins> endpoints.  When acting as answerer, the implementation will reject any m= sections other than the first m= section, unless they are in the same bundle group as that m= section. </ins> As it provides the best tradeoff between performance and compatibility with legacy endpoints, the default bundle policy MUST


No supported codec is present in the offer. <del> The bundle policy is "max-bundle", the m= section is not in a bundle group, and this is not the first m= section. </del> <ins> The bundle policy is "max-bundle", and this is not the first m= section or in the same bundle group as the first m= section. </ins> <del> The bundle policy is "balanced", the m= section is not in a bundle group, and this is not the first m= section for this media type. </del> <ins> The bundle policy is "balanced", and this is not the first m= section for this media type or in the same bundle group as the first m= section for this media type. </ins> The RTP/RTCP multiplexing policy is "require" and the m= section doesn't contain an "a=rtcp-mux" attribute.


The PeerConnection constructor allows the application to specify global parameters for the media session, such as the STUN/TURN servers and credentials to use when gathering candidates.  The size <del> of the ICE candidate pool can also be set, if desired; by default the candidate pool size is zero.  [[OPEN ISSUE: this is an inconsistency with the W3C spec https://github.com/rtcweb-wg/jsep/issues/12.]] </del> <ins> of the ICE candidate pool can also be set, if desired.  If the application does not indicate a candidate pool size, the browser may select any default candidate pool size. </ins> In addition, the application can specify its preferred policy regarding use of BUNDLE, the multiplexing mechanism defined in I-


4.2.4. <ins> The direction method returns the last value passed into setDirection. If setDirection has never been called, it returns the direction the transceiver was initialized with. 4.2.5. The currentDirection method returns the last negotiated direction for the transceiver's associated m= section.  More specifically, it returns the RFC3264 directional attribute of the associated m= section in the last applied answer, with "send" and "recv" directions reversed if it was a remote answer.  For example, if the directional attribute for the associated m= section in a remote answer is "recvonly", currentDirection returns "sendonly". If an answer that references this transceiver has not yet been applied, or if the transceiver is stopped, currentDirection returns null. 4.2.6. </ins> The setCodecPreferences method sets the codec preferences of a transceiver, which in turn affect the presence and order of codecs of the associated m= section on future calls to createOffer and


3.7. <del> JSEP supports simulcast of a MediaStreamTrack, where multiple encodings of the source media can be transmitted within the context of a single m= section.  The current JSEP API is designed to allow applications to send simulcasted media but only to receive a single encoding.  This allows for multi-user scenarios where each sending client sends multiple encodings to a server, which then, for each receiving client, chooses the appropriate encoding to forward. </del> <ins> JSEP supports simulcast transmission of a MediaStreamTrack, where multiple encodings of the source media can be transmitted within the context of a single m= section.  The current JSEP API is designed to allow applications to send simulcasted media but only to receive a single encoding.  This allows for multi-user scenarios where each sending client sends multiple encodings to a server, which then, for each receiving client, chooses the appropriate encoding to forward. </ins> Applications request support for simulcast by configuring multiple encodings on an RTPSender, which, upon generation of an offer or


RFC4566 is the base SDP specification and MUST be implemented. RFC5764 MUST be supported for signaling the UDP/TLS/RTP/SAVPF <del> RFC5764, TCP/DTLS/RTP/SAVPF I-D.nandakumar-mmusic-proto-iana- registration, "UDP/DTLS/SCTP" I-D.ietf-mmusic-sctp-sdp, and "TCP/DTLS/SCTP" I-D.ietf-mmusic-sctp-sdp RTP profiles. </del> <ins> RFC5764, TCP/DTLS/RTP/SAVPF RFC7850, "UDP/DTLS/SCTP" I-D.ietf- mmusic-sctp-sdp, and "TCP/DTLS/SCTP" I-D.ietf-mmusic-sctp-sdp RTP profiles. </ins> RFC5245 MUST be implemented for signaling the ICE credentials and candidate lines corresponding to each media stream.  The ICE


To properly indicate use of DTLS, the <proto> field MUST be set to "UDP/TLS/RTP/SAVPF", as specified in RFC5764, Section 8, if the default candidate uses UDP transport, or "TCP/DTLS/RTP/SAVPF", as <del> specified in I-D.nandakumar-mmusic-proto-iana-registration if the default candidate uses TCP transport. </del> <ins> specified in RFC7850 if the default candidate uses TCP transport. </ins> If codec preferences have been set for the associated transceiver, media formats MUST be generated in the corresponding order, and


clearer. Session Information ("i="), URI ("u="), Email Address ("e="), <del> Phone Number ("p="), Bandwidth ("b="), Repeat Times ("r="), and Time Zones ("z=") lines are not useful in this context and SHOULD NOT be included. </del> <ins> Phone Number ("p="), Repeat Times ("r="), and Time Zones ("z=") lines are not useful in this context and SHOULD NOT be included. </ins> Encryption Keys ("k=") lines do not provide sufficient security and MUST NOT be included.


JSEP's handling of session descriptions is simple and straightforward.  Whenever an offer/answer exchange is needed, the initiating side creates an offer by calling a createOffer() API.  The <del> application optionally modifies that offer, and then uses it to set up its local config via the setLocalDescription() API.  The offer is then sent off to the remote side over its preferred signaling mechanism (e.g., WebSockets); upon receipt of that offer, the remote party installs it using the setRemoteDescription() API. </del> <ins> application then uses that offer to set up its local config via the setLocalDescription() API.  The offer is finally sent off to the remote side over its preferred signaling mechanism (e.g., WebSockets); upon receipt of that offer, the remote party installs it using the setRemoteDescription() API. </ins> To complete the offer/answer exchange, the remote party uses the createAnswer() API to generate an appropriate answer, applies it


the ICE candidate event.  If the pool becomes depleted, either because a larger-than-expected number of ICE components is used, or because the pool has not had enough time to gather candidates, the <del> remaining candidates are gathered as usual. </del> <ins> remaining candidates are gathered as usual.  This only occurs for the first offer/answer exchange, after which the candidate pool is emptied and no longer used. </ins> One example of where this concept is useful is an application that expects an incoming call at some point in the future, and wants to


createOffer to generate new ICE credentials, for the purpose of forcing an ICE restart and kicking off a new gathering phase, in which the new servers will be used.  If the ICE candidate pool has <del> a nonzero size, any existing candidates will be discarded, and new candidates will be gathered from the new servers. </del> <ins> a nonzero size, and a local description has not yet been applied, any existing candidates will be discarded, and new candidates will be gathered from the new servers. </ins> Any change to the ICE candidate policy affects the next gathering phase.  If an ICE gathering phase has already started or


until a gathering phase occurs, and so any necessary filtering can still be done on any pooled candidates. <del> Any changes to the ICE candidate pool size take effect </del> <ins> The ICE candidate pool size MUST NOT be changed after applying a local description.  If a local description has not yet been applied, any changes to the ICE candidate pool size take effect </ins> immediately; if increased, additional candidates are pre-gathered; if decreased, the now-superfluous candidates are discarded.


accordingly, as described in I-D.ietf-mmusic-sdp-bundle-negotiation, Section 8.2. <ins> If the description is of type "answer", and there are still remaining candidates in the ICE candidate pool, discard them. </ins> 6. Note: The following algorithm does not yet have WG consensus but is


but also will offer "a=rtcp-mux", thus allowing for compatibility with either multiplexing or non-multiplexing endpoints. <del> The JSEP implementation will only gather RTP candidates.  This halves the number of candidates that the offerer needs to gather. Applying a description with an m= section that does not contain an "a=rtcp-mux" attribute will cause an error to be returned. </del> <ins> The JSEP implementation will only gather RTP candidates and will insert an "a=rtcp-mux-only" indication into any offers it generates.  This halves the number of candidates that the offerer needs to gather.  Applying a description with an m= section that does not contain an "a=rtcp-mux" attribute will cause an error to be returned. </ins> The default multiplexing policy MUST be set to "require". Implementations MAY choose to reject attempts by the application to


An "a=rtcp-mux" line, as specified in RFC5761, Section 5.1.3. <ins> If the RTP/RTCP multiplexing policy is "require", an "a=rtcp-mux- only" line, as specified in I-D.ietf-mmusic-mux-exclusive, Section 4. </ins> An "a=rtcp-rsize" line, as specified in RFC5506, Section 5. Lastly, if a data channel has been created, a m= section MUST be


The "a=rtcp-mux" line MUST only be added if present in the most recent answer. <del> The "a=rtcp-mux-only" line MUST only be added if present in the most recent answer. </del> The "a=rtcp-rsize" line MUST only be added if present in the most recent answer.


attribute MUST NOT be specified. If the RTP/RTCP multiplexing policy is "require", each m= section <del> MUST contain an "a=rtcp-mux" attribute. </del> <ins> MUST contain an "a=rtcp-mux" attribute.  If an "m=" section contains an "a=rtcp-mux-only" attribute then that section MUST also contain an "a=rtcp-mux" attribute. </ins> If this session description is of type "pranswer" or "answer", the following additional checks are applied:


TRANSPORT categories for bundled m= sections, as described in I- D.ietf-mmusic-sdp-bundle-negotiation, Section 8.1. <ins> Note that if media m= sections are bundled into a data m= section, then certain TRANSPORT and IDENTICAL attributes may appear in the data m= section even if they would otherwise only be appropriate for a media m= section (e.g., "a=rtcp-mux").  This cannot happen in initial offers because in the initial offer JSEP implementations always list media m= sections (if any) before the data m= section (if any), and at least one of those media m= sections will not have the "a=bundle-only" attribute.  Therefore, in initial offers, any "a=bundle-only" m= sections will be bundled into a preceding non-bundle-only media m= section. </ins> The "a=group:BUNDLE" attribute MUST include the MID identifiers specified in the bundle group in the most recent answer, minus any m= sections that have been marked as rejected, plus any newly added or


If a data channel m= section has been offered, a m= section MUST also be generated for data.  The <media> field MUST be set to "application" and the <proto> and "fmt" fields MUST be set to exactly <del> match the fields in the offer. </del> <ins> match the fields in the offer.  Note that if media m= sections are bundled into a data m= section, then certain TRANSPORT and IDENTICAL attributes may appear in the data m= section even if they would otherwise only be appropriate for a media m= section (e.g., "a=rtcp- mux"). </ins> Within the data m= section, an "a=mid" line MUST be generated and included as described above, along with an "a=sctp-port" line


excluded by subsequent calls to createOffer and createAnswer, in which case the corresponding media formats in the associated m= section will be excluded.  The codec preferences cannot add media <del> formats that would otherwise not be present.  This includes codecs that were not negotiated in a previous offer/answer exchange that included the transceiver. </del> <ins> formats that would otherwise not be present. </ins> The codec preferences of an RtpTransceiver can also determine the order of codecs in subsequent calls to createOffer and createAnswer,


For each offered m= section, if any of the following conditions are true, the corresponding m= section in the answer MUST be marked as rejected by setting the port in the m= line to zero, as indicated in <del> RFC3264, Section 6., and further processing for this m= section can be skipped: </del> <ins> RFC3264, Section 6, and further processing for this m= section can be skipped: </ins> The associated RtpTransceiver has been stopped. <del> No supported codec is present in the offer. </del> <ins> None of the offered media formats are supported and, if applicable, allowed by codec preferences. </ins> The bundle policy is "max-bundle", and this is not the first m= section or in the same bundle group as the first m= section.


for the corresponding m= line in the offer. If codec preferences have been set for the associated transceiver, <del> media formats MUST be generated in the corresponding order, and MUST exclude any codecs not present in the codec preferences or not present in the offer.  Note that non-JSEP endpoints are not subject to this restriction, and might add media formats in the answer that are not present in the offer, as specified in RFC3264, Section 6.1.  Therefore, JSEP implementations MUST be prepared to receive such answers. Unless excluded by the above restrictions, the media formats MUST include the mandatory audio/video codecs as specified in RFC7874, Section 3, and RFC7742, Section 5. </del> <ins> media formats MUST be generated in the corresponding order, regardless of what was offered, and MUST exclude any codecs not present in the codec preferences. Otherwise, the media formats on the m= line MUST be generated in the same order as those offered in the current remote description, excluding any currently unsupported formats.  Any currently available media formats that are not present in the current remote description MUST be added after all existing formats. In either case, the media formats in the answer MUST include at least one format that is present in the offer, but MAY include formats that are locally supported but not present in the offer, as mentioned in RFC3264, Section 6.1.  If no common format exists, the m= section is rejected as described above. </ins> The m= line MUST be followed immediately by a "c=" line, as specified in RFC4566, Section 5.7.  Again, as no candidates are available yet,


must instead match what was supplied in the offer, as described above. <del> Unless codec preferences have been set for the associated transceiver, the media formats on the m= line MUST be generated in the same order as in the current local description. </del> Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless the m= section is restarting, in which case new ICE credentials must be created as specified in RFC5245, Section 9.2.1.1.  If the


local answers, "recvonly" for remote answers, or "sendrecv" for either type of answer), choose the media format to send as the most preferred media format from the remote description that is <del> also present in the answer, as described in RFC3264, Sections 6.1 and 7, and start transmitting RTP media once the underlying transport layers have been established.  If an SSRC has not already been chosen for this outgoing RTP stream, choose a random one.  If media is already being transmitted, the same SSRC SHOULD be used unless the clockrate of the new codec is different, in which case a new SSRC MUST be chosen, as </del> <ins> also locally supported, as discussed in RFC3264, Sections 6.1 and 7, and start transmitting RTP media using that format once the underlying transport layers have been established.  If an SSRC has not already been chosen for this outgoing RTP stream, choose a random one.  If media is already being transmitted, the same SSRC SHOULD be used unless the clockrate of the new codec is different, in which case a new SSRC MUST be chosen, as </ins> specified in RFC7160, Section 3.1. The payload type mapping from the remote description is used to


If the RTP/RTCP multiplexing policy is "require", each m= section MUST contain an "a=rtcp-mux" attribute.  If an m= section contains <del> an "a=rtcp-mux-only" attribute then that section MUST also contain an "a=rtcp-mux" attribute. </del> <ins> an "a=rtcp-mux-only" attribute, that section MUST also contain an "a=rtcp-mux" attribute. </ins> <del> If this m= section was present in the previous answer then the state of RTP/RTCP multiplexing MUST match what was previously negotiated. </del> <ins> If an m= section was present in the previous answer, the state of RTP/RTCP multiplexing MUST match what was previously negotiated. </ins> If this session description is of type "pranswer" or "answer", the following additional checks are applied:


If present, "a=msid" attributes MUST be parsed as specified in I- D.ietf-mmusic-msid, Section 3.2, and their values stored, ignoring <del> any "appdata" field. </del> <ins> any "appdata" field.  If no "a=msid" attributes are present, a random msid-id value is generated for a "default" MediaStream for the session, if not already present, and this value is stored. </ins> Any "a=imageattr" attributes MUST be parsed as specified in RFC6236, Section 3, and their values stored.


The setConfiguration method allows the global configuration of the PeerConnection, which was initially set by constructor parameters, to <del> be changed during the session.  The effects of this method call </del> <ins> be changed during the session.  The effects of calling this method </ins> depend on when it is invoked, and they will differ, depending on which specific parameters are changed: <del> This call may result in a change to the state of the ICE agent. </del> <ins> Calling this method may result in a change to the state of the ICE agent. </ins> 4.1.17.


4.2.2. The stopped property indicates whether the transceiver has been <del> stopped, either by a call to stopTransceiver or by applying an answer that rejects the associated "m=" section.  In either of these cases, it is set to "true" and otherwise will be set to "false". </del> <ins> stopped, either by a call to stop or by applying an answer that rejects the associated "m=" section.  In either of these cases, it is set to "true" and otherwise will be set to "false". </ins> A stopped RtpTransceiver does not send any outgoing RTP or RTCP or process any incoming RTP or RTCP.  It cannot be restarted.


affects the direction property of the associated "m=" section on future calls to createOffer and createAnswer.  The permitted values for direction are "recvonly", "sendrecv", "sendonly", and "inactive", <del> mirroring the identically named directional attributes defined in </del> <ins> mirroring the identically named direction attributes defined in </ins> RFC4566. When creating offers, the transceiver direction is directly reflected


The currentDirection property indicates the last negotiated direction for the transceiver's associated "m=" section.  More specifically, it <del> indicates the directional attribute RFC3264 of the associated "m=" </del> <ins> indicates the direction attribute RFC3264 of the associated "m=" </ins> section in the last applied answer (including provisional answers), with "send" and "recv" directions reversed if it was a remote answer. <del> For example, if the directional attribute for the associated "m=" </del> <ins> For example, if the direction attribute for the associated "m=" </ins> section in a remote answer is "recvonly", currentDirection is set to "sendonly".


packets in response to Initial packets that don't include a valid token. <del> Both server and service must have access to Universal time, though tight synchronization is unnecessary. </del> <ins> Both server and service must have time synchronized with respect to one another to prevent tokens being incorrectly marked as expired, though tight synchronization is unnecessary. </ins> The tokens are protected using AES128-GCM AEAD, as explained in token-protection-with-aead.  All tokens, generated by either the


6. <del> For protocols where 4-tuple load balancing is sufficient, it is straightforward to deliver ICMP packets from the network to the correct server, by reading the echoed IP and transport-layer headers to obtain the 4-tuple.  When routing is based on connection ID, further measures are required, as most QUIC packets that trigger ICMP responses will only contain a client-generated connection ID that contains no routing information. To solve this problem, load balancers MAY maintain a mapping of Client IP and port to server ID based on recently observed packets. Alternatively, servers MAY implement the technique described in Section 14.4.1 of RFC9000 to increase the likelihood a Source Connection ID is included in ICMP responses to Path Maximum Transmission Unit (PMTU) probes.  Load balancers MAY parse the echoed packet to extract the Source Connection ID, if it contains a QUIC long header, and extract the Server ID as if it were in a Destination CID. </del> <ins> QUIC-LB requires no per-connection state at the load balancer.  The load balancer can extract the server ID from the connection ID of each incoming packet and route that packet accordingly. However, once the routing decision has been made, the load balancer MAY associate the 4-tuple with the decision.  This has two advantages: The load balancer only extracts the server ID once per incoming 4-tuple.  When the CID is encrypted, this substantially reduces computational load. Incoming Stateless Reset packets and ICMP messages are easily routed to the correct origin server. In addition to the increased state requirements, however, load balancers cannot detect the CONNECTION_CLOSE frame to indicate the end of the connection, so they rely on a timeout to delete connection state.  There are numerous considerations around setting such a timeout. In the event a connection ends, freeing an IP and port, and a different connection migrates to that IP and port before the timeout, the load balancer will misroute the different connection's packets to the original server.  A short timeout limits the likelihood of such a misrouting. Furthermore, if a short timeout causes premature deletion of state, the routing is easily recoverable by decoding an incoming Connection ID.  However, a short timeout also reduces the chance that an incoming Stateless Reset is correctly routed. Servers MAY implement the technique described in Section 14.4.1 of RFC9000 in case the load balancer is stateless, to increase the likelihood a Source Connection ID is included in ICMP responses to Path Maximum Transmission Unit (PMTU) probes.  Load balancers MAY parse the echoed packet to extract the Source Connection ID, if it contains a QUIC long header, and extract the Server ID as if it were in a Destination CID. </ins> 7.


verification) or make sure there is common context for the server to verify the address using a service-generated token. <ins> The service must also communicate the source connection ID of the Retry packet to the server so that it can include it in a transport parameter for client verification. </ins> There are two different mechanisms to allow offload of DoS mitigation to a trusted network service.  One requires no shared state; the server need only be configured to trust a retry service, though this


triggering Initial packet.  This is in cleartext to be readable for the server, but authenticated later in the token. <ins> RSCIL: The retry source connection ID length. </ins> Original Destination Connection ID: This also in cleartext and authenticated later. <ins> Retry Source Connection ID: This also in cleartext and authenticated later. </ins> Opaque Data: This data MUST contain encrypted information that allows the retry service to validate the client's IP address, in accordance <del> with the QUIC specification.  It MUST also encode a secure hash of the original destination connection ID field to verify that this field has not been edited. </del> <ins> with the QUIC specification.  It MUST also provide a cryptographically secure means to validate the integrity of the entire token. </ins> Upon receipt of an Initial packet with a token that begins with '0', the retry service MUST validate the token in accordance with the QUIC <del> specification.  It must also verify that the secure hash of the Connect ID is correct.  If incorrect, the token is invalid. </del> <ins> specification. </ins> In active mode, the service MUST issue Retry packets for all Client initial packets that contain no token, or a token that has the first bit set to '1'.  It MUST NOT forward the packet to the server.  The service MUST validate all tokens with the first bit set to '0'.  If successful, the service MUST forward the packet with the token <del> intact.  If unsuccessful, it MUST drop the packet. </del> <ins> intact.  If unsuccessful, it MUST drop the packet.  The Retry Service MAY send an Initial Packet containing a CONNECTION_CLOSE frame with the INVALID_TOKEN error code when dropping the packet. </ins> Note that this scheme has a performance drawback.  When the retry service is in active mode, clients with a token from a NEW_TOKEN


receives an Initial Packet with the first bit to '0', it is a Retry token and the server MUST NOT attempt to validate it.  Instead, it MUST assume the address is validated and MUST extract the Original <del> Destination Connection ID, assuming the format described in nss- service-requirements. </del> <ins> Destination Connection ID and Retry Source Connection ID, assuming the format described in nss-service-requirements. </ins> 6.3.


ODCIL: The original destination connection ID length.  Tokens in NEW_TOKEN frames MUST set this field to zero. <del> Original Destination Connection ID: This is copied from the field in the client Initial packet. </del> <ins> RSCIL: The retry source connection ID length.  Tokens in NEW_TOKEN frames MUST set this field to zero. Original Destination Connection ID: The server or Retry Service copies this from the field in the client Initial packet. Retry Source Connection ID: The server or Retry service copies this from the Source Connection ID of the Retry packet. </ins> Client IP Address: The source IP address from the triggering Initial packet.  The client IP address is 16 octets.  If an IPv4 address, the


retry tokens marked as being a few seconds in the future, due to possible clock synchronization issues. <del> A server MUST NOT send a Retry packet in response to an Initial packet that contains a retry token. </del> <ins> After decrypting the token, the server uses the corresponding fields to populate the original_destination_connection_id transport parameter, with a length equal to ODCIL, and the retry_source_connection_id transport parameter, with length equal to RSCIL. As discussed in QUIC-TRANSPORT, a server MUST NOT send a Retry packet in response to an Initial packet that contains a retry token. </ins> 7.


4.4.2. <del> Upon receipt of a QUIC packet that is not of type Initial or 0-RTT, the load balancer extracts as many of the earliest octets from the destination connection ID as necessary to match the nonce length. The server ID immediately follows. </del> <ins> Upon receipt of a QUIC packet, the load balancer extracts as many of the earliest octets from the destination connection ID as necessary to match the nonce length.  The server ID immediately follows. </ins> The load balancer decrypts the nonce and the server ID using the following three pass algorithm:


encrypted-nonce) Pass 2: The load balancer decrypts the nonce octets using 128-bit <del> AES Electronic Codebook (ECB) mode, much like QUIC header protection, using the server-id intermediate as "nonce" for this </del> <ins> AES ECB mode, using the server-id intermediate as "nonce" for this </ins> pass.  The server-id intermediate octets are zero-padded to 16 octets.  AES-ECB encrypts this padded server-id intermediate using its key to generate a mask which it applies to the encrypted


nonce = encrypted_nonce ^ AES-ECB(key, padded-server_id_intermediate) Pass 3: The load balancer decrypts the server ID using 128-bit AES <del> Electronic Codebook (ECB) mode, much like QUIC header protection. The nonce octets are zero-padded to 16 octets.  AES-ECB encrypts this nonce using its key to generate a mask which it applies to the intermediate server id.  This provides the dercypted server ID. </del> <ins> ECB mode.  The nonce octets are zero-padded to 16 octets.  AES-ECB encrypts this nonce using its key to generate a mask which it applies to the intermediate server id.  This provides the decrypted server ID. </ins> server_id = server_id_intermediate ^ AES-ECB(key, padded-nonce) <del> This three pass algorithm is a simplified version of the FFX </del> <ins> This three-pass algorithm is a simplified version of the FFX </ins> algorithm.  It has the same connection ID length requirements as the Stream Cipher CID Algorithm, with the additional property that each encrypted nonce value depends on all server ID bits, and each


When generating a routable connection ID, the server writes arbitrary bits into its nonce octets, and its provided server ID into the server ID octets.  Servers MAY opt to have a longer connection ID <del> beyond the nonce and server ID.  The nonce and additional bits MAY encode additional information, but SHOULD appear essentially random to observers. </del> <ins> beyond the nonce and server ID.  The additional bits MAY encode additional information, but SHOULD appear essentially random to observers. If the decrypted nonce bits increase monotonically, that guarantees that nonces are not reused between connection IDs from the same server. </ins> The server encrypts the server ID using exactly the algorithm as described in triple-stream-cipher-load-balancer-actions, performing


4.2. <del> The Obfuscated CID Algorithm makes an attempt to obscure the mapping of connections to servers to reduce linkability, while not requiring true encryption and decryption.  The format is depicted in the figure </del> <ins> The Stream Cipher CID algorithm provides cryptographic protection at the cost of additional per-packet processing at the load balancer to decrypt every incoming connection ID.  The CID format is depicted </ins> below. 4.2.1. <del> The configuration agent selects an arbitrary set of bits of the server connection ID that it will use to route to a given server, called the "routing bits".  The number of bits MUST have enough entropy to have a different code point for each server, and SHOULD have enough entropy so that there are many codepoints for each server. The configuration agent MUST NOT select a routing mask with more than 136 routing bits set to 1, which allows for the first octet and up to 2 octets for server purposes in a maximum-length connection ID. The configuration agent selects a divisor that MUST be larger than the number of servers.  It SHOULD be large enough to accommodate reasonable increases in the number of servers.  The divisor MUST be an odd integer so certain addition operations do not always produce an even number. The configuration agent also assigns each server a "modulus", an integer between 0 and the divisor minus 1.  These MUST be unique for each server, and SHOULD be distributed across the entire number space between zero and the divisor. 4.2.2. Upon receipt of a QUIC packet, the load balancer extracts the selected bits of the Server CID and expresses them as an unsigned integer of that length.  The load balancer then divides the result by the chosen divisor.  The modulus of this operation maps to the modulus for the destination server. Note that any Server CID that contains a server's modulus, plus an arbitrary integer multiple of the divisor, in the routing bits is routable to that server regardless of the contents of the non-routing bits.  Outside observers that do not know the divisor or the routing bits will therefore have difficulty identifying that two Server CIDs route to the same server. Note also that not all Connection IDs are necessarily routable, as the computed modulus may not match one assigned to any server.  These DCIDs are non-compliant as described above. 4.2.3. The server chooses a connection ID length.  This MUST contain all of the routing bits and MUST be at least 9 octets to provide adequate entropy. When a server needs a new connection ID, it adds an arbitrary nonnegative integer multiple of the divisor to its modulus, without exceeding the maximum integer value implied by the number of routing bits.  The choice of multiple should appear random within these constraints. The server encodes the result in the routing bits.  It MAY put any other value into bits that used neither for routing nor config rotation.  These bits SHOULD appear random to observers. 4.3. The Stream Cipher CID algorithm provides true cryptographic protection, rather than mere obfuscation, at the cost of additional per-packet processing at the load balancer to decrypt every incoming connection ID.  The CID format is depicted below. 4.3.1. </del> The configuration agent assigns a server ID to every server in its pool, and determines a server ID length (in octets) sufficiently large to encode all server IDs, including potential future servers.


MUST be at least 8 octets and no more than 16 octets.  The nonce length and server ID length MUST sum to 19 or fewer octets. <del> 4.3.2. </del> <ins> 4.2.2. </ins> Upon receipt of a QUIC packet, the load balancer extracts as many of the earliest octets from the destination connection ID as necessary


The output of the decryption is the server ID that the load balancer uses for routing. <del> 4.3.3. </del> <ins> 4.2.3. </ins> When generating a routable connection ID, the server writes arbitrary bits into its nonce octets, and its provided server ID into the


described in stream-cipher-load-balancer-actions, performing the three passes in reverse order. <del> 4.4. </del> <ins> 4.3. </ins> The Block Cipher CID Algorithm, by using a full 16 octets of plaintext and a 128-bit cipher, provides higher cryptographic


it also requires connection IDs of at least 17 octets, increasing overhead of client-to-server packets. <del> 4.4.1. </del> <ins> 4.3.1. </ins> The configuration agent assigns a server ID to every server in its pool, and determines a server ID length (in octets) sufficiently


The configuration agent also selects an 16-octet AES-ECB key to use for connection ID decryption. <del> 4.4.2. </del> <ins> 4.3.2. </ins> Upon receipt of a QUIC packet, the load balancer reads the first octet to obtain the config rotation bits.  It then decrypts the


in that order.  The load balancer uses the server ID octets for routing. <del> 4.4.3. </del> <ins> 4.3.3. </ins> When generating a routable connection ID, the server MUST choose a connection ID length between 17 and 20 octets.  The server writes its


routing bytes.  The Server ID is unique to each server, and the routing bytes are global. <del> For Obfuscated CID Routing, this consists of the Routing Bits, Divisor, and Modulus.  The Modulus is unique to each server, but the others MUST be global. </del> For Stream Cipher CID Routing, this consists of the Server ID, Server ID Length, Key, and Nonce Length.  The Server ID is unique to each server, but the others MUST be global.  The authentication token MUST


map to the same server.  It could then apply analytical techniques to try to obtain the server encoding. <del> The Stream and Block Cipher CID algorithms provide robust entropy to making any sort of linkage.  The Obfuscated CID obscures the mapping and prevents trivial brute-force attacks to determine the routing parameters, but does not provide robust protection against sophisticated attacks. </del> <ins> The Stream and Block Cipher CID algorithms provide robust protection against any sort of linkage.  The Plaintext CID algorithm makes no attempt to protect this encoding. </ins> Were this analysis to obtain the server encoding, then on-path observers might apply this analysis to correlating different client


To avoid this, the configuration agent SHOULD issue QUIC-LB configurations to mutually distrustful servers that have different <del> 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 solution has a privay impact; see multiple-configs. </del> <ins> keys for encryption algorithms.  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 solution has a privacy impact; see multiple-configs. </ins> These techniques are not necessary for the plaintext algorithm, as it does not attempt to conceal the server ID.


6.3.2.1. This sub-tree defines the L2VPN service type, according to the <del> several signalling options to exchange membership information between </del> <ins> several signaling options to exchange membership information between </ins> PEs of an L2VPN.  The following signaling options are supported: <del> Refers to the BGP control plane as described in RFC4761 and RFC6624. Refers to the BGP control plane as described in RFC7432 and RFC7209. </del> <ins> The service is a Multipoint VPLSs that use a BGP control plane as described in RFC4761 and RFC6624.  For this L2VPN service, the model allows configuring the Route Distinguisher, the Route Targets, the PWE encapsulation type and the MTU configurations to allow MTU mismatch. The service is a Multipoint VPLSs that use also a BGP control plane but also includes the additional features and related parameters RFC7432 and RFC7209.  The model allows the configuration of the EVPN service interface type, the local and remote VPWS Service Instance (VSI) RFC8214, the EVPN policies for handling MAC addresses and the Ethernet Segment Identifier (ESI) information. </ins> <del> Refers to LDP-signaled pseudowires RFC6074. </del> <ins> A Multipoint VPLSs that use a mesh of LDP-signaled Pseudowires RFC6074.  The model allows configuring the T-LDP PWE type, MTU mismatch and the list of AC and PW bindings. </ins> <del> Refers to L2TP-signaled pseudowires RFC6074. </del> <ins> The L2 VPN uses L2TP-signaled Pseudowires as described in RFC6074. The model allows configuring TBC. </ins> 6.3.2.2.


of the element and to ensure correct serialization for integrity and authenticity checks. <ins> All CBOR maps in the Manifest and manifest envelope MUST be encoded with the canonical CBOR ordering as defined in RFC8949. </ins> 8.2. The Envelope contains each of the other primary constituent parts of


MUST still contain the suit-authentication-wrapper element, but the content MUST be a list containing only the SUIT_Digest. <ins> The algorithms used in SUIT_Authentication are defined by the profiles declared in I-D.moran-suit-mti. </ins> 8.4. The manifest contains:


explanation for the overall connection rate drop is that hairpinning failed in some cases. <del> 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.  Future versions of this document will include experimental data regarding this option. </del> 5.2. As noted in description, ICE agents using the mDNS technique are


This document uses the Augmented BNF defined in RFC5234 and updated by RFC7405. <del> 1.2. The OpenAPI Specification Media Types convey OpenAPI Specification (OAS) files as defined in oas for version 3.0.0 and above. Those files can be serialized in JSON or yaml.  Since there are multiple OpenAPI Specification Specifications versions, those media- types support the "version" parameter. The following examples conveys the desire of a client to receive an OpenAPI Specification resource preferably in the following order: openapi 3.1 in yaml openapi 3.0 in yaml any openapi version in json </del> 2. <del> Security requirements for both media type and media type suffix registrations are discussed in Section 4.6 of MEDIATYPE. </del> <ins> This section describes the information required to register the above media types. </ins> <del> 3. </del> <ins> 2.1. </ins> <del> This specification defines the following new Internet media types MEDIATYPE. 3.1. </del> <ins> The following information serves as the registration form for the "application/yaml" media type. </ins> Type name: application


Change controller: n/a <del> 3.2. </del> <ins> 2.2. The OpenAPI Specification Media Types convey OpenAPI document (OAS) files as defined in oas for version 3.0.0 and above. Those files can be serialized in JSON or yaml.  Since there are multiple OpenAPI Specification versions, those media-types support the "version" parameter. The following examples conveys the desire of a client to receive an OpenAPI Specification resource preferably in the following order: openapi 3.1 in yaml openapi 3.0 in yaml any openapi version in json 2.2.1. The following information serves as the registration form for the "application/openapi+json" media type. </ins> Type name: application


Change controller: n/a <del> 3.3. </del> <ins> 2.2.2. The following information serves as the registration form for the "application/openapi+yaml" media type. </ins> Type name: application


Change controller: n/a <del> 4.  References </del> <ins> 3. Security requirements for both media type and media type suffix registrations are discussed in Section 4.6 of MEDIATYPE. </ins> <del> 4.1.  URIs </del> <ins> 4. This specification defines the following new Internet media types MEDIATYPE. IANA has updated the "Media Types" registry at https://www.iana.org/assignments/media-types [3] with the registration information provided below. 5.  References 5.1.  URIs </ins> [1] https://mailarchive.ietf.org/arch/browse/httpapi/ [2] https://github.com/ioggstream/draft-polli-rest-api-mediatypes <ins> [3] https://www.iana.org/assignments/media-types </ins>


service, defines the types of credentials which may be used in a deployment and provides methods for: <del> Issuing new credentials, </del> <ins> Issuing new credentials with a relevant credential lifetime, </ins> <del> Validating a credential against a reference identifier, and </del> <ins> Validating a credential against a reference identifier, </ins> Validating whether or not two credentials represent the same <del> client. </del> <ins> client, and Optionally revoking credentials which are no longer authorized. </ins> A *Delivery Service*, described fully in delivery-service, provides methods for:


Delivering Welcome messages to new members of a group. <del> Downloading KeyPackages for specific clients, and uploading new KeyPackages for a user's own clients. </del> <ins> Uploading new KeyPackages for a user's own clients. Downloading KeyPackages for specific clients.  Typically, KeyPackages are used once and consumed. </ins> Additional services may or may not be required depending on the application design:


set of acceptable behavior in a group.  These policies must be consistent between deployments for them to interoperate: <ins> A policy on which ciphersuites are acceptable. A policy on any mandatory or forbidden MLS extensions. </ins> A policy on when to send proposals and commits in plaintext instead of encrypted.


When, and under what circumstances, a reinitialization proposal is allowed. <del> When proposals from external senders are allowed. </del> <ins> When proposals from external senders are allowed and how to authorize those proposals. When external joiners are allowed and how to authorize those external commits. Which other proposal types are allowed. A policy of when members should commit pending proposals in a group. </ins> <del> When external joiners are allowed. </del> <ins> A policy of how to protect and share the GroupInfo objects needed for external joins. </ins> A policy for when two credentials represent the same client.  Note that many credentials may be issued authenticating the same


Finally, Clients should not be able to perform DoS attacks denial-of- service. <ins> 5. This document makes no requests of IANA. </ins>