jiebi/CodeConvo huggingface dataset:
Change:
DISCLAIMER: This draft is work-in-progress and has not yet seen significant (or really any) security analysis.  It should not be used <del> as a basis for building production systems. </del> <ins> as a basis for building production systems.  This published version of the draft has been designated an "implementation draft" for testing and interop purposes. </ins> Although TLS 1.3 RFC8446 encrypts most of the handshake, including the server certificate, there are several ways in which an on-path

Discussion:
Seems useful to note that -13 should be around for a while but still might change later
Yeah that's fine. Ta, S.
How about this simplification based on the outcome from 111? I think it's clear that future changes may occur, so I just dropped that.
Change:
The CDDL fragment which represents the above text for COSE_Mac follows. <del> 6.1. </del> <ins> 6.2. In this section we describe the structure and methods to be used when doing MAC authentication for those cases where the recipient is implicitly known. The MAC message uses the COSE_Mac0 structure defined in this section for carrying the body. The MAC structure can be encoded either withor without a tag depending on the context it will be used in.  The MAC structure is identified by the CBOR tag TBD6.  The CDDL fragment that represents this is: The COSE_Mac0 structure is a CBOR array.  The fields of the array in order are: is described in header-parameters. is described in header-parameters. contains the serialized content to be MACed.  If the payload is not present in the message, the application is required to supply the payload separately.  The payload is wrapped in a bstr to ensure that it is transported without changes.  If the payload is transported separately, then a null CBOR object is placed in this location and it is the responsibility of the application to ensure that it will be transported without changes. contains the MAC value. The CDDL fragment which corresponds to the above text is: 6.3. </ins> In order to get a consistent encoding of the data to be authenticated, the MAC_structure is used to have a canonical form.

Discussion:
Everybody but me wants a MAC w/o recipients.
There also needs to be an equivalent no-recipient signature version. Thanks.
That string does not even parse.
Should the kid attribute be a binary value rather than a string value?
No arguments that binary should not be the only type for this, some questions that binary is useful based on Jose experience. Definite arguement that binary is required. Doing two types is probably a bad idea.
Change:
IANA is requested to add these new URI schemes to the registry established with RFC7595. <del> 8.3. </del> <ins> 6.2.1. This document requests the registration of the Uniform Resource Identifier (URI) scheme "coap+ws".  The registration request complies with RFC4395. coap+ws Permanent Defined in Section N of [RFCthis] The "coap+ws" URI scheme provides a way to identify resources that are potentially accessible over the Constrained Application Protocol (CoAP) using the WebSocket Protocol. The scheme encoding conforms to the encoding rules established for URIs in RFC3986, i.e., internationalized and reserved characters are expressed using UTF-8-based percent-encoding. The scheme is used by CoAP endpoints to access CoAP resources using the WebSocket protocol. None. See Section N of [RFCthis] IETF chair <chair@ietf.org> IESG <iesg@ietf.org> [RFCthis] 6.2.2. This document requests the registration of the Uniform Resource Identifier (URI) scheme "coap+wss".  The registration request complies with RFC4395. coap+wss Permanent Defined in Section N of [RFCthis] The "coap+ws" URI scheme provides a way to identify resources that are potentially accessible over the Constrained Application Protocol (CoAP) using the WebSocket Protocol secured with Transport Layer Security (TLS). The scheme encoding conforms to the encoding rules established for URIs in RFC3986, i.e., internationalized and reserved characters are expressed using UTF-8-based percent-encoding. The scheme is used by CoAP endpoints to access CoAP resources using the WebSocket protocol secured with TLS. None. See Section N of [RFCthis] IETF chair <chair@ietf.org> IESG <iesg@ietf.org> [RFCthis] 6.3. IANA is requested to register the 'coap' well-known URI in the "Well- Known URIs" registry.  This registration request complies with RFC5785: coap IETF [RFCthis] None. 6.4. </ins> IANA is requested to assign the following value in the registry "Application Layer Protocol Negotiation (ALPN) Protocol IDs" created

Discussion:
This is an extremely rough merge of core-coap-tcp-tls and core-coap-websockets. The main intent was to get all the material into one draft with a potential outline and next perform an overall editorial pass.
With the merge of websockets-07, the scope of coap-tcp-tls is extended to include CoAP over WebSockets. The draft title should reflect that change in scope.
I probably would stay explicit (but then I'm biased -- RFC 3095 :-) CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets
WFM.
Neglected to close with
Change:
Initial contents: The fields and descriptions defined in order- objects. <ins> [[ RFC EDITOR: Please replace XXXX above with the RFC number assigned to this document ]] </ins> 9.7.3. This registry lists field names that are defined for use in ACME

Discussion:
Also, add some more "replace RFC XXXX with this document" notes, for clarity. Thanks to NAME for noticing that this was missing.
Merging based on r+ from NAME
The new registry looks good :+1: - no changes to request there. The existing directory registry () should probably have a "meta" entry:
Change:
8. <ins> The document updates the "TLS SignatureScheme" registry to change the recommended status of SHA-1 based signature schemes to N (not recommended) as defined by RFC8447.  The following entries are to be updated: Other entries of the resgistry remain the same. 9. </ins> Concerns with TLS 1.2 implementations falling back to SHA-1 is an issue.  This draft updates the TLS 1.2 specification to deprecate support for MD5 and SHA-1 for digital signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection. <del> 9. </del> <ins> 10. </ins> The authors would like to thank Hubert Kario for his help in writing the initial draft.  We are also grateful to Daniel Migault, Martin

Discussion:
SHA-1 entries in the signature scheme registry should not be recommended this pull request creates an IANA considerations section to remove the recommended status.
Partially addresses .
Please address the following IDNits: -- The document seems to lack an IANA Considerations section. (See Section 2.2 of URL for how to handle the case when there are no actions for IANA.) -- The draft header indicates that this document updates RFC5246, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC7525, but the abstract doesn't seem to mention this, which it should. Section 1. Editorial. -- s/RFC 5246 [RFC5246]/[RFC5246]/ -- s/RFC 6151 [RFC6151]/[RFC6151]/ -- s/RFC7525 [RFC7525]/[RFC7525]/ Section 1. Editorial. For symmetry with the rest of the text: OLD RFC 6151 [RFC6151] details the security considerations, including collision attacks for MD5, published in 2011. NEW In 2011, [RFC6151] detailed the security considerations, including collision attacks for MD5. Section 1. Please provide a reference for "Wang, et al". Is there a reference to provide for the "the potential for brute-force attack" Section 6. Editorial Nit. s/RFC5246 [RFC5246]/[RFC5246]/ Section 6. Move the text "In Section 7.4.1.4.1: the text should be revised from" out of the "OLD" block of text to be its own intro paragraph so that the OLD vs. NEW is a clear cut-and-paste. Section 7. Editorial. s/ RFC7525 [RFC7525]/[RFC7525]/ Section 7. SHA-1 is also not mentioned in RFC7525. Recommend: OLD The prior text did not explicitly include MD5 and this text adds it to ensure it is understood as having been deprecated. NEW The prior text did not explicitly include MD5 or SHA-1; and this text adds guidance to ensure that these algorithms have been deprecated. Section 7.

Editorial. Grammar. OLD In addition, the use of the SHA-256 hash algorithm is RECOMMENDED, SHA-1 or MD5 MUST NOT be used NEW In addition, the use of the SHA-256 hash algorithm is RECOMMENDED; and SHA-1 or MD5 MUST NOT be used Section 10.2 Please make RFC5246 a normative reference.
This looks good to merge!
Change:
Static vectors (see static-vectors): <del> "Extension.extension_data" for any extension in "expected_extensions" whose value is self-delimiting (e.g., fixed length).  This applies only to the corresponding message. </del> <ins> "Extension.extension_data" for any extension whose type is in "self_delimiting_extensions", or is listed in Section 4.2 of RFC8446 except "padding".  This applies only to the corresponding message. </ins> The "extensions" field of the corresponding message, if "allow_additional" is false.

Discussion:
In the case a cTLS handshake uses a self-delimiting extension (in additional extensions) that is not present in section 4.2 of RFC 8446, its length is always serialized. With this PR, the type of this extension can be stored in and its length can be omitted.
Change:
and their nodes in graph theory, and the definition in RFC1034 has the same practical result as the definition here.  Using graph theory, a domain name is a list of labels identifying a portion <del> along one edge of an acyclic directed graph.  A domain name can be </del> <ins> along one edge of a directed acyclic graph.  A domain name can be </ins> relative to other parts of the tree, or it can be fully qualified <del> (in which case, it ends at the common root of the graph). </del> <ins> (in which case, it begins at the common root of the graph). </ins> Also note that different IETF and non-IETF documents have used the term "domain name" in many different ways.  It is common for

Discussion:
Split into two pairs of commits (each first changing content and then line lengths) for easy partial acceptance, should that be desired: Improve grammar and diction Be consistent about ordering domain name labels from the root The second pair attempts to provide a consistent treatment of "domain name" as an abstract sequence of labels in directed graph order starting at the root, while maintaining clarity about wire, presentation, and common display formats rendering domain names in reverse.
Change:
different message bodies to the same resource having the same block number.  This remains true even when CoAP is used together with a security protocol such as DTLS or OSCORE, within the replay window <del> (I-D.mattsson-core-coap-actuators), which is a vulnerability of CoAP </del> <ins> (I-D.mattsson-core-coap-attacks), which is a vulnerability of CoAP </ins> when using RFC7959. A straightforward mitigation of mixing up blocks from different

Discussion:
We've mentioned outdated draft names at times. Details in individual commits, point-to-point updated in-PR too. The DTLS change is not so much an update but a not to the editor that they may update the reference at their discretion when the publication sequence is clear; I don't want to pull another normative dependency into our cluster because we don't normatively need anything from 1.3.
Change:
Binding Requests for continuing consent freshness.  ICE already requires that implementations respond to such requests, so this approach is maximally compatible.  A separate document will profile <del> the ICE timers to be used; see I-D.muthu-behave-consent-freshness. </del> <ins> the ICE timers to be used; see RFC7675. </ins> 5.4.

Discussion:
Addresses .
NAME CI fail
Yeah I can’t wait to diagnose what xml problem I introduced - sigh.
From Cullen's 20171106 review: The refs to draft-muthu-behave-consent-freshness should be to RFC7675
Addressed by .
Change:
For brevity, "Connection ID" will often be abbreviated as "CID". <ins> 1.2. All wire formats will be depicted using the notation defined in Section 1.3 of QUIC-TRANSPORT.  There is one addition: the function len() refers to the length of a field which can serve as a limit on a different field, so that the lengths of two fields can be concisely defined as limited to a sum, for example: x(A..B) y(C..B-len(x)) indicates that x can be of any length between A and B, and y can be of any length between C and B provided that (len(x) + len(y)) does not exceed B. The example below illustrates the basic framework: </ins> 2. 2.1.

Discussion:
There are so many variable length fields that the ASCII art doesn't serve much of a purpose. Just switch to the notation used in quic-transport for the various CID and token formats.
Change:
DTLS implementations do not use the TLS 1.3 "compatibility mode" described in Section D.4 of TLS13.  DTLS servers MUST NOT echo the "session_id" value from the client and endpoints MUST NOT send <del> ChangeCipherSpec messages.  Note however that implementations MUST ignore ChangeCipherSpec messages received in unprotected records. </del> <ins> ChangeCipherSpec messages. </ins> With these exceptions, the DTLS message formats, flows, and logic are the same as those of TLS 1.3.

Discussion:
NAME NAME
Well, clients can recover by tearing down the connection and starting over.
Sure, sure. I think this was in the context of a "single" connection. Perhaps it's not that important to clarify?
I'll add text.
I think the only comment that's left to be addressed is this: Perhaps what's missing is precisely that clarifying statement. Namely, that clients which find themselves in such a situation cannot recover.
Change:
Finally, in addition to these weaknesses, sharing a PSK across nodes may negatively affect deployments.  For example, revocation of <del> individual group members is not possible without changing the authentication key for all members. </del> <ins> individual group members is not possible without changing establishing a new PSK for all of the non-revoked members. </ins> 4.2.

Discussion:
Resolve comments from Ben Smyth.
NAME can you please cut a new version of the draft?
Done. Revision -02 has been submitted.
I am getting a permission error when I try to set the tag for "draft-ietf-tls-external-psk-guidance-02". Everything else is done, and I have used my local file to submit the Internet-Draft. Please set the tag when you have a minute.
Change:
HTTP/2 stream is considered to be that of the WebTransport protocol and follows the semantics defined by that protocol. <del> 3.5. </del> <ins> 3.7. </ins> An example of negotiating a WebTransport Stream on an HTTP/2 connection follows.  This example is intended to closely follow the

Discussion:
Landing this now and applying subsequent comments directly to speed things up
Will file issues for the ones indicated, otherwise I made the suggested edits. Thanks for reviewing this, NAME
Change:
5. <del> This document defines one ".well-known" URIs using the registration procedure and template from Section 5.1 of RFC5785. 5.1. URI suffix: captive-portal.json Change controller: IETF Specification document(s): This RFC Related information: None </del> <ins> TBD: None </ins> 6.

Discussion:
Removed language for /.well-known URI. Made serving over port 443 a SHOULD requirement. Other editorial changes
Added your updated language, should be good to go.
I don't think that we need this. 7710 gives us an entire URI, as can PvD.
I agree that we can use the URI from the DHCP option or from PvD. The reason I went this route was to avoid the scheme that was in the API draft to start with, which seemed to be: If you access the 7710 URI with a GET, you'll receive the HTTP for the user interactive portal If you access the 7710 URI with a POST, you'll get the JSON API That seemed problematic (a) because it implies the user portal and API are co-located and (b) it seemed overly complex. Do you have a preference for what methods are valid to access the JSON API, and whether we should specify that the URI needs to be JSON? My concern was that if the DHCP option or whatever pointed to something that was clearly .html, something's wrong, and using a well-known JSON URI to compare against would be a way to detect that.
NAME Thoughts on the method for fetching the JSON API, or if that's a non-issue?
Let's take this to the list.
PR fixes the well-known URI language. For now there is indication of Accept and Conent-Type header usage but we haven't explicitly called it out until we get a final decision. We can close this issue though.
Change:
above keying material. By using the TLS exporter, EAP-TLS can use any TLS 1.3 implementation <del> without having to extract the Main Secret, ClientHello.random, and ServerHello.random in a non-standard way. </del> <ins> which provides a public API for the exporter.  Note that EAP-TLS with TLS 1.2 RFC5216 can be used with the TLS exporter since the public exporter was defined in RFC5705. </ins> 2.4.

Discussion:
The PR only fixed some of Alan's comments. I updated the PR to address all Alan's comments that was copied in the issue
From Alan's review: >
Also >
Looks good to merge
Change:
Each SFrame session uses a single ciphersuite that specifies the following primitives: <del> o A hash function used for key derivation </del> <ins> A hash function used for key derivation </ins> <del> o An AEAD encryption algorithm RFC5116 used for frame encryption, optionally with a truncated authentication tag </del> <ins> An AEAD encryption algorithm RFC5116 used for frame encryption, optionally with a truncated authentication tag </ins> This document defines the following ciphersuites:

Discussion:
This PR addresses a few outstanding formatting cleanup issues: Fixes the list formatting problems identified in ... as well as a few others Wraps paragraphs to 80 columns
Merging on my own since these are just formatting changes.
This : ... is probably not a single paragraph. Similar problems and . It might be worth a more thorough proof-read of the document for others similar formatting problems.
Change:
connection ID to be routed back to the endpoint and to be identified by the endpoint upon receipt. <ins> Multiple connection IDs are used so that endpoints can send packets that cannot be identified by an observer as being for the same connection without cooperation from an endpoint; see migration- linkability. </ins> Connection IDs MUST NOT contain any information that can be used by an external observer (that is, one that does not cooperate with the issuer) to correlate them with other connection IDs for the same

Discussion:
Éric Vyncke said:
We say it, but it comes a lot later. Too late, I think.
Change:
At all levels of the network hierarchy, the filtration mechanisms used to detect undesirable traffic are essentially the same: a censor sniffs transmitting packets and identifies undesirable content, and <del> then uses a blocking or shaping mechanism to prevent or degrade </del> <ins> then uses a blocking or shaping mechanism to prevent or impair </ins> access.  Identification of undesirable traffic can occur at the application, transport, or network layer of the IP stack.  Censors are almost always concerned with web traffic, so the relevant

Discussion:
…nce. defines censorship. fixes definition of identification in intro.
First, one thing that isn’t clear immediately from the introduction is who/what is a “censor”. I find it a little strange, actually, to suggest that a censor performs "aggregation". Is the censor an ISP? A government? Something else? For example, a government may have loose policies about what kind of content to censor (e.g., "hate speech"). An ISP might in turn implement these loose policies in different ways. Policies can also differ across a country, etc. The other terms---identification and prevention---are similarly confusing, although I think the term "identification" isn't as problematic as its (incorrect?) definition in the introduction. "Identification is the process by which censors determine whether content is blocked" - NO. I think it is the process by which a censor might classify traffic to determine whether to block a traffic flow or now. I would suggest something like: prescription, identification, and interference.
Wondering what you think about "design, identification, and interference"? I think for the purposes of todays 20:00 ET IETF drafts deadline, I'll change the terminology throughout to match prescription, identification, and interference and I'll correct the other things mentioned here (define censor, fix definition of identification in intro).
That seems a bit more clear, indeed! Ah, I didn't realize there was a deadline of today 2000h. Not sure I can get you a pull request by then, but will try.
I'll leave this open. You by no means need to get a pull request by 20:00! I just want to do my best to make changes responsive to your feedback. I'll leave this open and you can see what I've done (I'll be working on trying to clear out issues until then), and feel free to submit changes as you think are needed.
Change:
Search criteria for limiting the number of results (optional). <ins> The search criteria are an associative array, expressed in a form-style query as per the URI template (see RFC6570 Sections 2.4.2 and 3.2.8) </ins> Page (optional).  Parameter cannot be used without the count parameter.  Results are returned from result set in pages that contain 'count' links starting from index (page * count).  Page

Discussion:
It appears I've missed some of Alexey's remarks responding to the changes made after his initial review (, 2019-11-20). This contains fixes for the points he still wanted changed / suggested after my original response to his review.
Change:
remains acknowledged, even if it does not appear in a future ACK frame.  This is unlike TCP SACKs (RFC2018). <del> It is expected that a sender will reuse the same packet number across different packet number spaces.  ACK frames only acknowledge the packet numbers that were transmitted by the sender in the same packet number space of the packet that the ACK was received in. </del> <ins> Packets from different packet number spaces can be identified using the same numeric value.  An acknowledgment for a packet needs to indicate both a packet number and a packet number space.  This is accomplished by having each ACK frame only acknowledge packet numbers in the same space as the packet in which the ACK frame is contained. </ins> Version Negotiation and Retry packets cannot be acknowledged because they do not contain a packet number.  Rather than relying on ACK

Discussion:
by taking NAME suggestion and adding a sentence about how the same PN may be used in each space.
NAME -- PTAL at .
Thanks for the suggestion NAME , accepted.
I have an editorial disagreement here, but as with all such disagreements, I'm happy to go with whatever more people think reads better. I find this use of "numeric value" to be unnecessary. Making it implicit (which is what this sentence is doing) doesn't really change the way a reader consumes this sentence. As a reader, I will replace "numeric value" with "packet number"; there isn't a different definition for packet number that is anything more than the numeric value. At a minimum, I would swap the order of the two sentences.
The contains the following paragraph: I see a few problems with the first sentence: As written, it does not make sense. There is no mention of packet number reuse expectations across packet number spaces in . The connection between it and the sentence that follows is not clear. I propose that the first sentence simply be dropped.
The second sentence can stand some improvement as well: There is no need for the word "only." It is not necessary to say that the ACK frame was received. Packets, not packet numbers, are acknowledged. How about something like this:
Looks good.