jiebi/CodeConvo huggingface dataset:
Change:
independently retransmit the same data.  To avoid this, HTTP/3 datagrams SHOULD be used. <ins> 9.1. CONNECT-UDP does not create an IP-in-IP tunnel, so the guidance in RFC6040 about transferring ECN marks between inner and outer IP headers does not apply.  There is no inner IP header in CONNECT-UDP tunnels. Note that CONNECT-UDP clients do not have the ability in this specification to control the ECN codepoints on UDP packets the proxy sends to the server, nor can proxies communicate the markings of each UDP packet from server to proxy. A CONNECT-UDP proxy MUST ignore ECN bits in the IP header of UDP packets received from the server, and MUST set the ECN bits to Not- ECT on UDP packets it sends to the server.  These do not relate to the ECN markings of packets sent between client and proxy in any way. </ins> 10. There are significant risks in allowing arbitrary clients to

Discussion:
On a related note, the text in #performance talks about disabling congestion control on a "connection," but I believe this is actually a per-endpoint decision. (The client could easily have more information than the proxy on the tunneled connections).
Even if CONNECT-UDP has no explicit ECN support without an extension, there is ambiguity relating to copying of ECN bits between 'inner' and 'outer' datagrams. MASQUE is not strictly IP-in-IP, though it's close to it, so it's not clear if RFC 6040 applies. Nevertheless, I would propose the following principles: ECN markings on the MASQUE connection SHOULD NOT be copied to any resulting UDP datagrams sent by the proxy; they should apply to the MASQUE connection only. If MASQUE congestion control is disabled per section 9, it MUST mark all packets non-ECT. ECN markings on incoming UDP datagrams SHOULD NOT be copied to the IP headers of MASQUE packets that encapsulate them: upstream congestion should not affect the congestion state of the MASQUE connection. I'm happy to write a PR to that effect.
When using CONNECT-UDP without extensions, the server-facing UDP sockets on the proxy will not be configured to use ECN, so there will not be any ECN markings on the proxy-server path. In other words, ECN will not be in use, so do we need text about it? Adding text to clarify this sounds reasonable, but it probably should be generic to anything in the IP header.
The extensions explicitly concern markings on DATAGRAM frames in the inner connection. The server may very well be sending packets with ECT(0). With no extension, it will eventually stop, but nevertheless these shouldn’t appear in MASQUE IP headers.
Agreed. I'll take you up on your offer to write a PR then :)
Yes, I think that being clear that for this case the two legs needs to be kept seperate unless internal signalling is used on client to proxy leg to influence the external side setting and receiving of these values.
Thanks!
Change:
hosting providers noted above are a particular case. It is RECOMMENDED that the server perform DNS queries and make HTTP <del> and TLS connections from various network perspectives, in order to make MitM attacks harder. </del> <ins> connections from various network perspectives, in order to make MitM attacks harder. </ins> 10.3.

Discussion:
Recent developments[[0]] [[1]] [[2]] have identified real-world server/hosting configurations that violate the assumptions of TLS-SNI-01 and its currently specified replacement, TLS-SNI-02. In light of these issues and the feasibility of addressing them across the entire Internet it seems prudent that the ACME specification remove the affected challenge type pending the development of a better alternative (TLS-SNI-03?). This will allow the draft last-call to proceed while the details of TLS-SNI-03 are worked out. The "Default Virtual Hosts" sub-section of the "Operational Considerations" section is removed since it spoke exclusively to a concern with TLS-SNI-02 validation. When the dust has settled on TLS-SNI-03 we should certainly include a section that describes why TLS-SNI-01/02 were removed that could replace this information. [0]: URL [1]: URL [2]: URL
NAME I don't think we need a place-holder in-doc for this
r+ with the one comment addressedShould there be any mention of that makes sure we use in a future RFC in case if gets re-added?
Change:
MUST NOT reject tokens because they lack opaque data and therefore the packet number. <ins> Shared-state Retry Services use the AES-128-ECB cipher.  Future standards could add new algorithms that use other ciphers to provide cryptographic agility in accordance with RFC7696.  Retry Service and server implementations SHOULD be extensible to support new algorithms. </ins> 7.3.1. On the wire, the token is presented as:

Discussion:
Secure ciphers are much more important for Shared State Retry than for the load balancer stuff and Initial Encryption. Therefore, some crypto agility to allow this mechanism to adapt as ciphers deprecate would be good. The key sequence can also imply a cipher, so we'll add that to the data model. Some fields will vary length based on the cipher. We should also make it so everyone MUST support AES128-GCM.
Change:
connection ID as part of its token validation logic (see token- integrity). <ins> A Retry packet does not include a packet number and cannot be explicitly acknowledged by a client. 17.2.5.3. </ins> The next Initial packet from the client uses the connection ID and token values from the Retry packet; see negotiating-connection-ids. Aside from this, the Initial packet sent by the client is subject to

Discussion:
This was getting a little long. You could get lost in there. The text was fine, it was mostly well structured. All it needed was one small move and some headers.
Change:
request and returns a response with the appropriate response code. The RS uses the dynamically established keys to protect the response, according to used communication security protocol. <del> FIXME: Mention client token. </del> <ins> (FIXME: Mention client token.) </ins> 5.

Discussion:
I have reviewed the protocol section and have made some minor edits. I believe the section is looking good. There were only two items that I believe are worthwhile to discuss: I prefer to use the term endpoint for the /token and /introspect rather than calling them resource. The term endpoint is used in the terminology section and aligns with OAuth. The client token is mentioned in this section and even after looking at the text later in the document I didn't really understood the concept.
Looks good to me. Does anyone else have a strong opinion on the use of "endpoint" vs "resource"? We might need to put a note into the text somewhere to clarify, since CoAP IMHO uses "endpoint" with a slightly different meaning.
Change:
the resolution. The HPKECiphertext values are computed according to the Encrypt <del> function defined in HPKE. </del> <ins> function defined in I-D.barnes-cfrg-hpke. </ins> Decryption is performed in the corresponding way, using the private key of the resolution node and the ephemeral public key transmitted

Discussion:
I'm approving these changes given the current state of the document, but I filed because the KDF stuff is broken. Please make HPKE a normative reference (since it's required to implement). Since it's an Internet-Draft, you don't need to add it to the references section, you can just reference it directly as and the Markdown processor will add the reference. (Change the to for an informative reference.)
Change:
1.1. <del> The thinking behind WebRTC call setup has been to fully specify and control the media plane, but to leave the signaling plane up to the application as much as possible.  The rationale is that different applications may prefer to use different protocols, such as the existing SIP call signaling protocol, or something custom to the particular application, perhaps for a novel use case.  In this approach, the key information that needs to be exchanged is the multimedia session description, which specifies the necessary transport and media configuration information necessary to establish the media plane. </del> <ins> WebRTC call setup has been designed to focus on controlling the media plane, leaving signaling plane behavior up to the application as much as possible.  The rationale is that different applications may prefer to use different protocols, such as the existing SIP call signaling protocol, or something custom to the particular application, perhaps for a novel use case.  In this approach, the key information that needs to be exchanged is the multimedia session description, which specifies the necessary transport and media configuration information necessary to establish the media plane. </ins> With these considerations in mind, this document describes the JavaScript Session Establishment Protocol (JSEP) that allows for full

Discussion:
Fixed my own comment, now LGTM
I think this got all the text from Robert, it was just not a change so it does not show up in diff.
Suggested change to the first sentence of 1.1 OLD: The thinking behind WebRTC call setup has been to fully specify and control the media plane, but to leave the signaling plane up to the application as much as possible. New: WebRTC call setup has been designed to focus on controlling the media plane, leaving signaling plane behavior up to the application as much as possible.
OK
Change:
1. This document provides a way to authenticate one party of a Transport <del> Layer Security (TLS) communication to its peer using a certificate after the session has been established.  This allows both the client and server to prove ownership of additional identities at any time after the handshake has completed.  This proof of authentication can be exported and transmitted out of band from one party to be validated by its peer. </del> <ins> Layer Security (TLS) connection to its peer using a certificate after the session has been established.  This allows both the client and server to prove ownership of additional identities at any time after the handshake has completed.  This proof of authentication can be exported and transmitted out-of-band from one party to be validated by its peer. </ins> This mechanism provides two advantages over the authentication that TLS natively provides:

Discussion:
NAME are you happy with the adjusted text? I don't consider DTLS support to be a big change since the only thing we are relying on from TLS is the exporter interface.
I think that this is sneaking in a big change with the DTLS thing. I'll try to find the email...
Change:
4.5. <del> In contrast to segmented delivery, several applications use UDP or unreliable SCTP to deliver RTP or raw TS-formatted video. </del> <ins> In contrast to segmented delivery, several applications use unreliable UDP or SCTP with its "partial reliability" extension RFC3758 to deliver Media encapsulated in RTP RFC3550 or raw MPEG Transport Stream ("MPEG-TS")-formatted video MPEG-TS, when the media is being delivered in situations such as broadcast and live streaming, that better tolerate occasional packet loss without retransmission. </ins> Under congestion and loss, this approach generally experiences more video artifacts with fewer delay or head-of-line blocking effects.

Discussion:
Also clarified relationship with UDP Behaviors section
I think this is ready to merge. Opinions?
I was more concerned about overlap when I opened , but what's in the section on Unreliable Transport and what's in the section on UDP behaviors seems to read pretty well to me. Opinions?
SRT, TS-Multicast over UDP, etc.
I THINK this is requesting a change in the "Unreliable Transport" section.
I think this one is also ready to close. Opinions?
Change:
For example, suppose there is a group with four members: If member B subsequently generates a Commit based on a secret <del> "leaf_hpke_secret_key", then it would generate the following sequence of path secrets and node secrets: </del> <ins> "leaf_hpke_secret", then it would generate the following sequence of path secrets: </ins> After the Commit, the tree will have the following structure, where <del> "ns[i]" represents the node_secret values generated as described above: </del> <ins> "np[i]" represents the node_priv values generated as described above: </ins> 5.5.

Discussion:
This deals cleanly with groups where the private key size doesn't align neatly with a hash function output size (e.g., X448), and saves a few hash invocations by removing intermediate values. A few editorial changes are included here as well. Depends on .
As discussed on call, folks are comfortable with this. Ready to merge, pending
Please merge when get a chance.
Change:
first Initial packet. This secret is determined by using HKDF-Extract (see Section 2.2 of <del> HKDF) with a salt of 0xafbfec289993d24c9e9786f19c6111e04390a899 and a </del> <ins> HKDF) with a salt of 0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a and a </ins> IKM of the Destination Connection ID field.  This produces an intermediate pseudorandom key (PRK) that is used to derive two separate secrets for sending and receiving.

Discussion:
Also, examples use final version numbers. IMPORTANT: the TLS extension codepoint needs to be updated, both in the text and in the examples (which will result in changes to authentication tags and the affected ciphertext).
I plugged the test vectors into the quiche test suite and it checks out URL
Hey there! We are currently implementing the Initial packet encryption process and it successfully works with the client Initial example from the appendix A.2 of the QUIC-TLS draft. However, when running tests with values for the server Initial example from the appendix A.3, tests regarding the parsing, header sampling, header protection and final encryption result all succeed, except for the header protection mask: the value we generate is: , while the draft explicitly specifies it should be something completely different: . Note that the value we generate is indeed used later on for the header protection and final encryption result, which both reveal successful. Therefore, three possibilities we thought of, in ascending order of probability: Our implementation is completely broken. The mask value provided by the current version of the specification (A.3) is correct, but all others are incorrect. Only the mask value is incorrect, while the rest is correct. We think the last option is the most probable one, as it could just mean it was forgotten to be updated in a recent draft version. If you think this is the case as well, then I would gladly open up a PR in order to close this, I just wanted to make sure beforehand. Otherwise, I would happily accept a tad of guidance towards a correct implementation. Thanks in advance, Paul.
Investigated a bit more. Looking at the result of a , we can see that: 2ebdfd53a is indeed meant to update example vectors, but does it only partially it seems: while 2ebdfd53a is for other secrets, but did it completely. So it should confirm our hypothesis.
hi NAME Our editors are taking some slight respite, we'll respond soon.
No problem NAME I was just adding some more information I forgot to mention yesterday. Thanks for the heads up :+1:
It seems to me that the header is not correct. Thoughts?
For me the header looks fine: it is consistent with the final result. What looks wrong to you NAME
I'll assign this to NAME since I think that is his code.

I can confirm this, but it won't matter as -33 will have new values entirely. The mask value should be 56fb1381e7 for the second example.
NAME would you link this issue to the PR that will update the values for -33 so it gets closed then?
New values seem to work in my testing.
Change:
UDP-Lite, such as "msgChecksumLen", "fullChecksumSend", "recvChecksumLen", and "fullChecksumRecv". <del> 10.4. </del> <ins> 10.5. </ins> Connectedness: Connectionless

Discussion:
(More out of curiosity, with no expectation that this would find its way into the text unless you think I've hit a bug): In UDP Multicast Receive, which kind of ICMP notifications can come in there that would constitute a ConnectionError -- given that this transport does not send (and would thus usually not trigger any)?
Section 10.4 for multicast receive mentions ICMP errors. You could have errors on initiate for joining a multicast group, etc, but it likely doesn't make sense to have ICMP errors mentioned here.
Suggest we can close this issue.
LGTMSeems like we do not loose anything by removing this. The change WFM.
Change:
IANA is requested to create the following two entries in the existing registry for ExtensionType (defined in RFC8446): <del> encrypted_client_hello(57), with "TLS 1.3" column values being set to "CH, EE", and "Recommended" column being set to "Yes". </del> <ins> encrypted_client_hello(0xff02), with "TLS 1.3" column values being set to "CH, EE", and "Recommended" column being set to "Yes". </ins> <del> outer_extension(58), with the "TLS 1.3" column values being set to </del> <ins> ech_nonce(0xff03), with the "TLS 1.3" column values being set to </ins> "CH", and "Recommended" column being set to "Yes". <ins> outer_extension(0xff04), with the "TLS 1.3" column values being set to "CH", and "Recommended" column being set to "Yes". </ins> 11.2. IANA is requested to create an entry, ech_required(121) in the

Discussion:
We'll request early codepoints after we get some implementation experience.
Yeah, as I was specifying the extension codepoint I noticed the collision between this variable, so I figured changing it here was best.
I have no objection to echononce -> echononce_value but did you mean to do it in this PR?
Change:
extensions which are required to establish the cryptographic context.  Currently the only such extensions are "key_share" and "pre_shared_key".  All current TLS 1.3 ServerHello messages will <del> contain one of these two extensions. </del> <ins> contain one of these two extensions, or both when using a PSK with (EC)DHE key establishment. </ins> TLS 1.3 has a downgrade protection mechanism embedded in the server's random value.  TLS 1.3 servers which negotiate TLS 1.2 or below in

Discussion:
Reading through the spec again I found a few tiny things to fix. I'm suggesting to replace "Zero-RTT" with "0-RTT" in the paragraph because I found "Zero-RTT" used only in headlines, but "0-RTT" consistently in paragraphs.
NAME Please provide a PR to add yourself to acknowledgements.
Change:
Result (and possibly additional Claims) to a Relying Party, which then compares this information against its own appraisal policy. <del> There are three ways in which the process may fail.  First, the Verifier may not issue a positive Attestation Result due to the Evidence not passing the Appraisal Policy for Evidence.  The second way in which the process may fail is when the Attestation Result is examined by the Relying Party, and based upon the Appraisal Policy for Attestation Results, the result does not pass the policy.  The third way is when the Verifier is unreachable or unavailable. </del> <ins> Three ways in which the process may fail include: First, the Verifier may not issue a positive Attestation Result due to the Evidence not passing the Appraisal Policy for Evidence. The second way in which the process may fail is when the Attestation Result is examined by the Relying Party, and based upon the Appraisal Policy for Attestation Results, the result does not pass the policy. The third way is when the Verifier is unreachable or unavailable. </ins> Since the resource access protocol between the Attester and Relying Party includes an Attestation Result, in this model the details of

Discussion:
` Is there a reason to enumerate the failure cases? How can it be argued that there are only three? What if the device fails part way through? What if the relying party fails? What if the relying party is unreachable? What if something happens that wasn’t anticipated in the appraisal policy? Put another way, what are we learning about RATS from this example?
Change:
this server. The Alternative-Address elective option requests the peer to instead <del> open a connection of the same kind as the present connection to the </del> <ins> open a connection of the same scheme as the present connection to the </ins> alternative transport address given.  Its value is in the form "authority" as defined in Section 3.2 of RFC3986.

Discussion:
Also clarifies that "same kind" in Alternate-Address refers to scheme.
When I submitted the original pull request, I also posed a question on the but did not receive a response. One open question is whether we want to allow a client to immediately send messages after sending its CSM without waiting for the server CSM. This would be similar to HTTP/2: URL To avoid unnecessary latency, clients are permitted to send additional messages to the server immediately after sending the client connection preface, without waiting to receive the server connection preface. It is important to note, however, that the server connection preface SETTINGS frame might include parameters that necessarily alter how a client is expected to communicate with the server. Upon receiving the SETTINGS frame, the client is expected to honor any parameters established. In some configurations, it is possible for the server to transmit SETTINGS before the client sends additional frames, providing an opportunity to avoid this issue.
I support not blocking the device until the server CSM. The server can choose to not process messages that are invalid (e.g. too large) and immediately follow up with the server CSM. From the perspective of a cloud and gateway software provider, the CoAP (using TCP/TLS) server will usually be in the cloud or gateway and therefore usually not power constrained. I may be missing other scenarios where a battery powered device is acting as a CoAP/TCP server. Does anyone have plans for any of those scenarios?
NAME added a related comment to (which is closed) From your message I understand that in HTTP/2 the client can send messages immediately without waiting for the server to respond either. To me it feels like we should be doing what has been done in the HTTP/2 case even though there is a risk that some problems occur when the client sends data in way that the server will subsequently not handle well. If that is the case, the client will have to re-send the data, I guess. For the currently defined options I don't see problems.
Change:
However, it is often desirable to have the RS and AS communicate at runtime for a variety of purposes, including allowing the RS to validate and understand the rights and privileges associated with a <del> grant of access represented by an access token issued by (AS), or </del> <ins> grant of access represented by an access token issued by the AS, or </ins> negotiating the capabilities of either party.  These types of connections are particularly useful for connecting an AS and RS from different vendors, allowing interoperable distributed deployments of

Discussion:
Deploy preview for gnap-resource-servers-editors-draft ready! Built with commit 122ea374f78cfa417b0d1d80101e64990c448665 https://deploy-preview-11--gnap-resource-servers-editors-URL
Change:
Structure of this message: %%% Authentication Messages enum { rsa_sign(1), dss_sign_RESERVED(2), <del> rsa_fixed_dh(3), dss_fixed_dh_RESERVED(4), </del> <ins> rsa_fixed_dh_RESERVED(3), dss_fixed_dh_RESERVED(4), </ins> rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), <del> fortezza_dms_RESERVED(20), (255) } ClientCertificateType; </del> <ins> fortezza_dms_RESERVED(20), ecdsa_sign(64), (255) } ClientCertificateType; </ins> A list of the types of certificate types that the client may

Discussion:
Note: unRESERVEDing SHA-1 and DSA is intentional. The point is that that things which are RESERVED are totally forbidden. Because you can offer SHA-1, we need the code point. If we decide to make DSA MUSTNOT, then I'll mark it reserved and update the text.
On Saturday, October 03, 2015 04:42:44 pm ekr wrote: Agreed. Using the "RESERVED" notation before was a bit iffy and with this new refactoring it has to be changed now. Just need to make sure it's mentioned explicitly that it's restricted.