jiebi/CodeConvo huggingface dataset:
Change:
For servers (in EncryptedExtensions), this extension contains the following structure: <ins> Indicates whether the server processed the client ESNI extension. (See handle-server-response and server-behavior.} </ins> The contents of ClientESNIInner.nonce.  (See client-behavior.) <ins> One or more ESNIKeys structures containing the keys that the client should use on subsequent connections to encrypt the ClientESNIInner structure. This protocol also defines the "esni_required" alert, which is sent by the client when it offered an "encrypted_server_name" extension which was not accepted by the server. Finally, requirements in client-behavior and server-behavior require implementations to track, alongside each PSK established by a previous connection, whether the connection negotiated this extension with the "esni_accept" response type.  If so, this is referred to as an "ESNI PSK".  Otherwise, it is a "non-ESNI PSK".  This may be implemented by adding a new field to client and server session states. </ins> 5.1. <ins> 5.1.1. </ins> In order to send an encrypted SNI, the client MUST first select one of the server ESNIKeyShareEntry values and generate an (EC)DHE share in the matching group.  This share will then be sent to the server in

Discussion:
(WG email coming shortly.) ESNI has different compatibility characteristics than most TLS extensions. It involves client state, and encrypting the SNI makes the ClientHello unusable for servers that do not have the key or do not implement ESNI. This breaks common rollout and rollback strategies and places strong requirements on DNS/server consistency. This makes deploying ESNI risky for servers. This change aims to reduce these deployment risks. ESNI is much more useful if widely deployed. Moreover, if ESNI is unreliable due to complex requirements on the server, clients will be disincentivized to implement it. The DNS/server consistency requirements also disincentivize rotating keys (section 7.2.5). This change introduces the notion of a "public name" which allows the client to receive authenticated signals from the server that the ESNIKeys are out of sync, so clients can safely repair key mismatches. It also aligns with existing server behavior before ESNI, so partial rollouts and rollbacks can also be handled. The fix for the latter also handles MITM scenarios, replacing the existing client recommendation: The public name notion fixes a bug in that text: an attacker could disable ESNI on all servers, given the existence of any such server.
And, as I write this, I realize I forgot to deal with Stephen's comment on the thread about the middlebox stuff! It's quite late here, so I will reword that tomorrow morning.
Currently, the connect fails when a mismatch occurs. An alternative strategy might be to return a new ESNI key that is then used for a subsequent connection.
How to understand the reliability of the public key from server?
I see that I missed something about disabling. I think that this could be a lot more explicit about the three primary cases that I talk about in the comments below.Looks mostly good, but added some nits and clarification questions.
Change:
4.5.1.2. <del> The "Base" is used to resolve references in the dynamic table as </del> <ins> The Base is used to resolve references in the dynamic table as </ins> described in relative-indexing. To save space, the Base is encoded relative to the Required Insert <del> Count using a one-bit sign ('S') and the "Delta Base" value.  A sign </del> <ins> Count using a one-bit sign ('S') and the Delta Base value.  A sign </ins> bit of 0 indicates that the Base is greater than or equal to the value of the Required Insert Count; the decoder adds the value of Delta Base to the Required Insert Count to determine the value of the

Discussion:
The new principle is to only use backticks when referring to variables in pseudocode. There were two such instances that remain.
In I came up with a principle that might apply to use of . Field names, frame names, transport parameter names, and error codes don't use any form of decoration. But if reference is being made to a variable in pseudocode, we would use backticks to distinguish it from. Qpack is a little tricky here because there is a mix of things. Note: backticks are quoted in for HTML and in double quotes () in text output. Sparing use is probably best.
WFM. Thanks. I was never clear on whether "Base" or "Required Insert Count" referred to pseudocode variables or not.
Change:
setting of the "vad" value in the signaling of the client to mixer audio level header extension described in RFC6464, Section 4. <del> 5.2.4. RFC3264 direction attributes (defined in Section 6.1) in offers are chosen according to the states of the RtpSender and RtpReceiver of a given RtpTransceiver, as follows: </del> 5.3. When createAnswer is called, a new SDP description must be created

Discussion:
Can you separate this from the ICE changes that are also in this PR?
Oops, yeah
NAME PTAL
LGTM
See URL
Change:
actual thresholds to declare a path unusable are implementation specific. <del> The connection should attempt to use multiple paths in parallel in order to minimize loss and delay.  The actual strategy is implementation specific. </del> <ins> The connection should attempt to minimize the latency for interactive traffic patterns by transmitting data across multiple paths when it is beneficial to do so.  The goal of minimizing the latency will be balanced against the cost of each of these paths, meaning that depending on the cost of the lower-latency path, the scheduling might choose to use a higher-latency path.  Traffic can be scheduled such that data may be transmitted on multiple paths in parallel to achieve the lowest latency possible.  The specific scheduling algorithm is implementation-specific. </ins> The connection should attempt to use multiple paths in parallel in order to maximize bandwidth and possibly overcome bandwidth

Discussion:
Get a better/more formal explanation of Interactive mode for multipath based on our experience with Siri, etc.
Proposal from Christoph Paasch: The connection should attempt to minimize the latency for interactive traffic patterns by transmitting data across multiple paths. The goal of minimizing the latency will be balanced against the cost fo each of these paths, meaning that depending on the cost of the lower latency path the scheduling might choose to use a higher latency path. Finally, the scheduling of the traffic can be done such that data may be transmitted on multiple paths in parallel to achieve the lowest latency possible.
Thanks for following up on this one.LGTM
Change:
Generate a unique mDNS hostname.  The unique name MUST consist of a version 4 UUID as defined in RFC4122, followed by ".local". <del> Register the candidate's mDNS hostname using Multicast DNS. </del> <ins> Register the candidate's mDNS hostname as defined in RFC6762. </ins> If registering of the mDNS hostname fails, abort these steps.  The candidate is not exposed.

Discussion:
Or alternatively consistently use mDNS, but mention in the intro that this refers to Multicast DNS {{RFC6762}}
Yeah, I think we should do the latter. That's what 6762 does.
Change:
The Original Header Block (OHB) contains the original values of any modified RTP header fields.  In the encryption process, the OHB is <del> appended to the RTP payload.  In the decryption process, the receiving endpoint uses it to reconstruct the original RTP header, so that it can pass the proper AAD value to the inner transform. </del> <ins> included in an SRTP packet as described in rtp-operations.  In the decryption process, the receiving endpoint uses it to reconstruct the original RTP header, so that it can pass the proper AAD value to the inner transform. </ins> The OHB can reflect modifications to the following fields in an RTP header: the payload type, the sequence number, and the marker bit.

Discussion:
This PR responds to IESG review comments from Magnus Westerlund, except for his comments on RED, which I haven't quite figured out how to address yet.
LGTM with nits
Change:
server's selected version is contained in the ServerHello.version field as in previous versions of TLS. <ins> 4.2.1.1. RFC EDITOR: PLEASE REMOVE THIS SECTION While the eventual version indicator for the RFC version of TLS 1.3 will be {3, 4}, implementations of draft versions of this specification SHOULD instead advertise {0x7f, [draft-version]} in their "supported_versions" extension, in ServerHello.version, and HelloRetryRequest.server_version.  This allows pre-RFC implementations to safely negotiate with each other, even if they would otherwise be incompatible. </ins> 4.2.2. %%% Cookie Extension

Discussion:
By the way, you also need to update Version Negotiation section of the .
lgtm
Done , Xiaoyin Liu EMAIL wrote:
Change:
document RFC8406: Channel and link codings are gathered in the PHY layer coding and <del> are out of the scope of this document. </del> <ins> are out of the scope of this document.  It focuses on situations where coding is not widely deployed in current SATCOM systems. </ins> FEC (also called Application-Level FEC) operates in and above the network layer.

Discussion:
I'm puzzled as to how this document claims that channel and link codings are out of scope - and then talks about channel mode, dealing with varying channel conditions (yet without using channel codings), etc. They're stated as out of scope...
If the intent is treating the overall end-to-end path as some sort of virtual 'channel' that coding packets are applied to, this needs to be said explicitly upfront. If 'channel' means more than one concatenated physical path here, this needs to be said. Unless your audience is only network coding people... the title should likely be 'network coding applicability to satellite-based scenarios' or similar, too. Needs to be really specific for clarity.
In PR , we have changed: "Channel and link codings are gathered in the PHY layer coding and are out of the scope of this document." by "Channel and link codings are gathered in the PHY layer coding and are out of the scope of this document. It focuses on situations where coding is not widely deployed in current SATCOM systems." For the comment on the end-to-end path, the notion of virtual 'channel' depends on the use-case and coding is not applied at the same level. For the title, we have moved from "Network coding and satellites" to "Coding techniques for satellite systems" from version 04 and 05 of the document to be more generic. I guess we should not go back to the "network coding"-like title.
Change:
5. <del> The simultaneous usage of several sending uniflows introduces new </del> <ins> The simultaneous usage of several sending paths introduces new </ins> algorithms (packet scheduling, path management) whose specifications are out of scope of this document.  Nevertheless, these algorithms are actually present in any multipath-enabled transport protocol like

Discussion:
This is really a minor issue, but the word "uniflow" appears just once in the draft, in section 5, packet scheduling. I think the packet scheduling text could simply use the word "path".
Change:
Destination Connection ID it uses in response to an Initial packet from the server. <del> The Destination Connection ID is of arbitrary length, and it could be zero length if the server sends a Retry packet with a zero- length Source Connection ID field.  In this case, the Initial keys provide no assurance to the client that the server received its packet; the client has to rely on the exchange that included the Retry packet for that property. </del> <ins> The Destination Connection ID field could be any length up to 20 bytes, including zero length if the server sends a Retry packet with a zero-length Source Connection ID field.  After a Retry, the Initial keys provide the client no assurance that the server received its packet, so the client has to rely on the exchange that included the Retry packet to validate the server address; see Section 8.1 of QUIC-TRANSPORT. </ins> test-vectors contains sample Initial packets.

Discussion:
These are all small, but neat improvements inspired by the feedback in .
Here are some minor editorial issues: Section 2.1: "TLS provides two endpoints with a way to establish a means of communication over an untrusted medium (that is, the Internet) that ensures that messages they exchange cannot be observed, modified, or forged." I think "observed" as used here is the wrong word. Because the encrypted form of the clear-text message will be possible to observe. Please reformulate to give actual security properties. Section 2.1: "A 0-RTT handshake, in which the client uses information it has previously learned about the server to send Application Data immediately. This Application Data can be replayed by an attacker so it MUST NOT carry a self-contained trigger for any non-idempotent action." Please do not use RFC2119 words "MUST NOT" in overview. I understand the need for emphasis on this. However, I assume this is actually specified normatively elsewhere. So simply using other words to provide the emphasis and possibly a reference to the section defining this normatively. Section 5.2: "Note: The Destination Connection ID is of arbitrary length, and it could be zero length if the server sends a Retry packet with a zero-length Source Connection ID field." To my understanding the DCID is not arbitrary length, it is of any octet length between 0 and 160 bits. Does the Initial processing function need to deal with non QUIC version-1 long header packets?
Based on , labeling this as "editorial"
I think the PR resolves my issues nicely.
I liked that we dropped the MUST NOT, it's already somewhere else. I also like that we point back to quic-trans for the dcid URL
Change:
as the freshest, regardless of the order of arrival.  In order to support existing Observe implementations the OSCORE client implementation MAY set the Observe value to the three least <del> significant bytes of the Partial IV. </del> <ins> significant bytes of the Partial IV; such an implementation needs to make sure that the Observe value for an observe notification without Partial IV is smaller than a notification with Partial IV. </ins> 4.1.3.6.

Discussion:
Solves issue (from review comments by NAME : URL)
According to Jim, the change of always including a Partial IV for notifications (both successful or errors) complicates the code too much, although it simplifies the spec, so he proposes to revert that change. Section 4.1.3.1 - I am unclear why an OSCORE error response can be cached by an OSCORE unaware intermediate would be cached, but a success message is never going to be cached. Based on this, I don't plan to set an outer Max-Age option. In section 5.4 you have the text requestpiv: contains the value of the 'Partial IV' in the COSE object of the request (see Section 5), with one exception: in case of protection or verification of Observe cancellations, the requestpiv contains the value of the 'Partial IV' in the COSE object of the corresponding registration (see Section 4.1.3.5.1). I am unclear how/why this is different for observations. A cancelation is a message, so the IV is the request. A re-registration is a request message, any response would correspond to that request. The only interesting question has to do with updating the MID on a re-registration but not how PIVs work for this field. Section 6.1 - Is a registry needed for the leading byte of compression? Behavior if bits 0, 1, or 2 is set in the flags byte on decode? Section C - given the way that my system is implemented, it would be nice if the outputs included the first full IV to be used for both the sender and the recipient. That would allow for a test that the combination of ids and common ivs is done correctly. In my case I do not have the shared IV available for testing as I immediately or in the id.
Change:
tickets needed for future connections is defined in I-D.ietf-tls- ticketrequests. <del> In the case where EAP-TLS with mutual authentication and ticket establishment with two tickets is successful, the conversation will appear as shown in figbase2. </del> <ins> figbase2 shows an example message flow for a succesfull EAP-TLS full handshake with mutual authentication and ticket establishment of a single ticket. </ins> 2.1.3.

Discussion:
Some of the text describing the figures indicated that TLS 1.3 only has one possible message flow. This pull request change the text to make it is clear that the message flows are examples. Based on discussion on the List initiated by Alan.
Change:
again. For the common (EC)DHE handshake with pre-established certificates, <del> Stream cTLS achieves an overhead of 45 bytes over the minimum </del> <ins> Stream cTLS achieves an overhead of 53 bytes over the minimum </ins> required by the cryptovariables.  For a PSK handshake, the overhead <del> is 21 bytes.  Annotated handshake transcripts for these cases can be found in transcripts. </del> <ins> is 21 bytes.  An annotated handshake transcript can be found in transcripts. </ins> <del> TODO: Update these values. </del> <ins> TODO: Make a PSK transcript and check the overhead. </ins> cTLS supports the functionality of TLS and DTLS 1.3, and is forward- compatible to future versions of TLS and DTLS.  cTLS itself is

Discussion:
The example did not account for the record layer, and seemed to overlook some other details as well.
CTLSClientPlaintext and CTLSServerPlaintext seem to be included in the example exchange but CTLSCiphertext seems to be missing. My understanding is that ServerFlight and ClientFlight are sent over CTLSCiphertext which would add a mimimum of 2 * 11 bytes. It is not explained why the signature is 64 bytes. In TLS 1.3, my understanding is that ecdsasecp256r1sha256 is variable length 12-76 bytes with an average length close to 75 bytes. Changing ecdsasecp256r1sha256 to ed25519 (or ecdsasecp256r1sha256_compact) would make it 64 bytes. The introduction promises an example PSK handshake, but that is missing.
NAME Please review , which attempts to fix the example as you've described.
Change:
UEFI event logs. 'ima': Indicates that the device supports the retrieval of event <del> logs from the Linux Integrity Measurement Architecture (IMA). </del> <ins> logs from the Linux Integrity Measurement Architecture (IMA ima- log).  Also see ima. </ins> 'netequip_boot': Indicates that the device supports the retrieval <del> of netequip boot event logs. </del> <ins> of netequip boot event logs.  See ima and netequip-boot-log. </ins> 2.1.1.2.

Discussion:
Self-approved
Thanks, this does a good job bridging the gap between what we say in the body of the document and what is available in external references.
Change:
toward the User Equipment.  This signal indicates that the User Equipment might need to contact the API Server to receive updated information.  For instance, this signal might be generated when the <del> end of a session is imminent, or when network access was denied. </del> <ins> end of a session is imminent, or when network access was denied.  For simplicity, and to reduce the attack surface, all signals SHOULD be considered equivalent by the User Equipment: as a hint to contact the API.  If future solutions have multiple signal types, each type SHOULD be rate-limited independently. </ins> An Enforcement Device MUST rate-limit any signal generated in response to these conditions.  See section_signal_risks for a

Discussion:
New SHOULD requirement to consider all signals as a single simple hint. Fixes issue Looking for reviewers to confirm this new SHOULD is OK.
Note Benjamin's reply to my question asking for clarification: My reply to that:
Closed in
lgtm
Change:
3.4.2. RtpSenders allow the application to control how RTP media is sent. <ins> An RtpSender is conceptually responsible for the outgoing RTP stream(s) described by an m= section.  This includes encoding the attached MediaStreamTrack, sending RTP media packets, and generating/ processing RTCP for the outgoing RTP streams(s). </ins> 3.4.3. <del> RtpReceivers allows the application to control how RTP media is received. </del> <ins> RtpReceivers allow the application to inspect how RTP media is received.  An RtpReceiver is conceptually responsible for the incoming RTP stream(s) described by an m= section.  This includes processing received RTP media packets, decoding the incoming stream(s) to produce a remote MediaStreamTrack, and generating/ processing RTCP for the incoming RTP stream(s). </ins> 3.5.

Discussion:
Attempts to address issue . Also changed "control" to "inspect" in RtpReceiver description, since an RtpReceiver is readonly and doesn't let an application control anything.
LGTM
Originally raised by Christer Section 3.4.1 talks about ³RtpTranceivers², ³RtpSenders² and ³RtpReceivers². 1) I think they should be introduced in their own section (not within the Session Description Protocol section). 2) I think it should be explained what an RtpXXX really is. At a minimum there should be a reference to the appropriate W3C document. But, as there is text on how they related to SDP m- lines etc, 1 or 2 sentences describing what they are would also be useful.
Section 3.4.1 is its own section, and explains what the RtpTransceiver is. Agree that Sections 3.4.2/3.4.3 (on senders/receivers) could be expanded somewhat. NAME FYI
Resolved by
Change:
signing private key corresponding to the credential at the leaf of the tree indicated by the sender field.  The signature covers the plaintext metadata and message content, which is all of MLSPlaintext <del> except for the "signature" and "membership_tag" fields.  If the sender is a member of the group, the signature also covers the GroupContext for the current epoch, so that signatures are specific to a given group and epoch. </del> <ins> except for the "signature", the "confirmation_tag" and "membership_tag" fields.  If the sender is a member of the group, the signature also covers the GroupContext for the current epoch, so that signatures are specific to a given group and epoch. </ins> The "membership_tag" field in the MLSPlaintext object authenticates the sender's membership in the group.  For an MLSPlaintext with a

Discussion:
As discussed in the mailing list, not having the signature contribute to the new epoch's key schedule leads to a one-off effect where parties stay in sync (with respect to keys) for one more epoch, before inevitably go out of sync. This pull request addresses this issue by including the signature in the confirmed transcript hash rather than the interim transcript hash. See the mailing list for a security consideration of this change. Credit: This pull request was primarily authored by Marta Mularczk; I'm just posting it here for administrative reasons.
Change:
[[OPEN ISSUE: Are there other extensions that would benefit from special treatment, as opposed to hex values.]] <del> 5.1.3. </del> <ins> 3.2.3. </ins> Certificates are a major contributor to the size of a TLS handshake. In order to avoid this overhead when the parties to a handshake have

Discussion:
This update aims to bring the template-based optimization to the center and focuses on the certificiate-based authentication exchange. Included in this version is the idea to omit the random values transmitted by the client and the server by hashes of the ephemeral public keys.
Change:
"nonce" is a 32-octet message containing a client-generated random nonce. <del> "context" is a 32-octet message containing the hash of the original TokenChallenge, SHA256(TokenChallenge). </del> <ins> "challenge_digest" is a 32-octet message containing the hash of the original TokenChallenge, SHA256(TokenChallenge). </ins> "token_key_id" is an Nid-octet identifier for the the token authentication key.  The value of this field is defined by the

Discussion:
We should consider renaming to . This value doesn't need to be a nonce, it's just some origin-selected context that it is binding to. We can also rename the in the Token struct to to make it clear what role it has.