jiebi/CodeConvo huggingface dataset:
Code change:
6. <del> RFC5246, The Transport Layer Security (TLS) Protocol Version 1.2, suggests that implementations can assume support for MD5 and SHA-1 by their peer.  This update changes the suggestion to assume support for SHA-256 instead, due to MD5 and SHA-1 being deprecated. In Section 7.4.1.4.1: the text should be revised from: OLD: "Note: this is a change from TLS 1.1 where there are no explicit rules, but as a practical matter one can assume that the peer supports MD5 and SHA- 1." NEW: "Note: This is a change from TLS 1.1 where there are no explicit rules, but as a practical matter one can assume that the peer supports SHA-256." 7. </del> 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

Related discussion:
text: cc NAME NAME NAME
I believe this I-D should still include the "update: 5246 (if approved)" header, even though we took out the 5246 OLD/NEW section. We are still proposing that 5246 be changed to require signature_algorithms extension be sent and that MD5/SHA1 never be sent. In other words, I think you can merge this PR assuming there are no conflicts.
Verifying that this is okay on list, but Daniel suggested the following change for s6: Add the following immediately bfore the OLD/NEW, i.e., right after "due to MD5 and SHA-1 being deprecated.": In Section 7.1.4.1: the following text is removed: If the client supports only the default hash and signature algorithms (listed in this section), it MAY omit the signature_algorithms extension.
Resulted in a number of changes - see .
I think you also need to update the abstract and introduction sections, as they both mention "This document updates ..." (same as URL). Will probably conflict with URL so we should merge that first.I believe this can be merged as is. I.e., don't remove the "udpates" header, change the abstract, or intro.
Code change:
will still be HKDF-Extract(0, 0).  For the computation of the binder_key, the label is "ext binder" for external PSKs (those provisioned outside of TLS) and "res binder" for resumption PSKs <del> (those provisioned as the resumption main secret of a previous handshake).  The different labels prevent the substitution of one type of PSK for the other. </del> <ins> (those provisioned as the resumption secret of a previous handshake). The different labels prevent the substitution of one type of PSK for the other. </ins> There are multiple potential Early Secret values, depending on which PSK the server ultimately selects.  The client will need to compute

Related discussion:
text: While we're renaming these anyway, exportersecret and resumptionsecret are just as descriptive.
exportermainsecret and resumptionmainsecret strike me as not needing an adjective in the middle at all. Perhaps exportersecret and resumptionsecret? For the exporter secret, dropping "main" avoids the acronym collision with the EMS extension, and there are no other secrets associated with exporters, so there's no use in designating this as the main one. For the resumption secret, there is a potential confusion between resumption[main]secret and the derived PSK associated with the ticket (section {#NSTMessage}), but we don't seem to give the latter a name in the first place so I think that's fine. This also gives us nice short KDF labels when we're able to change those: "exporter" and "resumption". (Or perhaps even "export" and "resume" if those don't fit in a hash block.)
Code change:
the connection, the session is terminated. Trade-offs: RST Packet Injection has a few advantages that make it <del> extremely popular is a censorship technique.  RST Packet Injection is </del> <ins> extremely popular as a censorship technique.  RST Packet Injection is </ins> an out-of-band prevention mechanism, allowing the avoidance of the the QoS bottleneck one can encounter with inline techniques such as Packet Dropping.  This out-of-band property allows a censor to

Related discussion:
text: I think there is a trivial typo in the first sentence of "Trade-offs".
thanks!
Code change:
To properly indicate use of DTLS, the <proto> field MUST be set to "UDP/TLS/RTP/SAVPF", as specified in RFC5764, Section 8, if the <del> default candidate uses UDP transport, or "TCP/TLS/RTP/SAVPF", as </del> <ins> default candidate uses UDP transport, or "TCP/DTLS/RTP/SAVPF", as </ins> specified inI-D.nandakumar-mmusic-proto-iana-registration if the default candidate uses TCP transport.

Related discussion:
text: URL of draft-nandakumar. This is a merge of a previously approved PR
lgtm
LGTM
As per discussion in mmusic, to make it abundantly clear that DTLS is to be used even when running over ICE-TCP, the profile name should be TCP/DTLS/RTP/SAVPF. We'll leave the UDP/TLS/RTP/SAVPF one alone, since that ship has sailed, and it's less ambiguous.
Need Suhas to update URL to reflect the above.
For SCTP, URL has the correct UDP/DTLS/SCTP and TCP/DTLS/SCTP things that we want to refer to.
The action item here is to update this document to use the correct fields as agreed above as if draft-nandakumar was done, and then when that document is fixed we will be good.
Code change:
6. <del> Security considerations are enumerated in I-D.ietf-rtcweb-security. </del> <ins> RTCWEB security considerations are enumerated in I-D.ietf-rtcweb- security. Security considerations pertaining to the use of DSCP are enumerated in I-D.ietf-tsvwg-rtcweb-qos. </ins>

Related discussion:
text: reformulated the TCP point, addressed security with a reference to -qos.
From Ben Campbell's review:
Second point is fixed by . I'm not sure the third point is an improvement.
SSL is used exactly once, as part of the acronym "TURN/SSL". This is also the first mention of TURN, but the second was much more convenient to attach the expansion to. Given that it was so awkward to attach them, I included a new section listing the "used protocols" instead.
From Magnus Westerlund in IETF LC: Section 8.1: [I-D.martinsen-mmusic-ice-dualstack-fairness] Martinsen, P., Reddy, T., and P. Patil, "ICE IPv4/IPv6 Dual Stack Fairness", draft-martinsen-mmusic-ice- dualstack-fairness-02 (work in progress), February 2015. Can be updated as this is now an WG item in ICE.
Updated in
Fixed by
I have reviewed this document in preparation for IETF last call. It is in good shape and I have requested the last call. While the last call is ongoing, I would like to double-check that this document (particularly Section 4) raises no new security considerations that should be documented in Section 6. I'm wondering if there are scenarios where a malicious application could try to game the priority scheme to some ill effect? draft-ietf-tsvwg-rtcweb-qos talks a bit about this, so I'm wondering if anything needs to be said here. And I found a couple of nits to be resolved together with any LC comments: Sec 3.2 - Please update the citation to point to draft-ietf-mmusic-ice-dualstack-fairness-02. Sec 3.4 - "Third, using TCP only between the endpoint and its relay may result in less issues with TCP in regards to real-time constraints, e.g. due to head of line blocking." This is awkwardly phrased. I would suggest something like "Third, using TCP between the client's TURN server and its peer may result in more performance problems (due to head-of-line blocking) than using UDP."
Code change:
6. <del> Security considerations are enumerated in I-D.ietf-rtcweb-security. </del> <ins> RTCWEB security considerations are enumerated in I-D.ietf-rtcweb- security. Security considerations pertaining to the use of DSCP are enumerated in I-D.ietf-tsvwg-rtcweb-qos. </ins>

Related discussion:
text: And one bit I left out — if text is to be added to reference draft-ietf-rtcweb-return, that should be done together with addressing nits and LC comments.
There seems no consensus to add RETURN, so I'm skipping this for now.
Code change:
ChaCha20 function as defined in Section 2.4 of CHACHA.  This uses a 256-bit key and 16 bytes sampled from the packet protection output. <del> The first 4 bytes of the sampled ciphertext are interpreted as a 32-bit number in little-endian order and are used as the block count. The remaining 12 bytes are interpreted as three concatenated 32-bit numbers in little-endian order and used as the nonce. </del> <ins> The first 4 bytes of the sampled ciphertext are the block counter.  A ChaCha20 implementation could take a 32-bit integer in place of a byte sequence, in which case the byte sequence is interpreted as a little-endian value. The remaining 12 bytes are used as the nonce.  A ChaCha20 implementation might take an array of three 32-bit integers in place of a byte sequence, in which case the nonce bytes are interpreted as a sequence of 32-bit little-endian integers. </ins> The encryption mask is produced by invoking ChaCha20 to protect 5 zero bytes.  In pseudocode:

Related discussion:
text: The nonce can just be opaque bytes. The block counter is tricky, as noted in the issue. The "obvious" choice is little-endian, as that is consistent with the philosophy of the designer (as I understand it), but that is not anything more than a guess. Absent strong evidence that big-endian is a better choice, I'm going to err on the side of not making a substantive change here. But I think that we need a consensus call to support that viewpoint.
Here's what 5.4.4 says However, RFC 8439 says: This is a little confusing, but I think the correct way to read this is that the ChaCha function takes the nonce as a 96-bit opaque quantity, and the fact that it's little-endian is an internal detail irrelevant to our purposes, so we should just replace the second sentence with "The remaining 12 bytes are used as the 96-bit ChaCha nonce". This is reinforced by the fact that the test vectors have the nonce as a byte block. The situation with the counter is more complicated because we are told it is both a counter and 32-bits (which might make you think it's an integer parameter), but it is also treated as a little-endian integer, which makes one think it's a bitstring. And then the test vectors treat it as a value, rather than as a bitstring. If you look at code it typically thinks of this as an integer: See, for instance: URL So, I think the right answer here is to think of ChaCha as having the following API: Note that because the value on the wire is in big-endian format, this would invert the nonce, but I think it's the right answer anyway. Otherwise, you're having to pass in the counter in the wrong format on big-endian platforms.
As a completely general note, I don't think it is right to change endianness of crypto wire formats. AES-GCM has a completely backwards neither little nor big endian encoding (byte and bit swapped so no platform wins) this remains so on the wire. Especially for HW processing this is significant. But little endian is also more performant on nearly all relevant platforms today so there is no need to go over board forcing big endian if it can be avoided without insulting RFC's.
Yeah, this should simplify that text some.
Code change:
ChaCha20 function as defined in Section 2.4 of CHACHA.  This uses a 256-bit key and 16 bytes sampled from the packet protection output. <del> The first 4 bytes of the sampled ciphertext are interpreted as a 32-bit number in little-endian order and are used as the block count. The remaining 12 bytes are interpreted as three concatenated 32-bit numbers in little-endian order and used as the nonce. </del> <ins> The first 4 bytes of the sampled ciphertext are the block counter.  A ChaCha20 implementation could take a 32-bit integer in place of a byte sequence, in which case the byte sequence is interpreted as a little-endian value. The remaining 12 bytes are used as the nonce.  A ChaCha20 implementation might take an array of three 32-bit integers in place of a byte sequence, in which case the nonce bytes are interpreted as a sequence of 32-bit little-endian integers. </ins> The encryption mask is produced by invoking ChaCha20 to protect 5 zero bytes.  In pseudocode:

Related discussion:
text: I like the proposed change, the text had somewhat confused me when implementing this in a previous life.
I don't think that the reinterpretation of the little-endian thing is safe, as per NAME comment. The takes a byte buffer as input rather than a . That is to allow for different block counter sizes. I'll make the editorial change, but leave the suggestion there alone.
I have a question out to the editor of the PKCS spec. It appears like there are no solid rules in the spec to support any particular position here. I'm going with my best guess at WWDJBD here, but I'm happy to make a change if there is a strong case made for something else.
NAME NAME can we flip this to please? I don't think that we need to change the substance here, but I want to confirm the little-endian/big-endian choice here. I hope to have more information to share on the question soon, but that might not be definitive. We might just have to make a call ourselves. Absent better information, I'm going to suggest that we continue with little-endian, but I this is far from an obvious conclusion.
The API I'm using for ChaCha20 takes a const uint8_t nonce[12], and I currently pass in a pointer (offset by 4 bytes) to the sample as the nonce, without doing any endianness conversions. I'm in favor of clarifying the language for this input. (Given that this has the design label instead of the editorial label, my design opinion is to keep with the simple thing of passing the bytes directly from the sample to the nonce input of ChaCha20 and not do any endianness conversions. I'm assuming that other crypto libraries have similar APIs though.)
The API I have takes . PKCS takes pointers just like the API NAME refers to (but it fails to specify the endianness, which is a critical oversight, compounded by the fact that the size of the counter can vary). I suspect that - as NAME says - the right idea is to note that ChaCha20 will interpret the nonce as three little-endian integers and that the counter might be expressed as a byte sequence that is then (probably) interpreted as a little-endian integer.
Code change:
ChaCha20 function as defined in Section 2.4 of CHACHA.  This uses a 256-bit key and 16 bytes sampled from the packet protection output. <del> The first 4 bytes of the sampled ciphertext are interpreted as a 32-bit number in little-endian order and are used as the block count. The remaining 12 bytes are interpreted as three concatenated 32-bit numbers in little-endian order and used as the nonce. </del> <ins> The first 4 bytes of the sampled ciphertext are the block counter.  A ChaCha20 implementation could take a 32-bit integer in place of a byte sequence, in which case the byte sequence is interpreted as a little-endian value. The remaining 12 bytes are used as the nonce.  A ChaCha20 implementation might take an array of three 32-bit integers in place of a byte sequence, in which case the nonce bytes are interpreted as a sequence of 32-bit little-endian integers. </ins> The encryption mask is produced by invoking ChaCha20 to protect 5 zero bytes.  In pseudocode:

Related discussion:
text: I understand and appreciate this being marked as “design”, though I consider the text that landed in master as editorial, as it (in my view) ended as adding practical advice while retaining the definition we have had.
Yes, but as a design issue, we want to confirm that "no action" is the correct outcome. It's cheap enough to do so.
I like the updated text. It reads good as it gives the practical advice first, then amends that with the formal definition.
Code change:
The number of bits in the IP Address that are used to define the prefix that is being assigned.  This MUST be less than or equal to the length of the IP Address field, in bits.  If the prefix length <del> is equal to the length of the IP Address, the endpoint is only allowed to send packets from a single source address.  If the prefix length is less than the length of the IP address, the endpoint is allowed to send packets from any source address that falls within the prefix. </del> <ins> is equal to the length of the IP Address, the receiver of this capsule is only allowed to send packets from a single source address.  If the prefix length is less than the length of the IP address, the receiver of this capsule is allowed to send packets from any source address that falls within the prefix. </ins> If an endpoint receives multiple ADDRESS_ASSIGN capsules, all of the assigned addresses or prefixes can be used.  For example, multiple

Related discussion:
text: This change adds text that addresses conveyed by ADDRESSASSIGN can be used in the "source address" field of an IP packet, while addresses conveyed by ROUTEADVERTISEMENT can be used in the "destination address" field. While we're here, also add a small clarification when a prefix is assigned/advertised that any of these addresses can be used in the source/destination field, respectively. A future extension could create semantics for these addreses, but that is not called out in the text at this time.
I'm know I'm late looking at this but thanks as this small clarification is really helpful
The current text in this draft needs to be updated to match the changes from URL I'll write up a PR once existing conflicting PRs are merged.
NAME is this unblocked now?
We need to clearly state that ADDRESSASSIGN defines a set of addresses the receiver of the capsule can use as a source IP address on packets it generates We need to clearly state that ROUTEADVERTISEMENT defines a set of addresses the receiver of the capsule can use as a destination IP address on packets it generates Should we rename the capsules to make this relationship more clear in all use cases?
Let's bike shed the name here NAME NAME NAME
(to clarify Tommy's comment - if anyone comes up with a new name they like, they should post it here. If not, we'll go with advertisement and withdraw)
Thanks!
Code change:
responds with an error status code and a problem document describing the error. <del> 6.3.3. </del> <ins> 6.3.4. </ins> A client may deactivate an account by posting a signed update to the server with a status field of "deactivated."  Clients may wish to do

Related discussion:
text: This is a variant of that uses a MAC key to perform the account binding instead of a bearer token. Thanks to NAME for pointing out the need for this on the ACME mailing list.
Question: will you require a CA that doesn't use external account bindings to reject a request if it contains an external-account-binding member? nit: s/field/member/g, consistent with RFC 7159.
StartCom plan to use ACME protocol for StartEncrypt, we need to identify the client's validation level, so the subscriber administration can generate a special token in the URL account that send this token to the email address used in the registration. At the registration, user need to enter email and this token with the certificate to let the CA system know this customer's validation level. After the CA system receive the email, the token and signing certificate, CA system know what type of certificate we can issue to this client; if this client account is class 4 validated, then the client can get EV SSL certificate, not DV SSL. please add this a parameter to the ACME protocol, thanks.
This request should be sent to the ACME mailing list (EMAIL) for further discussion, it would also be very useful to know what your EV (or OV) validation flow would look like using ACME as most likely the current certificate application object would need to be changed to identify those requirements to the server.
This was fixed by
Minor editorial comments.
Code change:
Preference <del> Prefer </del> <ins> Ignore </ins> This property specifies whether the application needs or prefers to use a transport protocol that preserves message boundaries.

Related discussion:
text: I am sure this has been discussed, but reading now it seems strange to me to use "Prefer" as the default for a Selection Property that affects how the application interacts with the API. Using "Prefer" means that I do not know what service I will get when using the default settings? In this case I do not know if I get messages or not if I use the defaults.
This should be Ignore as a default.
Code change:
Preconnection, Connection (read only) <del> This property specifies whether the application wishes to use a </del> <ins> This property specifies whether the application needs to use a </ins> transport protocol that ensures that all data is received on the other side without corruption.  This also entails being notified when a Connection is closed or aborted.  The default is to enable Reliable

Related discussion:
text: I didn't like something about reliability (let's not throw an error when we can't be UNreliable, only when we can't be reliable). I updated the text on ordering a bit, to say that the Property is ignored for the first Message on a Connection, and rephrased it slightly to talk about the receiver-side transport system and the receiving application - before, the text might have talked about a sender-side behavior. I added a TODO DISCUSS comment about per-message Niceness.
Fine with me, maybe fix minor knitThanks, all good now I think.
Code change:
"supported_signature_algorithms" value: %%% Signature Algorithm Extension enum { // RSASSA-PKCS-v1_5 <del> algorithms.  rsa_pkcs1_sha1 (0x0201), rsa_pkcs1_sha256 (0x0401), </del> <ins> algorithms rsa_pkcs1_sha1 (0x0201), rsa_pkcs1_sha256 (0x0401), </ins> rsa_pkcs1_sha384 (0x0501), rsa_pkcs1_sha512 (0x0601), Note: This production is named "SignatureScheme" because there is

Related discussion:
text: Minor editorial tweaks. I just noticed the extra line that gets left in there when shown up top (two lines between first two shown blocks, instead of one). This fixes that. Also drops the periods after the comments, as they're not sentences.
Code change:
monitor for new push messages. Requesting the delivery of events is particularly important for the <del> Web Push API.  The subscription, management and monitoring functions </del> <ins> W3C Push API.  The subscription, management and monitoring functions </ins> are currently fulfilled by proprietary protocols; these are adequate, but do not offer any of the advantages that standardization affords.

Related discussion:
text: Pretty good. I think that we should at least try to put some MUST-strength language in regarding confidentiality, etc... That makes writing the rest of the security considerations that much easier (you don't have to worry that someone might have ignored your advice and account for it).
Looks good. Further refinements can be done later :)
There is an adequate explanation of the related W3C Push API in the Introduction. Additional references about specific API behavior in Section 9.3 and 9.4 can be removed.
Besides removing extraneous API references, informative references should be added for the separate drafts for optional content encoding and authentication.
Moving to -05. Waiting for a decision on the VAPID call for adoption.
Code change:
This specification does not cover the throttling scope, that may be the given resource-target, its parent path or the whole Origin <del> RFC6454 section 7. </del> <ins> (see Section 7 of RFC6454). </ins> The rate-limit headers may be returned in both Successful and non Successful responses.  This specification does not cover whether

Related discussion:
text: uses http-core semantics fixes Sections refs cc: NAME
I'll wait for the new i-d-template image, but will do.
Please use either [RFCxxxx], Section yyy or Section yyy of [RFCxxxx]
Addressed by now.
If you start using the new kramdown-rcf2629 section ref syntax, you may want to do that consistently...