jiebi/CodeConvo huggingface dataset:
Change:
the underlying hash function for HKDF RFC5869.  SS and ES denote the sources from the table above. <del> The traffic keys are computed from xSS, xES, and the master_secret as described in traffic-key-calculation below. </del> <ins> The traffic keys are computed from xSS, xES, and the traffic_secret as described in traffic-key-calculation below.  The traffic_secret may be updated throughout the connection as described in updating- traffic-keys. </ins> Note: although the steps above are phrased as individual HKDF-Extract and HKDF-Expand operations, because each HKDF-Expand operation is

Discussion:
Is good.
The counter has a size of (2^64-1).The records are max (2^14 + 2048). So, my bold calculation would come to (2^64-1) / (2^14 + 2048) / 2^40 = 910.22 TiB of data. In Big Data, video streaming and other mass data cases 910TB data can be a limitation. I would like to propose the counter to go to 2^128-1, which would result in a connection that can reach (2^128-1) / (2^14 + 2048) / 2^80 = 1.52 * 10^10 YiB. If byte preservation is an issue, I'm willing to accept 2^96-1 as the counter max, resulting in (2^96-1) / (2^14 + 2048) / 2^80 = 3.55 YiB as maximum connection.
On a 40Gibit line this will take less time than one might expect: URL (let's say 2.5-3 days with overhead).
Why do you divide by (2^14 + 2048)? Shouldn't it be a multiplication with the minimum record size?
I don't see much support for this. Please take it to the list if you want to pursue it.
Consensus at interim: No protocol action needed. Add calculations to security considerations.
Also, consensus is that the math above is wrong.
NAME would you be willing to contribute a PR with a paragraph or two of guidance on the limits for AES-GCM and ChaCha20
Yes. What happened to the Key Update message? I can't find it in the text, and that would be a logical place to mention the limitations as well as in the security considerations section.
URL If you want to just send a PR against that branch that would be fine. Or really, whatever form you want and I can manually merge.
If we ditch renegotiation (), then we will need a way to rekey sessions to extend their lifetime. Nico suggests that sending ChangeCipherSpec and then using an increasing counter to extract new keys (i.e., add a counter to the key expansion PRF input), which would seem to be sufficient.

We have asked David McGrew about the theoretical limits on AES-GCM, we can find the same info for ChaCha+Poly1305. When we have that info, we will make an assessment as to how urgent this is. That will determine how soon we define this mechanism. NAME noted that you don't even have to negotiate to enable rekeying: if you send the rekey message and rekey, your connection will either be rekeyed, or killed by the peer.
Change:
FEC describes the sending of redundant information in an outgoing packet stream so that information can still be recovered even in the <del> face of packet loss.  There are multiple ways in which this can be accomplished; this section enumerates the various mechanisms and describes their tradeoffs. </del> <ins> face of packet loss.  There are multiple ways this can be accomplished for RTP media streams RFC3550; this section enumerates the various mechanisms available and describes their tradeoffs. </ins> 3.1. This approach, as described in RFC5956, Section 4.3, sends FEC <del> packets as an independent SSRC-multiplexed stream, with its own SSRC and payload type.  While this approach can protect multiple packets of the primary encoding with a single FEC packet, each FEC packet will have its own IP+UDP+RTP+FEC header, and this overhead can be excessive in some cases, e.g., when protecting each primary packet with a FEC packet. </del> <ins> packets as an independent RTP stream with its own synchronization source (SSRC, RFC3550) and payload type, multiplexed with the primary encoding.  While this approach can protect multiple packets of the primary encoding with a single FEC packet, each FEC packet will have its own IP+UDP+RTP+FEC header, and this overhead can be excessive in some cases, e.g., when protecting each primary packet with a FEC packet. </ins> This approach allows for recovery of entire RTP packets, including the full RTP header. 3.2. <del> This approach, as descibed in RFC2198, allows for redundant data to </del> <ins> This approach, as described in RFC2198, allows for redundant data to </ins> be piggybacked on an existing primary encoding, all in a single packet.  This redundant data may be an exact copy of a previous packet, or for codecs that support variable-bitrate encodings,

Discussion:
While reading the document, I wrote down the following notes that the editor may take into account when revising the document: in 3.1, expland SSRC on first usage and say that this is about sending streams over RTP somewhere early on (I assume this is implied by using the term WebRTC but for outsiders like me it may help to be more specific). Acknowledged. stylistic: I am not a big fan of using citations like '[RFC2198]' as ordinary words or nouns, it makes text difficult to follow unless you know the RFC numbers by heart and your brain translates them back to something meaningful on the fly. This makes texts more difficult to read for outsiders. Example: This mechanism is similar to the [RFC2198] mechanism described above. I prefer this: This mechanism is similar to the redundant encoding mechanism described above. There are couple of such usages of [RFCXXXX] in the document OK. add reference for PCMU OK. Reminder to self, RFC 5391.
Change:
responsible for verifying the server's identity in its certificate. [[TODO: Some more analysis needed in this case, as it is a little <del> odd, and probably some precise rules about handling ESNI and no SNI </del> <ins> odd, and probably some precise rules about handling ECHO and no SNI </ins> uniformly?]] <del> 8. </del> <ins> 12. </ins> <del> 8.1. </del> <ins> 12.1. </ins> IANA is requested to create an entry, encrypted_server_name(0xffce), in the existing registry for ExtensionType (defined in RFC8446), with "TLS 1.3" column values being set to "CH, EE", and "Recommended" column being set to "Yes". <del> 8.2. </del> <ins> 12.2. </ins> <del> IANA is requested to create an entry, esni_required(121) in the </del> <ins> IANA is requested to create an entry, echo_required(121) in the </ins> existing registry for Alerts (defined in RFC8446), with the "DTLS-OK" column being set to "Y". <del> 8.3. IANA is requested to create an entry, ESNI(0xff9f), in the existing registry for Resource Record (RR) TYPEs (defined in RFC6895) with "Meaning" column value being set to "Encrypted SNI". </del>

Discussion:
This change implements the ESNI -> ECHO design discussed in Singapore. There a couple pending TODOs, particularly around cross-CH HRR binding, but the meat is what's currently being analyzed. cc NAME NAME NAME NAME
This still seems a bit rough, but I think better in the spec than out.
Change:
The authors would like to thank David Benjamin, Eric Rescorla, Nick Sullivan, Martin Thomson, Hubert Kario, and other members of the TLS Working Group for discussions on earlier versions of this draft. <ins> Viktor Dukhovni contributed text allowing clients to send multiple counts in a ticket request. </ins>

Discussion:
This is without ticket re-use text. This also includes changes from . The following table outlines the ticket request values for a a client that wants N tickets and always attempts to race a connection across K paths. Did I get this right? Does this make sense? Should we put this in the document directly?
NAME NAME do you think we should include the table in the PR's description in the text? I think its contents are implied from the text, so adding more text is just being verbose. But I could be persuaded otherwise.
I think that it might be confusing. For instance, I see no reason that a client wouldn't have a fixed configuration. A client that never races resumptions could send N and 1 always.
Can you please provide text?
NAME I can't really provide text as I'm unclear on what the field is trying to even describe.
Change:
Multiple invocations of ReceivedPartial deliver data for the same Message by passing the same messageContext, until the endOfMessage <del> flag is delivered.  All partial blocks of a single Message are delivered in order without gaps.  This event does not support delivering discontiguous partial Messages. </del> <ins> flag is delivered or a ReceiveError occurs.  All partial blocks of a single Message are delivered in order without gaps.  This event does not support delivering discontiguous partial Messages. </ins> If the minIncompleteLength in the Receive request was set to be infinite (indicating a request to receive only complete Messages),

Discussion:
1 tiny fix suggested to make the text a little clearer (because the default "complete message" delivery may need a de-framer, or the whole Connection may function as a message), and pointed at a possible error when delivering partial data (it's already written elsewhere, but the suggestion makes a sentence more correct, I believe).
Looks good, thanks!
lgtm
Change:
requested address, and that it can also assign some requested addresses but not others. <ins> If an endpoint receives an ADDRESS_REQUEST capsule that contains zero Requested Addresses, it MUST abort the IP proxying request stream. </ins> 4.6.3. The ROUTE_ADVERTISEMENT capsule (see iana-types for the value of the

Discussion:
"The ADDRESS_REQUEST capsule contains a sequence of zero or more Requested Addresses." In cases there are zero Requested Addresses what does this mean? It appears that this is an even less determined form than the all zero block , that at least indicates an address family support or preference as well as prefix length by including one or two all-zero address of the families the endpoint want assigned? Should this be explicitly stated?
Change:
functionality needed to provide a transport service across a network, as required by the abstract interface. <del> Connection Group: A set of Connections that share properties.  For multiplexing transport protocols, the Connection Group defines the set of Connections that can be multiplexed together. </del> <ins> Connection Group: A set of Connections that share properties and caches.  For multiplexing transport protocols, only Connections within the same Connection Group are allowed be multiplexed together.  Applications can use their explicitly defined Connection Groups to control caching boundaries, as discussed in groups. </ins> Path: Represents an available set of properties that a local system can use to communicate with a remote system, such as

Discussion:
Alternate proposal to address (old PR was "Add CacheContext to architecture and API", ) Define explicit Connection Groups as a way to define caching boundaries Update TLS 1.3 references to RFC 8446
This is a light-weight approach, but seems a little heavy-handed. I thought connection groups were a tool to model multi-streaming. With this PR, they become a fuzzy thing between cache context and multi-streaming abstraction. This may be the better choice, but ist definitely an Architecture decision. I liked the cache original context more.
The result of the interim discussion was that we didn't like a separate cache context object as much. Based on the discussion, we need some abstraction to say "these connections don't share state with the rest of the connections in my process, and can share between one another". The Group is a convenient way to do this. Note that you can just have one connection in its own group even. In some ways, it solves a lot of problems—it isn't sensical to say that connections in a Group can not share cache state. It I multiplex, I'm by default sharing TLS state. So if we have a separate cache context, we'll need some prohibition that you can't have multiple connections in a group have different cache contexts. Using the group as the way to define the boundary solves this.
I agree that it solves a lot of Problems and is an easy-to-use solution. The more I think about it, the more I like it. If we agree that we want to go down this road, definitely a +1 from my side modulo NAME comments. Still, if we land this one, we need to add some means of manually managing connection groups to the API in the next round.
NAME please re-review!
NAME I updated the text to avoid the implication about cloning. I didn't intend to change the behavior for Clone() being required to get multiplexing. I was more thinking that the use of the cache could be managed implicitly, while still requiring calling Clone() to actually multiplex. But, for now, I removed the text about implicit groups. Please check that this resolves your concerns!
Thanks for the reviews and input!
share NAME concerns, approving so we can submit a draft to discuss in prague...Looks good to me!LGTM! Thanks for the fixThanks – Looks good to me!
Change:
security comes when information can be vouched for by hardware or by ROM code, especially if such hardware is physically resistant to hardware tampering.  The component that is implicitly trusted is <del> often referred to as a Root of Trust. </del> <ins> often referred to as a root of trust. </ins> A conveyance protocol that provides authentication and integrity protection can be used to convey unprotected Evidence, assuming the

Discussion:
Per design team meeting today Signed-off-by: Dave Thaler
I think it should be root of trust because it is not a defined term like Attester or Verifier.
Lower case is fine, I think. Any objections?
Change:
Abstract <del> This document describes a number of changes to TLS and DTLS IANA registries that range from adding notes to the registry all the way to changing the registration policy.  These changes were mostly motivated by WG review of the TLS- and DTLS-related registries undertaken as part of the TLS 1.3 development process. </del> <ins> This document updates the changes to TLS and DTLS IANA registries made in RFC 8447.  It adds a new value "D" for discouraged to the recommended column of the selected TLS registries. </ins> <del> This document obsoletes RFC 8447 and updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, and 7301. </del> <ins> This document updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, 7301, and 8447. </ins> 1. This document instructs IANA to make changes to a number of the IANA registries related to Transport Layer Security (TLS) and Datagram <del> Transport Layer Security (DTLS). Most of the instructions included herein and previously included in RFC8447, which this document obsoletes, were motivated by the development of TLS 1.3 RFC8446.  The changes ranged from simple, e.g., adding notes, to complex, e.g., changing a registry's registration policy.  Instead of listing the changes and their rationale here in the introduction, each section provides rationale for the proposed change(s).  The instructions in this document revise the values of "Recommended" column, applies the new value to the registries, and adds this column as noted in orphaned-registries. There are also instructions to update references, including replacing references to RFC8446 with I-D.ietf-tls-rfc8446bis and RFC8447 with I-D.ietf-tls-rfc8447bis. This document proposes no changes to the registration policies for TLS Alerts I-D.ietf-tls-rfc8446bis, TLS ContentType I-D.ietf-tls- rfc8446bis, TLS HandshakeType I-D.ietf-tls-rfc8446bis, and TLS Certificate Status Types RFC6961 registries; the existing policies (Standards Action for the first three; IETF Review for the last), are appropriate for these one-byte code points because of their scarcity. </del> <ins> Transport Layer Security (DTLS).  These changes update the changes made in RFC8447. This specification updates the "Recommended" column in TLS registries to define a third value "D" for items that are discouraged. </ins> 2.

Discussion:
Updated introduction and recommended column section. Deleted some irrelevant sections.
Changed from obsolete to update.
Obsoleting RFC 8447 means duplicating a lot of text and making changes to it which makes the document have awkward wording and makes the changes difficult to follow. I think it would be clearer if it were an update and just listed the changes. see Extension Types PR
At IETF 115, there was general agreement that this document could be an update as opposed to an obsolete to make it easier on IANA.
These are nits.
Change:
For example, if the dynamic table is 100 bytes, then the Required Insert Count will be encoded modulo 6.  If a decoder has received 10 <del> inserts, then an encoded value of 3 indicates that the Required </del> <ins> inserts, then an encoded value of 4 indicates that the Required </ins> Insert Count is 9 for the header block. 4.5.1.2.

Discussion:
The algorithm was updated at somepoint but the example was lagging.
Insert Count will be encoded modulo 6. If a decoder has received 10 inserts, then an encoded value of 3 indicates that the Required Insert Count is 9 for the header block. should be Insert Count will be encoded modulo 6. If a decoder has received 10 inserts, then an encoded value of 4 indicates that the Required Insert Count is 9 for the header block. Background: I implemented ReqInsertCount for decoder. When I test it with: MaxTableCapacity = 100 EncodedInsertCount = 3 TotalNumberOfInserts = 10 My function returns 8, not 9.I guess that EncodedInsertCount = 4 is right since ReqInsertCount for encoder calculates 4 with ReqInsertCount = 9. NAME pointed out that it looks like the algorithm was replaced, and the example text we are looking at is left as is.
Change:
connectivity, reduced throughput and increased latency, as well as increased cost in case of TURN relay. <ins> During experimental testing of the mDNS technique across a set of known mDNS-aware endpoints that had configured a STUN server but not a TURN server, the observed impact to ICE connection rate was 2% (relative) when mDNS was enabled on both sides, compared to when mDNS was only enabled on one side.  In this testing, the percentage of connections that required STUN (i.e., went through a NAT) increased from 94% to 97%, indicating that mDNS succeeded about half the time, and fell back to NAT hairpin for the remainder.  The most likely explanation for the overall connection rate drop is that hairpinning failed in some cases. </ins> One potential mitigation, as discussed in privacy, is to not conceal candidates created from RFC4941 IPv6 addresses.  This permits connectivity even in large internal networks or where mDNS is <del> disabled. The exact impact of the mDNS technique is being researched experimentally and will be provided before publication of this document. </del> <ins> disabled.  Future versions of this document will include experimental data regarding this option. </ins> 4.2.

Discussion:
ping
Will we get sources for these numbers that elaborate distribution and regional differences?
LGTM modulo the thought on mentioning the potential impact of c= line before the update.
No answer to my question?
NAME I struggled to respond to the question since it's so open-ended, and really outside the scope of this PR. Suggest filing an issue and we can discuss more there.
Change:
Some deployed in-network functions distinguish pure-acknowledgment (ACK) packets from packets carrying upper-layer data in order to attempt to enhance performance, for example by queueing ACKs <del> differently or manipulating ACK signaling.  Distinguishing ACK packets is trivial in TCP, but not supported by QUIC, since </del> <ins> differently or manipulating ACK signaling RFC3449.  Distinguishing ACK packets is possible in TCP, but is not supported by QUIC, since </ins> acknowledgment signaling is carried inside QUIC's encrypted payload, and ACK manipulation is impossible.  Specifically, heuristics attempting to distinguish ACK-only packets from payload-carrying

Discussion:
Add ref to RFC3449 rather than explain how this works.
The text says: “Distinguishing ACK packets is trivial in TCP,” arguably this is not trivial, since you need to handle data and ACKs and exclude implications of TCP options. I’d prefer to say “possible” than “trivial”.
It's more than possible, it's easy. I don't quite follow which TCP options you're referring to. I can only think of SACK, which just reduces the number of them. Why is this not as trivial as "If only the ACK bit is set, and there's no payload, it's an ACK." ? (Yes, truly bidirectional flows will have payload, but then I would argue they are not simple ACK packets.)
SACK adds an obvious widley deployed complication for TCP; ECN feedback also; some methods have simply used packet size. I know there are various forms ACK decimation/filtering/etc, some even delve into IP encaps to do this, I just don't want to convey a message that this "trivial" to get a good solution. The key point is that QUIC does not allow any of this without keying information.
I see. So we need a word that says it's a bit more complex than "trivial", but still reasonably simple (esp. in comparison with QUIC). "Possible" would work.
Yes, "possible" is indeed fine. Shall I make a PR? Gorry
I'd say yes.
Change:
The result is that if there are N distinct media types, then candidates will be gathered for for N media streams.  This policy balances desire to multiplex with the need to ensure basic audio <del> and video can still be negotiated in legacy cases. </del> <ins> and video can still be negotiated in legacy cases.  When acting as answerer, if there is no bundle group in the offer, the implementation will reject all but the first m= section of each type. </ins>

Discussion:
If a non-bundle offer is received, and "max-bundle" is used, the first m= section should be accepted and all others rejected. This will ensure the same result whether or not the "max-bundle" endpoint is the offerer or answerer (ignoring some unlikely corner cases), and will prevent a lone media description from being rejected if the remote offer didn't contain a bundle group simply because it wasn't necessary. Also added equivalent rules for the "balanced" bundle policy.
This LGTM
This isn't exactly what I had in mind for 'balanced', but this might not be an issue in practice. If the answerer needs to handle multiple m= lines that are unbundled, it can set max-compat.
lgtm
Change:
IANA is requested to assign two values from the NamedCurve registry with names eddsa_ed25519(TBD3) and eddsa_ed448(TBD4) with this document as reference.  IANA has already assigned the value 29 to <del> ecdh_x25519, and the value 30 to ecdh_x448(TBD2). </del> <ins> ecdh_x25519, and the value 30 to ecdh_x448. </ins> IANA is requested to assign one value from SignatureAlgorithm Registry with name eddsa(TBD5) with this document as reference.

Discussion:
Should remove the "TBD2" after ecdh_x448.
Looks good to me. Thanks.
Change:
"supported_signature_algorithms" value: %%% Signature Algorithm Extension enum { none(0), md5_RESERVED(1), <del> sha1, sha224_RESERVED(3), sha256(4), sha384(5), sha512(6), (255) } </del> <ins> sha1(2), sha224_RESERVED(3), sha256(4), sha384(5), sha512(6), (255) } </ins> HashAlgorithm; [[TODO: IANA considerations for new SignatureAlgorithm value]]

Discussion:
I think sha1 is supposed to be removed from this? If not, the int is missing sha2. enum { none(0), sha1, sha256(4), sha384(5), sha512(6), (255) } HashAlgorithm;
No, it's there because you can offer it for certs. It is missing the assignment. PRs welcome :)
Okay so it's just missing the "(2)". I'll get on the PR.
Fixed by PR