3.2.3. <del> The sending client maps the outgoing streams and give them unique indices: 0, 1,.. etc.  As mentioned above SFrame supports up to 16 outgoing stream.  After encoding the frame and before packetizing it, the necessary media metadata will be moved out of the encoded frame buffer, to be used later in the RTP header extension.  The encoded frame, the metadata buffer and the stream index are passed to SFrame encryptor which internally keeps track of the number of frames encrypted so far for that stream.  The encryptor constructs SFrame header using the stream index and frame counter and derive the encryption IV.  The frame is encrypted using the encryption key and the header, encrypted frame and the media metadata are authenticated using the authentication key.  The authentication tag is then truncated (If supported by the cipher suite) and prepended at the end of the ciphertext. </del> <ins> After encoding the frame and before packetizing it, the necessary media metadata will be moved out of the encoded frame buffer, to be used later in the RTP header extension.  The encoded frame and the metadata buffer are passed to SFrame encryptor which internally keeps track of the number of frames encrypted so far.  The encryptor constructs SFrame header using frame counter and key id and derive the encryption IV.  The frame is encrypted using the encryption key and the header, encrypted frame and the media metadata are authenticated using the authentication key.  The authentication tag is then truncated (If supported by the cipher suite) and prepended at the end of the ciphertext. </ins> The encrypted payload is then passed to a generic RTP packetized to construct the RTP packets and encrypts it using SRTP keys for the


5.1.2. <del> The sender of a simulcast stream may use the same SRC for all the simulcast streams from the same media source or use a different SRC for each of them, in any case it is transparent to the SFU which will be able to perform the simulcast layer switching normally.  The senders are already able to receive different SRCs from different participants due to LastN and RTP Stream reuse, so supporting simulcast uses same mechanisms. </del> <ins> When using simulcast, the same input image will produce N different encoded frames (one per simulcat layer) which would be processed inpependently by the frame encryptor and assigned an unique counter for each. </ins> 5.1.3.


sizes or frames per second.  In order to support it, the sender MUST encode each spatial layer of a given picture in a different frame. That is, an RTP frame may contain more than one SFrame encrypted <del> frame with same source (SRC) and incrementing frame counter. </del> <ins> frame with an incrementing frame counter. </ins> 5.2.


Secure Frame (SFrame) <del> draft-omara-sframe-01 </del> <ins> draft-ietf-sframe-enc-latest </ins> Abstract


4. <del> This specification introduces two extensions to the SUIT envelope and the manifest structure, as motivated in arch. The SUIT envelope is enhanced with a key exchange payload, which is carried inside the suit-protection-wrappers parameter, see envelope- fig.  One or multiple SUIT_Encryption_Info payload(s) are carried within the suit-protection-wrappers parameter.  The content of the SUIT_Encryption_Info payload is explained in AES-KW (for AES-KW) and in HPKE (for HPKE).  When the encryption capability is used, the suit-protection-wrappers parameter MUST be included in the envelope. The manifest is extended with a CEK verification parameter (called suit-cek-verification), see manifest-fig.  This parameter is optional and is utilized in environments where battery exhaustion attacks are a concern.  Details about the CEK verification can be found in cek- verification. </del> <ins> This specification introduces two extensions to the SUIT_Parameters, as motivated in arch. The SUIT manifest is enhanced with a key exchange payload, which is carried within the suit-directive-override-parameters or suit- directive-set-parameters for each encrypted payload.  One SUIT_Encryption_Info is carried with suit-parameter-encryption-info, see parameter-fig.  The content of the SUIT_Encryption_Info is explained in AES-KW (for AES-KW) and in HPKE (for HPKE).  When the encryption capability is used, the SUIT_Encryption_Info parameter MUST be included in the SUIT_Directive. A CEK verification parameter (called suit-parameter-cek- verification), see parameter-fig, also extends the manifest.  This parameter is optional and is utilized in environments where battery exhaustion attacks are a concern.  Details about the CEK verification can be found in cek-verification. </ins> 5.


a RESTful API. Different protocols can be used with RESTful systems, but at the time <del> of writing the most common protocols are HTTP RFC7230 and CoAP </del> <ins> of writing the most common protocols are HTTP RFC9110 and CoAP </ins> RFC7252.  Since RESTful APIs are often lightweight and enable loose coupling of system components, they are a good fit for various Internet of Things (IoT) applications, which in general aim at


3.5. <del> Section 4.3 of RFC7231 defines the set of methods in HTTP; </del> <ins> Section 9.3 of RFC9110 defines the set of methods in HTTP; </ins> Section 5.8 of RFC7252 defines the set of methods in CoAP.  As part of the Uniform Interface constraint, each method can have certain properties that give guarantees to clients.


3.6. <del> Section 6 of RFC7231 defines a set of Status Codes in HTTP that are </del> <ins> Section 15 of RFC9110 defines a set of Status Codes in HTTP that are </ins> assigned by the server to indicate whether a request was understood and satisfied, and how to interpret the answer.  Similarly, Section 5.9 of RFC7252 defines the set of Response Codes in CoAP. <del> The status codes consist of three digits (e.g., "404" with HTTP or "4.04" with CoAP) where the first digit expresses the class of the code.  Implementations do not need to understand all status codes, but the class of the code must be understood.  Codes starting with 1 are informational; the request was received and being processed (not </del> <ins> The codes consist of three digits (e.g., "404" with HTTP or "4.04" with CoAP) where the first digit expresses the class of the code. Implementations do not need to understand all codes, but the class of the code must be understood.  Codes starting with 1 are informational; the request was received and being processed (not </ins> available in CoAP).  Codes starting with 2 indicate a successful request.  Codes starting with 3 indicate redirection; further action is needed to complete the request (not available in CoAP).  Codes


Internet X.509 Public Key Infrastructure: <del> HTTP security: Section 9 of RFC7230, Section 9 of RFC7231, etc. </del> <ins> HTTP security: Section 11 of RFC9112, Section 17 of RFC9110, etc. </ins> CoAP security:


7. <del> This document has no IANA actions. </del> <ins> 7.1. IANA is requested to update the entry for server_name(0) in the registry for ExtensionType (defined in TLS13) by replacing the value in the "TLS 1.3" column with the value "CH, EE, CR". 7.2. IANA is requested to add the following entries to the registry for Exporter Labels (defined in RFC5705): "EXPORTER-server authenticator handshake context", "EXPORTER-client authenticator finished key" and "EXPORTER-server authenticator finished key". </ins> 8.


The signatures generated with this API cover the context string "Exported Authenticator" and therefore cannot be transplanted into other protocols. <ins> In TLS 1.3 the client can not explicitly learn from the TLS layer whether its Finished message was accepted.  Because the application traffic keys are not dependent on the client's final flight, receiving messages from the server does not prove that the server received the client's Finished.  To avoid disagreement between the client and server on the authentication status of EAs, servers MUST verify the client Finished before sending an EA or processing a received EA. </ins>


Abstract The organizational separation between the operator of a TLS server <del> and the certificate authority can create limitations.  For example, </del> <ins> and the certification authority can create limitations.  For example, </ins> the lifetime of certificates, how they may be used, and the <del> algorithms they support are ultimately determined by the certificate authority.  This document describes a mechanism by which operators may delegate their own credentials for use in TLS, without breaking compatibility with clients that do not support this specification. </del> <ins> algorithms they support are ultimately determined by the certification authority.  This document describes a mechanism by which operators may delegate their own credentials for use in TLS, without breaking compatibility with clients that do not support this specification. </ins> 1.


operators to limit the exposure of keys in cases that they do not realize a compromise has occurred.  The risk inherent in cross- organizational transactions makes it operationally infeasible to rely <del> on an external CA for such short-lived credentials.  In OCSP stapling, if an operator chooses to talk frequently to the CA to obtain stapled responses, then failure to fetch an OCSP stapled </del> <ins> on an external CA for such short-lived credentials.  In OCSP stapling (i.e., using the Certificate Status extension types ocsp RFC6066 or ocsp_multi RFC6961), if an operator chooses to talk frequently to the CA to obtain stapled responses, then failure to fetch an OCSP stapled </ins> response results only in degraded performance.  On the other hand, failure to fetch a potentially large number of short lived certificates would result in the service not being available, which


associated signature algorithm).  The signature on the credential indicates a delegation from the certificate that is issued to the TLS server operator.  The secret key used to sign a credential <del> corresponds to the public key of the X.509 end-entity certificate. </del> <ins> corresponds to the public key of the TLS server's X.509 end-entity certificate. </ins> A TLS handshake that uses delegated credentials differs from a normal handshake in a few important ways:


It was noted in XPROT that certificates in use by servers that support outdated protocols such as SSLv2 can be used to forge signatures for certificates that contain the keyEncipherment KeyUsage <del> (RFC5280 section 4.2.1.3) In order to prevent this type of cross- </del> <ins> (RFC5280 section 4.2.1.3).  In order to prevent this type of cross- </ins> protocol attack, we define a new DelegationUsage extension to X.509 that permits use of delegated credentials.  (See certificate- requirements.)


private key.  The mechanism proposed in this document allows the delegation to be done off-line, with no per-transaction latency.  The figure below compares the message flows for these two mechanisms with <del> TLS 1.3 I-D.ietf-tls-tls13. </del> <ins> TLS 1.3 I-D.ietf-tls-tls13, where DC is delegated credentials. </ins> These two mechanisms can be complementary.  A server could use credentials for clients that support them, while using LURK to


to match the protocol version that is negotiated by the client and server. <del> The credential's public key, a DER-encoded SubjectPublicKeyInfo as defined in RFC5280. </del> <ins> The credential's public key, a DER-encoded X690 SubjectPublicKeyInfo as defined in RFC5280. </ins> The delegated credential has the following structure:


Many of the use cases for delegated credentials can also be addressed using purely server-side mechanisms that do not require changes to <del> client behavior (e.g., LURK I-D.mglt-lurk-tls-requirements).  These mechanisms, however, incur per-transaction latency, since the front- end server has to interact with a back-end server that holds a private key.  The mechanism proposed in this document allows the delegation to be done off-line, with no per-transaction latency.  The figure below compares the message flows for these two mechanisms with TLS 1.3 I-D.ietf-tls-tls13. </del> <ins> client behavior (e.g., a PKCS#11 interface or a remote signing mechanism KEYLESS).  These mechanisms, however, incur per-transaction latency, since the front-end server has to interact with a back-end server that holds a private key.  The mechanism proposed in this document allows the delegation to be done off-line, with no per- transaction latency.  The figure below compares the message flows for these two mechanisms with TLS 1.3 RFC8446. </ins> These two mechanisms can be complementary.  A server could use credentials for clients that support them, while using LURK to support legacy clients. It is possible to address the short-lived certificate concerns above <del> by automating certificate issuance, e.g., with ACME I-D.ietf-acme- acme.  In addition to requiring frequent operationally-critical interactions with an external party, this makes the server operator dependent on the CA's willingness to issue certificates with sufficiently short lifetimes.  It also fails to address the issues with algorithm support.  Nonetheless, existing automated issuance APIs like ACME may be useful for provisioning credentials within an operator network. </del> <ins> by automating certificate issuance, e.g., with ACME RFC8555.  In addition to requiring frequent operationally-critical interactions with an external party, this makes the server operator dependent on the CA's willingness to issue certificates with sufficiently short lifetimes.  It also fails to address the issues with algorithm support.  Nonetheless, existing automated issuance APIs like ACME may be useful for provisioning credentials within an operator network. </ins> 3. While X.509 forbids end-entity certificates from being used as issuers for other certificates, it is perfectly fine to use them to issue other signed objects as long as the certificate contains the <del> digitalSignature KeyUsage (RFC5280 section 4.2.1.3).  We define a new signed object format that would encode only the semantics that are needed for this application.  The credential has the following </del> <ins> digitalSignature KeyUsage (RFC 5280 section 4.2.1.3).  We define a new signed object format that would encode only the semantics that are needed for this application.  The credential has the following </ins> structure: Relative time in seconds from the beginning of the delegation


5.4. <ins> If a client decides to cache the certificate chain an re-validate it when resuming a connection, the client SHOULD also cache the associated delegated credential and re-validate it. 5.5. </ins> Delegated credentials can be valid for 7 days and it is much easier for a service to create delegated credential than a certificate signed by a CA.  A service could determine the client time and clock


1. <ins> Server operators often deploy TLS termination services in locations such as remote data centers or Content Delivery Networks (CDNs) where it may be difficult to detect key compromises.  Short-lived certificates may be used to limit the exposure of keys in these cases. However, short-lived certificates need to be renewed more frequently than long-lived certificates.  If an external CA is unable to issue a certificate in time to replace a deployed certificate, the server would no longer be able to present a valid certificate to clients. With short-lived certificates, there is a smaller window of time to renew a certificates and therefore a higher risk that an outage at a CA will negatively affect the uptime of the service. </ins> Typically, a TLS server uses a certificate provided by some entity other than the operator of the server (a "Certification Authority" or CA) RFC8446 RFC5280.  This organizational separation makes the TLS


The server operator can only use TLS signature schemes for which the CA will issue credentials. <del> These dependencies cause problems in practice.  Server operators often deploy TLS termination services in locations such as remote data centers or Content Delivery Networks (CDNs) where it may be difficult to detect key compromises.  Short-lived certificates may be used to limit the exposure of keys in these cases. However, short-lived certificates need to be renewed more frequently than long-lived certificates.  If an external CA is unable to issue a certificate in time to replace a deployed certificate, the server would no longer be able to present a valid certificate to clients. With short-lived certificates, there is a smaller window of time to renew a certificates and therefore a higher risk that an outage at a CA will negatively affect the uptime of the service. </del> To reduce the dependency on external CAs, this document proposes a limited delegation mechanism that allows a TLS peer to issue its own credentials within the scope of a certificate issued by an external


A client which supports this document SHALL send an empty "delegated_credential" extension in its ClientHello.  If the client receives a delegated credential without indicating support, then the <del> client SHOULD abort with an "unexpected_message" alert. </del> <ins> client MUST abort with an "unexpected_message" alert. </ins> If the extension is present, the server MAY send a delegated <del> credential extension.  If the extension is not present, the server MUST NOT send a credential.  A credential MUST NOT be provided unless a Certificate message is also sent.  The server MUST ignore the extension unless TLS 1.2 or later is negotiated. When negotiating TLS 1.3, and using delegated credentials, the server MUST send the delegated credential as an extension in the CertificateEntry of its end-entity certificate; the client SHOULD ignore delegated credentials sent as extensions with any other certificate.  When negotiating TLS 1.2, the delegated credential MUST be sent as an extension in the ServerHello. </del> <ins> credential extension; if the extension is not present, the server MUST NOT send a delegated credential.  A delegated credential MUST NOT be provided unless a Certificate message is also sent.  The server MUST ignore the extension unless TLS 1.2 or later is negotiated. When negotiating TLS 1.3, the server MUST send the delegated credential as an extension in the CertificateEntry of its end-entity certificate; the client SHOULD ignore delegated credentials sent as extensions to any other certificate.  When negotiating TLS 1.2, the delegated credential MUST be sent as an extension in the ServerHello. </ins> The delegated credential contains a signature from the public key in the end-entity certificate using a signature algorithm advertised by


certificate when the certificate permits the usage of delegated credentials. <del> Conforming CAs MUST mark this extension as non-critical.  This allows the certificate to be used by service owners for clients that do not support certificate delegation as well and not need to obtain two certificates. </del> The client MUST NOT accept a delegated credential unless the server's end-entity certificate satisfies the following criteria:


type in RFC5280), but has the keyEncipherment and dataEncipherment usages are disabled. <ins> The extension MAY be marked crititcal.  (See Section 4.2 of RFC5280.) If the strict boolean is set to true, then the server MUST use delegated credential in the handshake; if no delegated credential is offered, then the client MUST abort the handshake with an "illegal_parameter" alert. </ins> 5. TBD


6.1. <ins> Marking the delegation certificate's DelegationUsage extension non- critical allows the certificate to be used for clients that do not support delegated credentials.  However, it may be desirable to ensure that the delegation certificate is only used in handshakes in which a delegated credential negotiated.  It suffices to mark the extension crticial and set the strict boolean to true: if the client does not support delegated credentials, then it will abort the handshake if the certificate has the DelegationUsage extension (as per Section 4.2 of RFC5280); if the client indicates support, but the server does not offer a delegated credential, then the client will abort the handshake (as per certificate-requirements). 6.2. </ins> Delegated credentials limit the exposure of the TLS private key by limiting its validity.  An attacker who compromises the private key of a delegated credential can act as a man in the middle until the


access control mechanisms SHOULD be used to protect it such as file system controls, physical security or hardware security modules. <del> 6.2. </del> <ins> 6.3. </ins> Delegated credentials do not provide any additional form of early revocation.  Since it is short lived, the expiry of the delegated


private key that signs the delegated credential also implictly revokes the delegated credential. <del> 6.3. </del> <ins> 6.4. </ins> Delegated credentials can be valid for 7 days and it is much easier for a service to create delegated credential than a certificate


validity period.  In the absence of an application profile standard specifying otherwise, the maximum validity period is set to 7 days. Peers MUST NOT issue credentials with a validity period longer than <del> the maximum validity period.  This mechanism is described in detail in client-and-server-behavior. </del> <ins> the maximum validity period or that extends beyond the validity period of the delegation certificate.  This mechanism is described in detail in client-and-server-behavior. </ins> It was noted in XPROT that certificates in use by servers that support outdated protocols such as SSLv2 can be used to forge


"signature_algorithms" is REQUIRED for certificate authentication. <del> "supported_groups" and "key_share" are REQUIRED for DHE or ECDHE key exchange. </del> <ins> "supported_groups" is REQUIRED for ClientHello messages using DHE or ECDHE key exchange. "key_share" is REQUIRED for DHE or ECDHE key exchange. </ins> "pre_shared_key" is REQUIRED for PSK key agreement.


with B and probably retry the request, leading to duplication on the server system as a whole. <del> The first class of attack can be prevented by the mechanism described in this section.  Servers need not permit 0-RTT at all, but those which do SHOULD implement either the single-use tickets or ClientHello recording techniques described in the following two sections. </del> <ins> The first class of attack can be prevented by sharing state to guarantee that the 0-RTT data is accepted at most once.  Servers SHOULD provide that level of replay safety, by implementing one of the methods described in this section or by equivalent means.  It is understood, however, that due to operational concerns not all deployments will maintain state at that level.  Therefore, in normal operation, clients will not know which, if any, of these mechanisms servers actually implement and hence MUST only send early data which they deem safe to be replayed. In addition to the direct effects of replays, there is a class of attacks where even operations normally considered idempotent could be exploited by a large number of replays (timing attacks, resource limit exhaustion and others described in replay-0rtt).  Those can be mitigated by ensuring that every 0-RTT payload can be replayed only a limited number of times.  The server MUST ensure that any instance of it (be it a machine, a thread or any other entity within the relevant serving infrastructure) would accept 0-RTT for the same 0-RTT handshake at most once; this limits the number of replays to the number of server instances in the deployment.  Such a guarantee can be accomplished by locally recording data from recently-received ClientHellos and rejecting repeats, or by any other method that provides the same or a stronger guarantee.  The "at most once per server instance" guarantee is a minimum requirement; servers SHOULD limit 0-RTT replays further when feasible. </ins> The second class of attack cannot be prevented at the TLS layer and MUST be dealt with by any application.  Note that any application whose clients implement any kind of retry behavior already needs to implement some sort of anti-replay defense. <del> In normal operation, clients will not know which, if any, of these mechanisms servers actually implement and therefore MUST only send early data which they are willing to have subject to the attacks described in replay-0rtt. </del> 8.1. The simplest form of anti-replay defense is for the server to only


CertificateEntry. If the corresponding certificate type extension <del> ("server_certificate_type" or "client_certificate_type") was not used or the X.509 certificate type was negotiated, then each CertificateEntry contains an X.509 certificate.  The sender's certificate MUST come in the first CertificateEntry in the list. Each following certificate SHOULD directly certify one preceding it. Because certificate validation requires that trust anchors be distributed independently, a certificate that specifies a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates. </del> <ins> ("server_certificate_type" or "client_certificate_type") was not negotiated in Encrypted Extensions, or the X.509 certificate type was negotiated, then each CertificateEntry contains an X.509 certificate. The sender's certificate MUST come in the first CertificateEntry in the list.  Each following certificate SHOULD directly certify one preceding it.  Because certificate validation requires that trust anchors be distributed independently, a certificate that specifies a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates. </ins> Note: Prior to TLS 1.3, "certificate_list" ordering required each certificate to certify the one immediately preceding it; however,


"key_share", "pre_shared_key", "psk_key_exchange_modes", "early_data", "cookie", "supported_versions", "certificate_authorities", "oid_filters", "post_handshake_auth", <del> and "signature_algorithms_certs", extensions with the values </del> <ins> and "signature_algorithms_cert", extensions with the values </ins> defined in this document and the Recommended value of "Yes". IANA [SHALL update/has updated] this registry to include a "TLS


associate an SNI value with the ticket.  Clients, however, SHOULD store the SNI with the PSK to fulfill the requirements of NSTMessage. <del> Implementor's note: the most straightforward way to implement the PSK/cipher suite matching requirements is to negotiate the cipher suite first and then exclude any incompatible PSKs.  Any unknown PSKs (e.g., they are not in the PSK database or are encrypted with an unknown key) SHOULD simply be ignored.  If no acceptable PSKs are found, the server SHOULD perform a non-PSK handshake if possible. </del> <ins> Implementor's note: when session resumption is the primary use case of PSKs the most straightforward way to implement the PSK/cipher suite matching requirements is to negotiate the cipher suite first and then exclude any incompatible PSKs.  Any unknown PSKs (e.g., they are not in the PSK database or are encrypted with an unknown key) SHOULD simply be ignored.  If no acceptable PSKs are found, the server SHOULD perform a non-PSK handshake if possible.  If backwards compatibility is important, client provided, externally established PSKs SHOULD influence cipher suite selection. </ins> Prior to accepting PSK key establishment, the server MUST validate the corresponding binder value (see psk-binder below).  If this value


server has selected for the negotiated key exchange.  Servers MUST NOT send a KeyShareEntry for any group not indicated in the "supported_groups" extension and MUST NOT send a KeyShareEntry when <del> using the "psk_ke" PskKeyExchangeMode.  If a HelloRetryRequest was received by the client, the client MUST verify that the selected NamedGroup in the ServerHello is the same as that in the </del> <ins> using the "psk_ke" PskKeyExchangeMode.  If using (EC)DHE key establishment, and a HelloRetryRequest containing a "key_share" extension was received by the client, the client MUST verify that the selected NamedGroup in the ServerHello is the same as that in the </ins> HelloRetryRequest.  If this check fails, the client MUST abort the handshake with an "illegal_parameter" alert.


is not present or does not validate, the server MUST abort the handshake.  Servers SHOULD NOT attempt to validate multiple binders; rather they SHOULD select a single PSK and validate solely the binder <del> that corresponds to that PSK.  See [client-hello-recording] for the security rationale for this requirement.  In order to accept PSK key establishment, the server sends a "pre_shared_key" extension indicating the selected identity. </del> <ins> that corresponds to that PSK.  See [client-hello-recording] and [psk- identity-exposure] for the security rationale for this requirement. In order to accept PSK key establishment, the server sends a "pre_shared_key" extension indicating the selected identity. </ins> Clients MUST verify that the server's selected_identity is within the range supplied by the client, that the server selected a cipher suite


This alert notifies the recipient that the sender will not send any more messages on this connection.  Any data received after a <del> closure alert has been received MUST be ignored. </del> <ins> closure alert has been received MUST be ignored.  This alert MUST be sent with AlertLevel=warning. </ins> This alert notifies the recipient that the sender is canceling the handshake for some reason unrelated to a protocol failure.  If a


not specify how protocols add security with TLS; how to initiate TLS handshaking and how to interpret the authentication certificates exchanged are left to the judgment of the designers and implementors <del> of protocols that run on top of TLS. </del> <ins> of protocols that run on top of TLS.  Application protocols using TLS MUST specify how TLS works with their application protocol, including how and when handshaking occurs, and how to do identity verification. I-D.ietf-uta-rfc6125bis provides useful guidance on integrating TLS with applicaiton protocols. </ins> This document defines TLS version 1.3.  While TLS 1.3 is not directly compatible with previous versions, all versions of TLS incorporate a


Freeze & deprecate record layer version field. <ins> Update format of signatures with context. </ins> draft-05 Prohibit SSL negotiation for backwards compatibility.


Remove renegotiation. <del> Update format of signatures with context. </del> Remove point format negotiation. draft-03


1.2. <del> draft-07 - Integration of semi-ephemeral DH proposal. </del> <ins> draft-08 Remove support for weak and lesser used named curves. Remove support for MD5 and SHA-224 hashes with signatures. draft-07 Integration of semi-ephemeral DH proposal. </ins> Add initial 0-RTT support


digital signatures.  The "extension_data" field of this extension contains a "supported_signature_algorithms" value. <del> %%% Signature Algorithm Extension enum { none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5), sha512(6), (255) } HashAlgorithm; </del> <ins> %%% Signature Algorithm Extension enum { none(0), md5_RESERVED(1), sha1(2), sha224_RESERVED(3), sha256(4), sha384(5), sha512(6), (255) } HashAlgorithm; </ins> Each SignatureAndHashAlgorithm value lists a single hash/signature pair that the client is willing to verify.  The values are indicated


SHA-224, SHA-256, SHA-384, and SHA-512 SHS, respectively.  The "none" value is provided for future extensibility, in case of a signature algorithm which does not require hashing before signing. <ins> The usage of MD5 and SHA-224 are deprecated.  The md5_RESERVED and sha224_RESERVED values MUST NOT be offered or negotiated by any implementation. </ins> This field indicates the signature algorithm that may be used.


appropriate rules. If the client supports only the default hash and signature algorithms <del> (listed in this section), it MAY omit the signature_algorithms </del> <ins> (listed in this section), it MAY omit the "signature_algorithms" </ins> extension.  If the client does not support the default algorithms, or supports other hash and signature algorithms (and it is willing to use them for verifying messages sent by the server, i.e., server certificates and server key share), it MUST send the <del> signature_algorithms extension, listing the algorithms it is willing to accept. </del> <ins> "signature_algorithms" extension, listing the algorithms it is willing to accept. </ins> <del> If the client does not send the signature_algorithms extension, the </del> <ins> If the client does not send the "signature_algorithms" extension, the </ins> server MUST do the following: If the negotiated key exchange algorithm is one of (DHE_RSA,


The "extension_data" field of this extension SHALL contain a "NamedGroupList" value: <del> %%% Named Group Extension enum { // Elliptic Curve Groups.  sect163k1 (1), sect163r1 (2), sect163r2 (3), sect193r1 (4), sect193r2 (5), sect233k1 (6), sect233r1 (7), sect239k1 (8), sect283k1 (9), sect283r1 (10), sect409k1 (11), sect409r1 (12), sect571k1 (13), sect571r1 (14), secp160k1 (15), secp160r1 (16), secp160r2 (17), secp192k1 (18), secp192r1 (19), secp224k1 (20), secp224r1 (21), secp256k1 (22), secp256r1 (23), secp384r1 (24), secp521r1 (25), </del> <ins> %%% Named Group Extension enum { // Elliptic Curve Groups. obsolete_RESERVED (1..13), sect571r1 (14), obsolete_RESERVED (15..22), secp256r1 (23), secp384r1 (24), secp521r1 (25), </ins> <del> Indicates support of the corresponding named curve The named curves defined here are those specified in SEC 2 [13].  Note that many of these curves are also recommended in ANSI X9.62 X962 and FIPS 186-2 DSS.  Values 0xFE00 through 0xFEFF are reserved for private use.  Values 0xFF01 and 0xFF02 were used in previous versions of TLS but MUST NOT be offered by TLS 1.3 implementations.  [[OPEN ISSUE: Triage curve list.]] </del> <ins> Indicates support of the corresponding named curve.  Note that some curves are also recommended in ANSI X9.62 X962 and FIPS 186-2 DSS.  Values 0xFE00 through 0xFEFF are reserved for private use. </ins> Indicates support of the corresponding finite field group, defined <del> in </del> <ins> in I-D.ietf-tls-negotiated-ff-dhe.  Values 0x01FC through 0x01FF are reserved for private use. Values within "obsolete_RESERVED" ranges were used in previous versions of TLS and MUST NOT be offered or negotiated by TLS 1.3 implementations. </ins> Items in named_curve_list are ordered according to the client's preferences (favorite choice first). <del> As an example, a client that only supports secp192r1 (aka NIST P-192; value 19 = 0x0013) and secp224r1 (aka NIST P-224; value 21 = 0x0015) and prefers to use secp192r1 would include a TLS extension consisting </del> <ins> As an example, a client that only supports secp256r1 (aka NIST P-256; value 23 = 0x0017) and secp384r1 (aka NIST P-384; value 24 = 0x0018) and prefers to use secp256r1 would include a TLS extension consisting </ins> of the following octets.  Note that the first two octets indicate the extension type (Supported Group Extension):


1.2. <del> draft-09 The maximum permittion record expansion for AEAD has been reduced from 2048 to 256 octets. </del> draft-08 Remove support for weak and lesser used named curves.


Revise list of currently available AEAD cipher suites. <ins> Reduce maximum permitted record expansion for AEAD from 2048 to 256 octets. </ins> draft-07 Integration of semi-ephemeral DH proposal.


generated. An AEAD cipher MUST NOT produce an expansion of greater than 256 <del> bytes.  An endpoint that receives a record that is larger than 2^14+256 octets MUST generate a fatal "record_overflow" alert. </del> <ins> bytes.  An endpoint that receives a record that is larger than 2^14 + 256 octets MUST generate a fatal "record_overflow" alert. </ins> As a special case, we define the NULL_NULL AEAD cipher which is simply the identity operation and thus provides no security.  This


A TLSCiphertext record was received that had a length more than <del> 2^14+256 bytes, or a record decrypted to a TLSPlaintext record </del> <ins> 2^14 + 256 bytes, or a record decrypted to a TLSPlaintext record </ins> with more than 2^14 bytes.  This alert is always fatal and should never be observed in communication between proper implementations (except when messages were corrupted in the network).


When this message will be sent: <del> If this message is sent, it MUST be sent immediately after the </del> <ins> The EncryptedExtensions message MUST be sent immediately after the </ins> ServerHello message.  This is the first message that is encrypted under keys derived from ES.


below). The client specifies the cryptographic configuration for the 0-RTT <del> data using the "configuration", "cipher_suite", and "extensions" </del> <ins> data using the "configuration_id", "cipher_suite", and "extensions" </ins> values.  For configurations received in-band (in a previous TLS connection) the client MUST:


of the following octets.  Note that the first two octets indicate the extension type ("supported_groups" extension): <ins> As of TLS 1.3, servers are permitted to send the "supported_groups" extension to the client.  If the server has a group it prefers to the ones in the "key_share" extension but is still willing to accept the ClientHello, it SHOULD send "supported_groups" to update the client's view of its preferences.  Clients MUST NOT act upon any information found in "supported_groups" prior to successful completion of the handshake, but MAY use the information learned from a successfully completed handshake to change what groups they offer to a server in subsequent connections. </ins> [[TODO: IANA Considerations.]] 6.3.2.3.


lacking a "server_name" extension with a fatal "missing_extension" alert. <del> Some of these extensions exist only for the client to provide additional data to the server in a backwards-compatible way and thus have no meaning when sent from a server.  The client-only extensions defined in this document are: "signature_algorithms" & "supported_groups".  Servers MUST NOT send these extensions.  Clients receiving any of these extensions MUST respond with a fatal </del> <ins> Servers MUST NOT send the "signature_algorithms" extension; if a client receives this extension it MUST respond with a fatal </ins> "unsupported_extension" alert and close the connection. 9.


The TLS handshake establishes one or more input secrets which are combined to create the actual working keying material, as detailed <del> below.  The key derivation process makes use of the following functions, based on HKDF RFC5869: </del> <ins> below.  The key derivation process makes use of the HKDF-Extract and HKDF-Expand functions as defined for HKDF RFC5869, as well as the functions defined below: </ins> Given a set of n InputSecrets, the final "master secret" is computed by iteratively invoking HKDF-Extract with InputSecret_1, <del> InputSecret_2, etc.  The initial secret is simply a string of 0s as long as the size of the Hash that is the basis for the HKDF. </del> <ins> InputSecret_2, etc.  The initial secret is simply a string of zeroes as long as the size of the Hash that is the basis for the HKDF. </ins> Concretely, for the present version of TLS 1.3, secrets are added in the following order:


The "extension_data" field of this extension contains a "NamedGroupList" value: <del> %%% Named Group Extension </del> <ins> %%% Supported Groups Extension </ins> Indicates support of the corresponding named curve.  Note that some curves are also recommended in ANSI X9.62 X962 and FIPS 186-4


Upon receipt of a HelloRetryRequest, the client MUST verify that the extensions block is not empty and otherwise MUST abort the handshake <del> with a "decode_error" alert.  Clients SHOULD abort the handshake with an "unexpected message" if the HelloRetryRequest would not result in any change in the ClientHello or in response to any second HelloRetryRequest which was sent in the same connection (i.e., where the ClientHello was itself in response to a HelloRetryRequest). </del> <ins> with a "decode_error" alert.  Clients MUST abort the handshake with an "illegal_parameter" alert if the HelloRetryRequest would not result in any change in the ClientHello.  If a client receives a second HelloRetryRequest in the same connection (i.e., where the ClientHello was itself in response to a HelloRetryRequest), it MUST abort the handshake with an "unexpected_message" alert. </ins> Otherwise, the client MUST process all extensions in the HelloRetryRequest and send a second updated ClientHello.  The


Fields and variables may be assigned a fixed value using "=", as in: <del> 3.7.1. </del> <ins> 3.8. </ins> Defined structures may have variants based on some knowledge that is available within the environment.  The selector must be an enumerated


For example: <del> 3.8. </del> <ins> 3.9. </ins> TLS defines two generic alerts (see alert-protocol) to use upon failure to parse a message.  Peers which receive a message which


The certificate and signing key to be used. <del> A Handshake Context based on the hash of the handshake messages </del> <ins> A Handshake Context based on the transcript of the handshake messages </ins> A base key to be used to compute a MAC key.


in the cookie, rather than requiring it to export the entire intermediate hash state (see cookie). <ins> For concreteness, the transcript hash is always taken from the following sequence of handshake messages, starting at the first ClientHello and including only those messages that were sent: ClientHello, HelloRetryRequest, ClientHello, ServerHello, EncryptedExtensions, Server CertificateRequest, Server Certificate, Server CertificateVerify, Server Finished, EndOfEarlyData, Client Certificate, Client CertificateVerify, Client Finished. </ins> In general, implementations can implement the transcript by keeping a running transcript hash value based on the negotiated hash.  Note, however, that subsequent post-handshake authentications do not


Secret is called with four distinct transcripts; in a 1-RTT-only exchange with three distinct transcripts. <del> The complete transcript passed to Derive-Secret is always taken from the following sequence of handshake messages, starting at the first ClientHello and including only those messages that were sent: ClientHello, HelloRetryRequest, ClientHello, ServerHello, EncryptedExtensions, Server CertificateRequest, Server Certificate, Server CertificateVerify, Server Finished, EndOfEarlyData, Client Certificate, Client CertificateVerify, Client Finished. </del> If a given secret is not available, then the 0-value consisting of a string of Hash.length zero bytes is used.  Note that this does not mean skipping rounds, so if PSK is not in use Early Secret will still


Add "post_handshake_auth" extension to negotiate post-handshake authentication (*). <ins> Shorten labels for HKDF-Expand-Label so that we can fit within one compression block (*). </ins> draft-19 Hash context_value input to Exporters (*)


layer headers.  Note that in some cases a zero-length HashValue (indicated by "") is passed to HKDF-Expand-Label. <ins> Note: with common hash functions, any label longer than 12 characters requires an additional iteration of the hash function to compute. The labels in this specification have all been chosen to fit within this limit. </ins> Given a set of n InputSecrets, the final "master secret" is computed by iteratively invoking HKDF-Extract with InputSecret_1, InputSecret_2, etc.  The initial secret is simply a string of


mean skipping rounds, so if PSK is not in use Early Secret will still be HKDF-Extract(0, 0).  For the computation of the binder_secret, the label is "external psk binder key" for external PSKs (those <del> provisioned outside of TLS) and "resumption psk binder key" for resumption PSKs (those provisioned as the resumption master secret of a previous handshake).  The different labels prevent the substitution of one type of PSK for the other. </del> <ins> provisioned outside of TLS) and "res binder" for resumption PSKs (those provisioned as the resumption master secret of a previous handshake).  The different labels prevent the substitution of one type of PSK for the other. </ins> There are multiple potential Early Secret values depending on which PSK the server ultimately selects.  The client will need to compute


Organizations are a way of forming groups of contributors on GitHub. Each Working Group SHOULD create a new organization for the working <del> group. A working group organization SHOULD be named consistently so that it can be found.  For instance, the name could be ietf-<wgname> or ietf- <wgname>-wg. </del> <ins> group.  A working group organization SHOULD be named consistently so that it can be found.  For instance, the name could be ietf-<wgname> or ietf-<wgname>-wg. </ins> A single organization SHOULD NOT be used for all IETF activity, or all activity within an area.  Large organizations create too much


to all repositories and ownership does not grant any other significant privileges. <del> When Area Directors or Working Group Chairs change, teams MUST be updated to reflect the new membership status. When a Working Group is closed, the responsible Area Director is responsible for removing existing members from teams in the organization.  Repositories MUST be updated along to indicate that they are no longer under development. </del> <ins> Details about creating organizations adhering to these guidelines can be found in GIT-CONFIG. </ins> 2.2. <del> When an IETF Working Group is closed or when associated mailing lists are closed, mail archives and datatracker information from that work is backed up and accessible.  The same applies to GitHub repositories. Any repositories including issues and discussion SHOULD be backed up on IETF resources.  It is desirable for those to be accessible via the Working Group's datatracker page.  For example, this might be via URLs listed in the More Info section on the Working Group Charter page. The IETF MAY decide to backup information associated with a Working Group's organization periodically.  This decision can be made differently per Working Group in consultation with the responsible Area Director. 2.3. </del> Each Working Group MAY set its own policy as to whether and how it uses GitHub.  It is important that occasional participants in the WG and others accustomed to IETF tools be able to determine this and


to those mailing lists should be given.  An example of this is at https://datatracker.ietf.org/wg/quic/charter/. <del> 2.3.1. One important policy is the IETF IPR policy (see RFC5378, RFC3979, and RFC4879).  Part of this policy requires making contributors aware of the policy. The IETF Trust license file for open source repositories [5] MUST be included prominently in any document repository. Including this information in the CONTRIBUTING file is sufficient. In addition to the boilerplate text there can be a benefit to including pointers to other working group materials, the IETF datatracker, specific drafts, or websites.  Adding such text is at the discretion of the Working Group Chairs. </del> 3. A Working Group Chairs are responsible for determining how to best


An alternative is to rely on periodic email summaries of activity, such as those produced by a notification tool like github-notify-ml <del> [6].  This tool has been used effectively in several working groups, </del> <ins> [5].  This tool has been used effectively in several working groups, </ins> though it requires server infrastructure. A working group that uses GitHub MAY provide either facility at the


[4] https://about.gitlab.com/ <del> [5] https://trustee.ietf.org/license-for-open-source- repositories.html [6] https://github.com/dontcallmedom/github-notify-ml </del> <ins> [5] https://github.com/dontcallmedom/github-notify-ml </ins>


much later - in that scenario one endpoint might be aware of the compatibility document while the other may not. <del> When a client creates a QUIC connection, its goal is to use an application layer protocol.  Therefore, when considering which versions are compatible, clients will only consider versions that support one of the intended application layer protocols.  For example, if the client's first flight advertises multiple Application Layer Protocol Negotiation (ALPN) ALPN tokens and multiple compatible versions, the server needs to ensure that the ALPN token that it selects can run over the QUIC version that it selects. </del> 2.3. When the server can parse the client's first flight using the


6. <ins> When a client creates a QUIC connection, its goal is to use an application layer protocol.  Therefore, when considering which versions are compatible, clients will only consider versions that support one of the intended application layer protocols.  If the client's first flight advertises multiple Application Layer Protocol Negotiation (ALPN) ALPN tokens and multiple compatible versions, it is possible for some application layer protocols to not be able to run over some of the offered compatible versions.  It is the server's responsibility to only select an ALPN token that can run over the compatible QUIC version that it selects. A given ALPN token MUST NOT be used with a new QUIC version different from the version for which the ALPN token was originally defined, unless all the following requirements are met: The new QUIC version supports the transport features required by the application protocol. The new QUIC version supports ALPN. The version of QUIC for which the ALPN token was originally defined is compatible with the new QUIC version. When incompatible version negotiation is in use, the second connection which is created in response to the received version negotiation packet MUST restart its application layer protocol negotiation process without taking into account the original version. 7. </ins> In order to facilitate the deployment of future versions of QUIC, designers of future versions SHOULD attempt to design their new version such that commonly deployed versions are compatible with it.


widely deployed, this section discusses considerations for future versions to help with compatibility with QUIC version 1. <del> 6.1. </del> <ins> 7.1. </ins> QUIC version 1 features Retry packets, which the server can send to validate the client's IP address before parsing the client's first


handshake even though the Retry itself was sent using the original version. <del> 6.2. </del> <ins> 7.2. </ins> QUIC version 1 uses TLS 1.3, which supports session resumption by sending session tickets in one connection that can be used in a later


of QUIC; i.e., require that clients not use them across multiple version and that servers validate this client requirement. <del> 6.3. </del> <ins> 7.3. </ins> QUIC version 1 allows sending data from the client to the server during the handshake, by using 0-RTT packets.  If a future document


packets.  That document could specify that compatible version negotiation causes 0-RTT data to be rejected by the server. <del> 7. </del> <ins> 8. </ins> Because QUIC version 1 was the only IETF Standards Track version of QUIC published before this document, it is handled specially as


version negotiation to negotiate versions other than QUIC version 1 will need to implement this draft. <del> 8. </del> <ins> 9. </ins> The security of this version negotiation mechanism relies on the authenticity of the Version Information exchanged during the


possibility of cross-protocol attacks, but more analysis is still needed here. <del> 9. </del> <ins> 10. </ins> <del> 9.1. </del> <ins> 10.1. </ins> This document registers a new value in the "QUIC Transport Parameters" registry maintained at


of a codepoint in the 0-63 range to replace the provisional codepoint described above. <del> 9.2. </del> <ins> 10.2. </ins> This document registers a new value in the "QUIC Transport Error Codes" registry maintained at <<https://www.iana.org/assignments/


attempt prior to receiving the Version Negotiation packet is distinct from the connection with the incompatible version that follows. <ins> Note that this separation across two connections is conceptual: it applies to normative requirements on QUIC connections, but does not require implementations to internally use two distinct connection objects. </ins> 2.5. When the client picks its original version, it will try to avoid


also ignores a Version Negotiation packet that contains incorrect connection ID fields; see QUIC-INVARIANTS. <del> Upon receiving the Version Negotiation packet, the client will search for a version it supports in the list provided by the server.  If it doesn't find one, it aborts the connection attempt.  Otherwise, it selects a mutually supported version and sends a new first flight with that version - this version is now the negotiated version. </del> <ins> Upon receiving the Version Negotiation packet, the client SHALL search for a version it supports in the list provided by the server. If it doesn't find one, it SHALL abort the connection attempt. Otherwise, it SHALL select a mutually supported version and sends a new first flight with that version - this version is now the negotiated version. </ins> The new first flight will allow the endpoints to establish a connection using the negotiated version.  The handshake of the


attacker injected packets in order to influence the version negotiation process, see downgrade. <ins> Only servers can start incompatible version negotiation: clients MUST NOT send Version Negotiation packets and servers MUST ignore all received Version Negotiation packets. </ins> 2.2. If A and B are two distinct versions of QUIC, A is said to be


differ after the handshake, then A is compatible with B and B is compatible with A. <del> Version compatibility is not bijective: it is possible for version A </del> <ins> Version compatibility is not symmetric: it is possible for version A </ins> to be compatible with version B and for B not to be compatible with A.  This could happen for example if version B is a strict superset of version A.


6. Clients MUST ignore any received Version Negotiation packets that <del> contain the version that they initially attempted.  Once a client has reacted to a Version Negotiation packet, it MUST drop all subsequent Version Negotiation packets on that connection. </del> <ins> contain the version that they initially attempted.  A client that makes a connection attempt based on information received from a Version Negotiation packet MUST ignore any Version Negotiation packets it receives in response to that connection attempt. </ins> Both endpoints MUST parse their peer's Version Information during the handshake.  If parsing the Version Information failed (for example,


topic is used to correlate push messages sent to the same subscription and does not convey any other semantics. <del> The grammar for the Topic header field uses the "token" and "quoted- string" rules defined in RFC7230. Any double quotes from the "quoted-string" form are removed before comparing topics for equality. </del> <ins> The grammar for the Topic header field uses the "token" rule defined in RFC7230. </ins> For use with this protocol, the Topic header field MUST be restricted to no more than 32 characters from the URL and filename safe Base 64


A device and software that is the recipient of push messages. Examples in this document use the RFC7230.  Many of the exchanges can <del> be completed using HTTP/1.1.  Where HTTP/2 is necessary, the more verbose frame format from RFC7540 is used. </del> <ins> be completed using HTTP/1.1: message_subscription send replace acknowledge_message When an example depends on HTTP/2 server push, the more verbose frame format from RFC7540 is used: monitor-subscription monitor-set receive_receipt </ins> Examples do not include specific methods for push message encryption or application server authentication because the protocol does not


3. <del> The push service shares the same default port number (443/TCP) with HTTPS, but MAY also advertise the IANA allocated TCP System Port 1001 using HTTP alternative services RFC7838. </del> <ins> The push service MUST use HTTP over TLS [RFC2818] following the recommendations in [RFC7525].  The push service shares the same default port number (443/TCP) with HTTPS, but MAY also advertise the IANA allocated TCP System Port 1001 using HTTP alternative services RFC7838. </ins> While the default port (443) offers broad reachability characteristics, it is most often used for web browsing scenarios


to an entity body that is 4096 bytes or less in size. To limit the number of stored push messages, the push service MAY <del> either expire messages prior to their advertised Time-To-Live or reduce their advertised Time-To-Live. </del> <ins> respond with a shorter Time-To-Live than proposed by the application server in its request for push message delivery (ttl).  Once a message has been accepted, the push service MAY later expire the message prior to its advertised Time-To-Live.  If the application server requested a delivery receipt, the push service MUST return a failure response (acknowledge_message). </ins> 7.3.


Generic Event Delivery Using HTTP Push <del> draft-thomson-webpush-protocol-latest </del> <ins> draft-ietf-webpush-protocol-latest </ins> Abstract


Examples in this document use the RFC7230.  Many of the exchanges can be completed using HTTP/1.1, where HTTP/2 is necessary, the more <del> verbose frame format from I-D.ietf-httpbis-http2 is used. </del> <ins> verbose frame format from RFC7540 is used. </ins> 2.


A user agent requests the delivery of new push messages by making a GET request to a push message subscription resource.  The push <del> service does not respond to this request, it instead uses I-D.ietf- httpbis-http2 to send the contents of push messages as they are sent by application servers. </del> <ins> service does not respond to this request, it instead uses RFC7540 to send the contents of push messages as they are sent by application servers. </ins> Each push message is pushed in response to a synthesized GET request. The GET request is made to the push message resource that was created


The application server requests the delivery of receipts from the push server by making a HTTP GET request to the receipt subscription resource.  The push service does not respond to this request, it <del> instead uses I-D.ietf-httpbis-http2 to send push receipts when messages are acknowledged (acknowledge_message) by the user agent. </del> <ins> instead uses RFC7540 to send push receipts when messages are acknowledged (acknowledge_message) by the user agent. </ins> Each receipt is pushed in response to a synthesized GET request.  The GET request is made to the same push message resource that was


its adoption in the broadcasting/streaming industry is lagging behind. <del> Currently, there is no standard protocol designed for ingesting media into a streaming service using WebRTC and so content providers still rely heavily on protocols like RTMP for doing so. These protocols are much older than WebRTC and by default lack some important security and resilience features provided by WebRTC with minimal overhead and additional latency. The media codecs used for ingestion in older protocols tend to be limited and not negotiated.  WebRTC includes support for negotiation of codecs, potentially alleviating transcoding on the ingest node (which can introduce delay and degrade media quality).  Server side transcoding that has traditionally been done to present multiple renditions in Adaptive Bit Rate Streaming (ABR) implementations can be replaced with Simulcast RFC8853 and SVC codecs that are well supported by WebRTC clients.  In addition, WebRTC clients can adjust client-side encoding parameters based on RTCP feedback to maximize encoding quality. Encryption is mandatory in WebRTC, therefore secure transport of media is implicit. </del> The IETF RTCWEB working group standardized JSEP (RFC8829), a mechanism used to control the setup, management, and teardown of a multimedia session.  It also describes how to negotiate media flows


based on RTP and may be the closest in terms of features to WebRTC, is not compatible with the SDP offer/answer model RFC3264. <del> In the specific case of media ingestion into a streaming service, some assumptions can be made about the server-side which simplifies the WebRTC compliance burden, as detailed in WebRTC-gateway document draft-ietf-rtcweb-gateways. </del> <ins> So, currently, there is no standard protocol designed for ingesting media into a streaming service using WebRTC and so content providers still rely heavily on protocols like RTMP for doing so.  Most of those protocols are not RTP based, requiring media protocol translation when doing egress via WebRTC.  Avoiding this media protocol translation is desirable as there is no functional parity between those protocols and WebRTC and it increases the implementation complexity at the media server side. Also, the media codecs used in those protocols tend to be limited and not negotiated, not always matching the mediac codes supported in WebRTC.  This requires to perform transcoding on the ingest node, which introduces delay, degrades media quality and increases the processing workload required on the server side.  Server side transcoding that has traditionally been done to present multiple renditions in Adaptive Bit Rate Streaming (ABR) implementations can be replaced with Simulcast RFC8853 and SVC codecs that are well supported by WebRTC clients.  In addition, WebRTC clients can adjust client-side encoding parameters based on RTCP feedback to maximize encoding quality. </ins> This document proposes a simple protocol for supporting WebRTC as media ingestion method which:


4.2. <ins> In the specific case of media ingestion into a streaming service, some assumptions can be made about the server-side which simplifies the WebRTC compliance burden, as detailed in WebRTC-gateway document draft-ietf-rtcweb-gateways. </ins> In order to reduce the complexity of implementing WHIP in both clients and media servers, WHIP imposes the following restrictions regarding WebRTC usage:


The initial offer by the WHIP client MAY be sent after the full ICE gathering is complete with the full list of ICE candidates, or it MAY <del> only contain local candidates (or even an empty list of candidates). </del> <ins> only contain local candidates (or even an empty list of candidates) as per RFC8863. </ins> In order to simplify the protocol, there is no support for exchanging gathered trickle candidates from Media Server ICE candidates once the


candidates of the Media Server.  The Media Server MAY use ICE lite, while the WHIP client MUST implement full ICE. <del> The WHIP client MAY perform trickle ICE or ICE restarts RFC8863 by sending an HTTP PATCH request to the WHIP resource URL with a body containing a SDP fragment with MIME type "application/trickle-ice- sdpfrag" as specified in RFC8840.  When used for trickle ICE, the body of this PATCH message will contain the new ICE candidate; when used for ICE restarts, it will contain a new ICE ufrag/pwd pair. </del> <ins> The WHIP client MAY perform trickle ICE or ICE restarts as per RFC8838 by sending an HTTP PATCH request to the WHIP resource URL with a body containing a SDP fragment with MIME type "application/ trickle-ice-sdpfrag" as specified in RFC8840.  When used for trickle ICE, the body of this PATCH message will contain the new ICE candidate; when used for ICE restarts, it will contain a new ICE ufrag/pwd pair. </ins> Trickle ICE and ICE restart support is OPTIONAL for a WHIP resource. If the WHIP resource supports either Trickle ICE or ICE restarts, but