jiebi/CodeConvo huggingface dataset:
If Observe is implemented: <del> Replace step 1 in ver-req with: A.  Discard Code and all options marked in fig-option-protection with 'x' in column E, except for Observe, present in the received message. For example, an If-Match Outer option is discarded, Uri-Host Outer option is not discarded, Observe is not discarded. </del> <ins> Insert the following step before step 1 in ver-req: </ins> <del> Replace step 3 in ver-req with: </del> <ins> A.  Check if the Outer Observe option is present and has value zero. </ins> <del> B.  If Observe is present in the received message, and has value 0, check if the Token, kid and Partial IV are identical to a previously received Observe registration.  In this case, replay verification is postponed until step C.  Otherwise verify the 'Partial IV' parameter using the Replay Window, as described in replay-protection. </del> <ins> Insert the following step between step 6 and 7 of ver-req: </ins> <del> Insert the following steps between step 6 and 7 of ver-req: C.  If Observe was present in the received message (in step 1): If the value of Observe in the Outer message is 0: If Observe is present and has value 0 in the decrypted options, discard the Outer Observe.  If the Token, kid and Partial IV are identical to a previously received Observe registration, respond with a notification as described in observe-replay- processing; Otherwise, discard both the Outer and Inner (if present) Observe options and verify the 'Partial IV' parameter using the Replay Window, as described in replay-protection. If the value of Observe in the Outer message is not 0, discard the decrypted Observe option if present. </del> <ins> B.  If Inner Observe is present and has value zero, and Outer option is either not present or has not value 0, then remove the Observe option. </ins> 8.3.
If Observe is implemented: <del> Replace step 1 of ver-res with: A.  Discard Code and all options marked in fig-option-protection with 'x' in column E, except for Observe, present in the received message. For example, ETag Outer option is discarded, as well as Max-Age Outer option, Observe is not discarded. Insert the following steps between step 2 and 3 of ver-res: B.  If the Observe option is present in the response, but the request was not an Observe registration, then go to 9. </del> <ins> Replace step 6 of ver-res with: </ins> <del> C.  If an Observe option is included or the Notification number for the observation has already been initiated, but the Partial IV is not present in the response, then go to 9. </del> <ins> A.  If Inner Observe is present then: </ins> <del> D.  For Observe notifications, verify the received 'Partial IV' parameter against the corresponding Notification Number as described in replay-protection. </del> <ins> If the request was not an Observe registration, then go to 9. </ins> <del> Replace step 6 of ver-res with: </del> <ins> If the Partial IV was not present in the response, then go to 9. </ins> <del> E.  If the response is a notification, initiate or update the corresponding Notification Number, as described in sequence-numbers. Otherwise, delete the attribute-value pair (Token, {Security Context, PIV}). </del> <ins> If the request was an Observe registration and the Partial IV was present in the response, then verify the received 'Partial IV' parameter against the corresponding Notification Number, and follow the processing described in replay-notifications. Otherwise, delete the attribute-value pair (Token, {Security Context, PIV}). </ins> <del> Replace step 7 of ver-res with: </del> <ins> Replace step 9 of ver-res with: </ins> <del> F.  Add decrypted Code, options and payload to the decrypted request, except for decrypted Observe if present.  The OSCORE option is removed. </del> <ins> B.  In case any of the previous erroneous conditions apply: the client SHALL stop processing the response.  An error condition occurring while processing a response in an observation does not cancel the observation.  A client MUST NOT react to failure by re- registering the observation immediately. </ins> <del> An error condition occurring while processing a response in an observation does not cancel the observation.  A client MUST NOT react to failure in step 5 by re-registering the observation immediately. </del> <ins> Note that the attribute-value attribute-value pair (Token, {Security Context, PIV}) MUST be deleted whenever the Observation is cancelled or "forgotten". </ins> 9.
receiving endpoint discards the message, if complying to the policy) may be obtained as part of normal resource discovery. <ins> Applications need to use a padding scheme if the content of a message can be determined solely from the length of the payload.  As an example, the strings "YES" and "NO" even if encrypted can be distinguished from each other as there is no padding supplied by the current set of encryption algorithms.  Some information can be determined even from looking at boundary conditions.  An example of this would be returning an integer between 0 and 100 where lengths of 1, 2 and 3 will provide information about where in the range things are.  Three different methods to deal with this are: 1) ensure that all messages are the same length.  For example using 0 and 1 instead of 'yes' and 'no'.  2) Use a character which is not part of the responses to pad to a fixed length.  For example, pad with a space to three characters.  3) Use the PKCS #7 style padding scheme where m bytes are appended each having the value of m.  For example, appending a 0 to "YES" and two 1's to "NO".  This style of padding means that all values need to be padded. </ins> 8. Privacy threats executed through intermediate nodes are considerably
Distributor, this framework utilizes a DTLS-SRTP RFC5764 association between an endpoint and the Key Distributor.  To establish this association, an endpoint will send DTLS-SRTP messages to the Media <del> Distributor which will then forward them to the Media Distributor as </del> <ins> Distributor which will then forward them to the Key Distributor as </ins> defined in I-D.jones-perc-dtls-tunnel.  The Key Encryption Key (KEK) (i.e., EKT Key) is also conveyed by the Key Distributor over the DTLS association to endpoints via procedures defined in PERC EKT [I-
Media Distributors use DTLS-SRTP RFC5764 directly with a peer Media Distributor to establish HBH keys for transmitting RTP and RTCP <del> packets that peer Media Distributor.  The Key Distributor does not </del> <ins> packets to that peer Media Distributor.  The Key Distributor does not </ins> facilitate establishing HBH keys for use between Media Distributors. 4.5.1. The procedures defined in DTLS Tunnel for PERC I-D.jones-perc-dtls- <del> tunnel establish one or more DTLS tunnels between the Media </del> <ins> tunnel establish one or more TLS tunnels between the Media </ins> Distributor and Key Distributor, making it is possible for the Media Distributor to facilitate the establishment of a secure DTLS association between each endpoint and the Key Distributor as shown
the DTLS signaling, but will instead forward DTLS packets received from an endpoint on to the Key Distributor (and vice versa) via a tunnel established between Media Distributor and the Key Distributor. <del> This tunnel used to encapsulate the DTLS-SRTP signaling between the Key Distributor and endpoints will also be used to convey HBH key </del> <ins> This tunnel is used to encapsulate the DTLS-SRTP signaling between the Key Distributor and endpoints will also be used to convey HBH key </ins> information from the Key Distributor to the Media Distributor, so no additional protocol or interface is required.
fingerprint of the DTLS-SRTP certificate used for the call.  This certificate is unique for a given call and a conference.  This allows the Key Distributor to ensure that only authorized users participate <del> in the conference.  Similarly the Key Distributor can create a WeBRTC Identity assertion bound the fingerprint of the unique certificate </del> <ins> in the conference.  Similarly the Key Distributor can create a WebRTC Identity assertion to bind the fingerprint of the unique certificate </ins> used by the Key Distributor for this conference so that the endpoint can validate it is talking to the correct Key Distributor.
This document defines an extension to DTLS-SRTP called SRTP EKT Key Transport which enables secure transport of EKT keying material from <del> one DTLS-SRTP peer to another.  This allows those peers to process EKT keying material in SRTP (or SRTCP) and retrieve the embedded SRTP keying material.  This combination of protocols is valuable because it combines the advantages of DTLS, which has strong authentication of the endpoint and flexibility, along with allowing secure multiparty RTP with loose coordination and efficient communication of per-source keys. </del> <ins> the DTLS-SRTP peer in the server role to the client.  This allows those peers to process EKT keying material in SRTP (or SRTCP) and retrieve the embedded SRTP keying material.  This combination of protocols is valuable because it combines the advantages of DTLS, which has strong authentication of the endpoint and flexibility, along with allowing secure multiparty RTP with loose coordination and efficient communication of per-source keys. </ins> 5.1.
5.4. <del> The DTLS ekt_key is sent using the retransmissions specified in Section 4.2.4.  of DTLS RFC6347. </del> <ins> The DTLS message is sent using the retransmissions specified in Section 4.2.4. of DTLS RFC6347.  Retransmission is finished with an Ack message or an alert is received. </ins> 6.
7.3. <del> IANA is requested to add srtp_ekt_key_transport as a new extension name to the "ExtensionType Values" table of the "Transport Layer Security (TLS) Extensions" registry with a reference to this specification and allocate a value of TBD to for this.  Note to RFC Editor: TBD will be allocated by IANA. </del> <ins> IANA is requested to add as a new extension name to the "ExtensionType Values" table of the "Transport Layer Security (TLS) Extensions" registry with a reference to this specification and allocate a value of TBD to for this. [[ Note to RFC Editor: TBD will be allocated by IANA. ]] </ins> Considerations for this type of extension are described in Section 5 of RFC4366 and requires "IETF Consensus". 7.4. <del> IANA is requested to add srtp_ekt_message as an new descriptions name to the "TLS ContentType Registry" table of the "Transport Layer Security (TLS) Extensions" registry with a reference to this specification, a DTLS-OK value of "Y", and allocate a value of TBD to for this content type.  Note to RFC Editor: TBD will be allocated by IANA. </del> <ins> IANA is requested to add as a new entry in the "TLS HandshakeType Registry" table of the "Transport Layer Security (TLS) Parameters" registry with a reference to this specification, a DTLS-OK value of "Y", and allocate a value of TBD to for this content type. [[ Note to RFC Editor: TBD will be allocated by IANA. ]] </ins> This registry was defined in Section 12 of RFC5246 and requires "Standards Action".
a ciphertext value C with a length of N bytes. <del> The decryption function returns a plaintext value P that is at least M bytes long, or returns an indication that the decryption operation failed because the ciphertext was invalid (i.e. it was not generated by the encryption of plaintext with the key K). These functions have the property that D(K, E(K, P)) = ( P concatenated with optional padding) for all values of K and P.  Each cipher also has a limit T on the number of times that it can be used with any fixed key value.  The EKTKey MUST NOT be used for encryption more that T times.  Note that if the same EKT packet is retransmitted 3 times, that only counts as 1 encryption. </del> <ins> The decryption function returns a plaintext value P that is M bytes long, or returns an indication that the decryption operation failed because the ciphertext was invalid (i.e. it was not generated by the encryption of plaintext with the key K). These functions have the property that D(K, E(K, P)) = P for all values of K and P.  Each cipher also has a limit T on the number of times that it can be used with any fixed key value.  The EKTKey MUST NOT be used for encryption more that T times.  Note that if the same EKT packet is retransmitted 3 times, that only counts as 1 encryption. </ins> Security requirements for EKT ciphers are discussed in sec.
other aspects of EKT processing.  EKT ciphers are free to use this field in any way, but they SHOULD NOT use other EKT or SRTP fields as an input.  The values of the parameters L, and T MUST be defined by <del> each EKTCipher. </del> <ins> each EKTCipher.  The cipher MUST provide integrity protection. </ins> 2.5.
2.2. <del> For several types of events, it is sometimes impossible to tie them to a specific conceptual QUIC connection (e.g., a packet_dropped event triggered because the packet has an unknown connection_id in the header).  Since qlog events in a trace are typically associated with a single connection, it is unclear how to log these events. Ideally, implementers SHOULD create a separate, individual "endpoint- level" trace file (or group_id value), not associated with a specific connection (for example a "server.qlog" or group_id = "client"), and log all events that do not belong to a single connection to this grouping trace.  However, this is not always practical, depending on the implementation.  Because the semantics of most of these events are well-defined in the protocols and because they are difficult to mis-interpret as belonging to a connection, implementers MAY choose to log events not belonging to a particular connection in any other trace, even those strongly associated with a single connection. Note that this can make it difficult to match logs from different vantage points with each other.  For example, from the client side, it is easy to log connections with version negotiation or retry in the same trace, while on the server they would most likely be logged in separate traces.  Servers can take extra efforts (and keep additional state) to keep these events combined in a single trace however (for example by also matching connections on their four-tuple instead of just the connection ID). </del> <ins> A single qlog event trace is typically associated with a single QUIC connection.  However, for several types of events (for example, a transport-packetdropped event with trigger value of "connection_unknown"), it can be impossible to tie them to a specific QUIC connection, especially on the server. There are various ways to handle these events, each making certain tradeoffs between file size overhead, flexibility, ease of use, or ease of implementation.  Some options include: Log them in a separate endpoint-wide trace (or use a special group_id value) not associated with a single connection. Log them in the most recently used trace. Use additional heuristics for connection identification (for example use the four-tuple in addition to the Connection ID). Buffer events until they can be assigned to a connection (for example for version negotiation and retry events). </ins> 3.
QUIC version 2 endpoints MUST implement the QUIC version 1 specification as described in QUIC, QUIC-TLS, and RFC9002, with the <del> following changes: </del> <ins> following changes. </ins> <del> The version field of long headers is 0x709a50c4. </del> <ins> 3.1. </ins> <del> The salt used to derive Initial keys in Section 5.2 of QUIC-TLS changes to: </del> <ins> The version field of long headers is 0x709a50c4. </ins> <del> The labels used in QUIC-TLS to derive packet protection keys (Section Section 5.1 of QUIC-TLS), header protection keys (Section Section 5.4 of QUIC-TLS), Retry Integrity Tag keys (Section Section 5.8 of QUIC-TLS), and key updates (Section Section 6.1 of QUIC-TLS) change from "quic key" to "quicv2 key", from "quic iv" to "quicv2 iv", from "quic hp" to "quicv2 hp", and from "quic ku" to "quicv2 ku", to meet the guidance for new versions in Section Section 9.6 of QUIC-TLS of that document. </del> <ins> 3.2. </ins> <del> The key and nonce used for the Retry Integrity Tag (Section 5.8 of QUIC-TLS) change to: </del> <ins> Initial packets use a packet type field of 0b01. 0-RTT packets use a packet type field of 0b10.  Handshake packets use a packet type field of 0b11.  Retry packets use a packet type field of 0b00. 3.3. 3.3.1. The salt used to derive Initial keys in Section 5.2 of QUIC-TLS changes to: 3.3.2. The labels used in QUIC-TLS to derive packet protection keys (Section Section 5.1 of QUIC-TLS), header protection keys (Section Section 5.4 of QUIC-TLS), Retry Integrity Tag keys (Section Section 5.8 of QUIC-TLS), and key updates (Section Section 6.1 of QUIC-TLS) change from "quic key" to "quicv2 key", from "quic iv" to "quicv2 iv", from "quic hp" to "quicv2 hp", and from "quic ku" to "quicv2 ku", to meet the guidance for new versions in Section Section 9.6 of QUIC-TLS of that document. 3.3.3. The key and nonce used for the Retry Integrity Tag (Section 5.8 of QUIC-TLS) change to: </ins> 4.
Finally QUIC-VN provides two mechanisms for endpoints to negotiate the QUIC version to use.  The "incompatible" version negotiation <del> method can support switching from any initial QUIC version to any other version with full generality, at the cost of an additional round-trip at the start of the connection.  "Compatible" version negotiation eliminates the round-trip penalty but levies some restrictions on how much the two versions can differ semantically. </del> <ins> method can support switching from any QUIC version to any other version with full generality, at the cost of an additional round-trip at the start of the connection.  "Compatible" version negotiation eliminates the round-trip penalty but levies some restrictions on how much the two versions can differ semantically. </ins> QUIC version 2 is meant to mitigate ossification concerns and exercise the version negotiation mechanisms.  The only change is a
data, unless priorities specified by the application indicate otherwise (see stream-prioritization). <ins> Even though a sender is encouraged to assemble frames containing up- to-date information every time it sends a packet, it is not forbidden to retransmit frames of lost packets as they are.  A receiver MUST accept packets containing an outdated frame, such as a MAX_DATA frame carrying a smaller maximum data than one found in an older packet. </ins> Upon detecting losses, a sender MUST take appropriate congestion control action.  The details of loss detection and congestion control are described in QUIC-RECOVERY.
QUIC Stream ID for a client-initiated bidirectional stream encoded as a variable-length integer.  A client MUST treat receipt of a GOAWAY frame containing a Stream ID of any other type as a connection error <del> of type HTTP_MALFORMED_FRAME. </del> <ins> of type HTTP_WRONG_STREAM. </ins> Clients do not need to send GOAWAY to initiate a graceful shutdown; they simply stop making new requests.  A server MUST treat receipt of
definitions) is closed.  A connection enters the draining state when the idle timeout expires. <del> Each endpoint advertises its own idle timeout to its peer.  The idle timeout starts from the last packet received.  In order to ensure that initiating new activity postpones an idle timeout, an endpoint restarts this timer when sending a packet.  An endpoint does not postpone the idle timeout if another packet has been sent containing frames other than ACK or PADDING, and that other packet has not been acknowledged or declared lost.  Packets that contain only ACK or PADDING frames are not acknowledged until an endpoint has other frames to send, so they could prevent the timeout from being refreshed. </del> <ins> Each endpoint advertises its own idle timeout to its peer.  An enpdpoint restarts any timer it maintains when a packet from its peer is received and processed successfully.  The timer is also restarted when sending a packet containing frames other than ACK or PADDING (an ACK-eliciting packet, see QUIC-RECOVERY), but only if no other ACK- eliciting packets have been sent since last receiving a packet. Restarting when sending packets ensures that connections do not prematurely time out when initiating new activity. </ins> The value for an idle timeout can be asymmetric.  The value advertised by an endpoint is only used to determine whether the
result is smaller than the min_rtt, the RTT should be used, but the ack delay field should be ignored. <del> A sender calculates both smoothed RTT and RTT variance similar to those specified in RFC6298, see on-ack-received. </del> <ins> A sender calculates both smoothed RTT (SRTT) and RTT variance (RTTVAR) similar to those specified in RFC6298, see on-ack-received. </ins> A sender takes an RTT sample when an ACK frame is received that acknowledges a larger packet number than before (see on-ack-
available and unused connection IDs.  While each endpoint independently chooses how many connection IDs to issue, endpoints SHOULD provide and maintain at least eight connection IDs.  The <del> endpoint SHOULD do this by always supplying a new connection ID when a connection ID is retired by its peer or when the endpoint receives a packet with a previously unused connection ID.  Endpoints that initiate migration and require non-zero-length connection IDs SHOULD provide their peers with new connection IDs before migration, or risk the peer closing the connection. </del> <ins> endpoint SHOULD do this by supplying a new connection ID when a connection ID is retired by its peer or when the endpoint receives a packet with a previously unused connection ID.  However, it MAY limit the frequency or the total number of connection IDs issued for each connection to avoid the risk of running out of connection IDs (see reset-token). An endpoint that initiates migration and requires non-zero-length connection IDs SHOULD ensure that the pool of connection IDs available to its peer allows the peer to use a new connection ID on migration, as the peer will close the connection if the pool is exhausted. </ins> 5.1.2.
using the KDF provided by TLS.  In TLS 1.3, the HKDF-Expand-Label function described in Section 7.1 of TLS13 is used, using the hash function from the negotiated cipher suite.  Other versions of TLS <del> MUST provide a similar function in order to be used QUIC. </del> <ins> MUST provide a similar function in order to be used with QUIC. </ins> The current encryption level secret and the label "quic key" are input to the KDF to produce the AEAD key; the label "quic iv" is used
in hexadecimal notation.  Future versions of QUIC SHOULD generate a new salt value, thus ensuring that the keys are different for each version of QUIC.  This prevents a middlebox that only recognizes one <del> version of QUIC from seeing or modifying the contents of handshake packets from future versions. </del> <ins> version of QUIC from seeing or modifying the contents of packets from future versions. </ins> The HKDF-Expand-Label function defined in TLS 1.3 MUST be used for Initial packets even where the TLS versions offered do not include
The "extension_data" field of the quic_transport_parameters extension contains a value that is defined by the version of QUIC that is in use.  The quic_transport_parameters extension carries a <del> TransportParameters when the version of QUIC defined in QUIC- </del> <ins> TransportParameters struct when the version of QUIC defined in QUIC- </ins> TRANSPORT is used. The quic_transport_parameters extension is carried in the ClientHello