jiebi/CodeConvo huggingface dataset:
Change:
A "HpkeKeyConfig" structure carrying the configuration information associated with the HPKE public key.  Note that this structure contains the "config_id" field, which applies to the entire <del> ECHConfigContents.  Sites MUST NOT publish two differet"ECHConfigContents" values with the same "HpkeKeyConfig" value. </del> <ins> ECHConfigContents.  Sites MUST NOT publish two different "ECHConfigContents" values with the same "HpkeKeyConfig" value. The RECOMMENDED technique for choosing "config_id" is to choose a random byte.  This process is repeated if this config_id matches that of any valid ECHConfig, which could include any ECHConfig that has been recently removed from active use. </ins> The longest name of a backend server, if known.  If this value is not known it can be set to zero, in which case clients SHOULD use

Discussion:
accidentally targeted an older branch that was since merged into master. This just takes the same change and redirects it to the main branch.
Change:
3.4.1. If the ClientHello is not encrypted, SNI can be derived from the <del> client's Initial packet by calculating the Initial secret to decrypt the packet payload and parsing the QUIC CRYPTO frame(s) containing the TLS ClientHello. </del> <ins> client's Initial packet(s) by calculating the Initial secret to decrypt the packet payload and parsing the QUIC CRYPTO frame(s) containing the TLS ClientHello. </ins> As both the derivation of the Initial secret and the structure of the Initial packet itself are version-specific, the first step is always

Discussion:
Follow-on to
Thanks NAME As there are clarifications/editorial, I think we will wait for the AD review and take this PR up with a next revision before or after IETF last call. But I think it's ready to merge!
You're welcome. Agreed they're editorial, so merge whenever it makes sense.
Change:
qualification is not required if the target of the assignment is well specified. <del> For enumerateds that are never converted to external representation, the numerical information may be omitted. </del> The names assigned to enumerateds do not need to be unique.  The numerical value can describe a range over which the same name applies.  The value includes the minimum and maximum inclusive values

Discussion:
We don't actually use this syntax, and having it in here just adds useless complexity. Defining syntax we don't actually use just risks confusing people reading the document for the first time.
Change:
The createOffer method takes as a parameter an RTCOfferOptions object.  Special processing is performed when generating a SDP <del> description if the following constraints are present. </del> <ins> description if the following options are present. </ins> 5.2.3.1.

Discussion:
Also fix a bunch of TODOs and a few places where text was obsolete. NAME NAME
I suspect we might need to say a bit more in this section this but this all looks good good so LGTM
Change:
IKEv2 <ins> OpenVPN </ins> Extensions (Application-Layer Protocol Negotiation): The application enables or configures extensions that are to be negotiated by the security protocol, such as ALPN RFC7301.

Discussion:
I'm pretty sure OpenVPN offers the following interfaces, because they are available as command line arguments in the openvpn tool: URL Identities and Private Keys: --cert option and --key Supported Algorithms (Key Exchange, Signatures, and Ciphersuites): --auth alg Pre-Shared Key Import: I think explicit import, as the application can specify the PSK explicitly: --secret key Pre-Shared Key Export: I think Explicit export, because the OpenVPN documentation mentions RFC 5705, RFC 5705 mentions DTLS-SRTP, and DTLS-SRTP is classified as explicit export: keying-material-exporter label len Connection Termination: OpenVPN allows connection restart based on signals SIGHUP and SIGUSR1
Change:
recovered is to exploit existing signaling that is understood by the congestion control mechanism.  An example would be to indicate to a TCP sender that a packet has been recovered (i.e., congestion has <del> occurred), by using ECN signaling. </del> <ins> occurred), by using ECN signaling TENTET. </ins> 6.4.

Discussion:
There are two possibilities either: "Point-to-point transmetting method based on the use of an erasure coding scheme and TCP/IP protocol", ISAE-SUPAERO (2019) EP 3 432 500 A1, WO 2019015931 (A1). URL "On the joint use of TCP and Network Coding", Emmanuel Lochin, IETF'100 NWCRG session, November 2017. URL
Since this is IPR protected content I gather the IPR declaration is up to date?
Yes Le mer. 28 oct. 2020 à 10:40, patibulon a écrit :
done in PR
Change:
Note that these criteria for deciding to use a never-indexed literal representation will evolve over time as new attacks are discovered. <del> 7.5. </del> <ins> 7.2. </ins> There is no currently known attack against a static Huffman encoding. A study has shown that using a static Huffman encoding table created

Discussion:
Magnus Nystrom : not be able (based on no current known attack against static Huffman encodings) to mount the previously described "probing" attack? If so, adding a sentence at the end of the section along the lines of "Thus, the previously mentioned probing attack is not known to be applicable for any fields where static Huffman encoding is used."
This section is not related to the probing attack. I think some of the confusion here is lost formatting when importing from RFC 7541. The TOC should be:
Change:
[[OPEN ISSUE: Should we remove this?  I am reluctant to create a situation where one needs to read 8446 to process this document.]] <ins> [[OPEN ISSUE: Add some text to rename the extended_master_secret entry in the extensions registry to extended_main_secret, after the above is resolved.]] </ins> This document uses several registries that were originally created in RFC4346 and updated in RFC8447.  IANA has updated these to reference this document.  The registries and their allocation policies are

Discussion:
I wasn't sure where to put this text. There was an Appendix talking about TLS 1.2, so I figured it could go nearby. And then it probably wanted to go before that Appendix so there isn't ambiguity about how to refer to EMS.
Implementations of TLS 1.2 will remain for some time. The document renames "master secret" to "main secret", but TLS 1.2 has some naming variations that aren't in TLS 1.3. Perhaps a section in the document somewhere (maybe under Backward Compatibility since that talks about older versions) that describes some additional deltas: "master secret" => "main secret", to align this this document "premaster secret" => "preliminary secret" ("pre-main secret" sounds weird to me) "extended master secret" => "extended main secret" (probably move rfc7627 from informative to normative and then also add to the updates line) Also cover the variations like "EncryptedPreMasterSecret" and "mastersecret", but not the KDF labels since those can't change. And then IANA considerations to rename extendedmastersecret to extendedmain_secret in the registries.
Change:
9.7.6. <ins> This registry lists field names that are defined for use in the JSON object included in the "meta" field of an ACME directory object. Template: Field name: The string to be used as a field name in the JSON object Field type: The type of value to be provided, e.g., string, boolean, array of string Reference: Where this field is defined Initial contents: The fields and descriptions defined in account- objects. [[ RFC EDITOR: Please replace XXXX above with the RFC number assigned to this document ]] 9.7.7. </ins> This registry lists the types of identifiers that can be present in ACME authorization objects.

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:
2. <del> Token redemption is performed using HTTP Authentication (RFC9110), with the scheme "PrivateToken".  Origins challenge clients to present a token from a specific issuer (challenge).  Once a client has received a token from that issuer, or already has a valid token available, it presents the token to the origin (redemption). </del> <ins> Token redemption is performed using HTTP Authentication (RFC9110, Section 11), with the scheme "PrivateToken".  Origins challenge clients to present a token from a specific issuer (challenge).  Once a client has received a token from that issuer, or already has a valid token available, it presents the token to the origin (redemption). </ins> 2.1.

Discussion:
Previously, the document linked to RFC 7235, whose whole purpose was to discuss HTTP Authentication. Now you kjust link to RFC 9110, which all of HTTP semantics. Suggest that you link to Section 11 of RFC 9110 to make the reader's life easier.
Change:
6.2. <del> A Probe Timeout (PTO) triggers sending one or two probe packets when ack-eliciting packets are not acknowledged within the expected period of time or the handshake has not been completed.  A PTO enables a connection to recover from loss of tail packets or acks.  The PTO algorithm used in QUIC implements the reliability functions of Tail Loss Probe TLP RACK, RTO RFC5681 and F-RTO algorithms for TCP RFC5682, and the timeout computation is based on TCP's retransmission timeout period RFC6298. </del> <ins> A Probe Timeout (PTO) triggers sending one or two probe datagrams when ack-eliciting packets are not acknowledged within the expected period of time or the handshake has not been completed.  A PTO enables a connection to recover from loss of tail packets or acknowledgements.  The PTO algorithm used in QUIC implements the reliability functions of Tail Loss Probe TLP RACK, RTO RFC5681 and F-RTO algorithms for TCP RFC5682, and the timeout computation is based on TCP's retransmission timeout period RFC6298. </ins> 6.2.1.

Discussion:
Now that the PTO retransmits Initial and Handshake data, it's possible and likely desirable to bundle multiple QUIC packets in a single datagram. This change makes it clear that is allowed.
nits, but lgtm
Change:
and identifies the version used for that packet.  During Version Negotiation (see version and Section 17.2.1 of QUIC-TRANSPORT), the version number field has a special value (0x00000000) that <del> identifies the packet as a Version Negotiation packet.  Many QUIC versions that start with 0xff implement IETF drafts.  QUIC versions that start with 0x0000 are reserved for IETF consensus documents.  For example, QUIC version 1 uses version 0x00000001. </del> <ins> identifies the packet as a Version Negotiation packet.  Upon time of publishing of this document, QUIC versions that start with 0xff implement IETF drafts.  QUIC version 1 uses version 0x00000001. </ins> Operators should expect to observe packets with other version <del> numbers as a result of various internet experiments and future </del> <ins> numbers as a result of various Internet experiments and future </ins> standards. source and destination connection ID: short and long packet

Discussion:
The first is not true really. There are 16 million versions that start with 0xff and we only published 34 drafts and implemented far fewer than that. The second is no longer true as we removed the reservation from the registry. Maybe just strike these sentences.
Time of publication statements are not generally useful in this context.
Change:
The primary method of Registrar "authentication" by the MASA is detailed in RequestVoucherFromMASA.  As detailed in securityconsiderations the MASA might find it necessary to request <del> additional Registrar authentication.  Registrars MUST be prepared to support TLS client certificate authentication and HTTP Basic or Digest authentication as described in RFC7030 for EST clients. </del> <ins> additional Registrar authentication. The Registrar is the client in the BRSKI-MASA connection.  When operating as such, the Registrars MUST be prepared to support TLS client certificate authentication.  The registrar should also be configurable to support HTTP Basic or Digest authentication as described in RFC7030 for EST clients: provision of such credentials of outside the scope of this document and would be part of a supply- chain integration process. </ins> Implementors are advised that contacting the MASA is to establish a secured REST connection with a web service and that there are a number of authentication models being explored within the industry.

Discussion:
Adds text to include SNI in BRSKI-MASA handshake.
I like the first diff (expanding the client authentication discussion into a paragraph). I don't see the need for RFC6066 SNI reference. But since it is a "SHOULD" don't have a technical complaint.
Change:
The length (in bytes) of the following TLSCiphertext.fragment. <del> The length MUST NOT exceed 2^14 + 2048. </del> <ins> The length MUST NOT exceed 2^14 + 256.  An endpoint that receives a record that exceeds this length MUST generate a fatal "record_overflow" alert. </ins> The AEAD encrypted form of TLSPlaintext.fragment.

Discussion:
As discussed on list.
Minor suggestions: 1) Explicitly specify the expectation of a "record_overflow" alert after the two "MUST NOT"s. 2) Also drop the issue "OPEN ISSUE" note that's on line 1087-1088. 3) Amend the changelog to mention this. 4) Add a sentence noting the overhead cap has changed to the "Note: In versions of TLS prior to 1.3" paragraph, or elsewhere.
As NAME suggests, I've updated the PR. I have not added the Note. I don't like those. The change log is enough.
Why was the changelog amended as for draft-09? The draft-08 hasn't been published yet. Is it in the progress of being released? (not shown on DataTracker and releases haven't been tagged on GitHub since draft-05)
Pilot error. Please feel free to submit a PR. , Dave Garrett EMAIL wrote:
This is currently 2^{14} + 2048 (in TLSCiphertexT) and then 2^{14} + 1024 later. This is introduced by leaving room for compression. Should we just reduce this entirely across the board. Certainly we don't need to leave room for compression.
Proposal at interim: 256 octets total.
Change:
skew distributions are not symmetric, so the optimal tradeoff may involve an asymmetric replay window. <del> 4.2.8. RFC6066 and RFC6961 provide extensions to negotiate the server sending OCSP responses to the client.  In TLS 1.2 and below, the server sends an empty extension to indicate negotiation of this extension and the OCSP information is carried in a CertificateStatus message.  In TLS 1.3, the server's OCSP information is carried in an extension in EncryptedExtensions.  Specifically: The body of the "status_request" or "status_request_v2" extension from the server MUST be a CertificateStatus structure as defined in RFC6066 and RFC6961 respectively. Note: This means that the certificate status appears prior to the certificates it applies to.  This is slightly anomalous but matches the existing behavior for SignedCertificateTimestamps RFC6962, and is more easily extensible in the handshake state machine. </del> 4.3. The next two messages from the server, EncryptedExtensions and

Discussion:
This change adds a set of extensions to the Certificate message. This is intended to hold all extension messages that are certificate-specific as opposed to extensions that apply to the entire connection. This change facilitates future extensions to the protocol for post-handshake server authentication and resolves the anomaly of OCSP messages appearing before certificates in the handshake.
Changed SingleCertificate to CertificateEntry
NAME this seems ready to land from my side modulo the rename I propose. Do you have any changes to make?
Change:
5.7. <del> Errors can be reported in ACME both at the HTTP layer and within ACME payloads.  ACME servers can return responses with an HTTP error response code (4XX or 5XX).  For example: If the client submits a request using a method not allowed in this document, then the server MAY return status code 405 (Method Not Allowed). </del> <ins> Errors can be reported in ACME both at the HTTP layer and within challenge objects as defined in identifier-validation-challenges. ACME servers can return responses with an HTTP error response code (4XX or 5XX).  For example: If the client submits a request using a method not allowed in this document, then the server MAY return status code 405 (Method Not Allowed). </ins> When the server responds with an error status, it SHOULD provide additional information using problem document RFC7807.  To facilitate

Discussion:
Also switches the type of the challenge type to be instead of as JSON doesn't have dictionaries. I'll push a follow-up PR that will switch the rest of the -> .
Change:
contains more than one microcontroller.  Often it is also a compressed archive that contains code, configuration data, and even the entire file system.  The image may consist of a <del> differential update for performance reasons.  Firmware is the more universal term.  The terms, firmware image, firmware, and image, are used in this document and are interchangeable. </del> <ins> differential update for performance reasons. </ins> <del> Software: The terms "software" and "firmware" are used interchangeably. Bootloader: A bootloader is a piece of software that is executed once a microcontroller has been reset.  It is responsible for deciding whether to boot a firmware image that is present or whether to obtain and verify a new firmware image.  Since the bootloader is a security critical component its functionality may be split into separate stages.  Such a multi-stage bootloader may offer very basic functionality in the first stage and resides in ROM whereas the second stage may implement more complex functionality and resides in flash memory so that it can be updated in the future (in case bugs have been found).  The exact split of components into the different stages, the number of firmware images stored by an IoT device, and the detailed functionality varies throughout different implementations.  A more detailed discussion is provided in bootloader. </del> <ins> The terms, firmware image, firmware, and image, are used in this document and are interchangeable.  We use the term application firmware image to differentiate it from a firmware image that contains the bootloader.  An application firmware image, as the name indicates, contains the application program often including all the necessary code to run it (such as protocol stacks, and embedded operating system). </ins> Microcontroller (MCU for microcontroller unit): An MCU is a compact integrated circuit designed for use in embedded systems. A typical microcontroller includes a processor, memory (RAM and flash), input/output (I/O) ports and other features connected via some bus on a single chip.  The term 'system on chip (SoC)' is <del> often used for these types of devices. </del> <ins> often used interchangeably with MCU, but MCU tends to imply more limited peripheral functions. </ins> System on Chip (SoC): An SoC is an integrated circuit that <del> integrates all components of a computer, such as CPU, memory, input/output ports, secondary storage, etc. </del> <ins> contains all components of a computer, such as CPU, memory, input/ output ports, secondary storage, a bus to connect the components, and other hardware blocks of logic. </ins> Homogeneous Storage Architecture (HoSA): A device that stores all firmware components in the same way, for example in a file system

Discussion:
First chunk of changes.
This is a really great set of edits. I think that it really improves the document as a whole! I have suggested a couple of minor edits.Quick partial language review
Change:
This specification introduces the Capsule Protocol.  The Capsule Protocol is a sequence of type-length-value tuples that new HTTP <del> Upgrade Tokens (see Section 16.7 of HTTP) can choose to use.  It allows endpoints to reliably communicate request-related information end-to-end on HTTP request streams, even in the presence of HTTP intermediaries.  The Capsule Protocol can be used to exchange HTTP Datagrams when HTTP is running over a transport that does not support the QUIC DATAGRAM frame. </del> <ins> Upgrade Tokens (see HTTP) can choose to use.  It allows endpoints to reliably communicate request-related information end-to-end on HTTP request streams, even in the presence of HTTP intermediaries.  The Capsule Protocol can be used to exchange HTTP Datagrams when HTTP is running over a transport that does not support the QUIC DATAGRAM frame. </ins> This specification defines the "data stream" of an HTTP request as the bidirectional stream of bytes that follow the headers in both

Discussion:
It's shorter and apparently the tagging is what is now required later on in the RFC process anyway.
Change:
All ECDSA computations MUST be performed according to ANSI X9.62 or its successors.  Data to be signed/verified is hashed, and the result run directly through the ECDSA algorithm with no additional hashing. <del> The default hash function is SHA-1 FIPS.180-2, and sha_size (see ske and cert_verify) is 20.  However, an alternative hash function, such as one of the new SHA hash functions specified in FIPS 180-2 FIPS.180-2, SHOULD be used instead. </del> <ins> A secure hash function such as SHA-256, SHA-384, or SHA-512 from FIPS.180-4 MUST be used. </ins> All EdDSA computations MUST be performed according to RFC8032 or its succesors.  Data to be signed/verified is run through the EdDSA

Discussion:
RFC 4492 called SHA-1 the "default" hash for ECDSA, because that was the only hash defined in X9.62 at the time. The new X9.62 (new being a relative term - it's from 2005) defines all the SHA-2 hashes as well. We now make the use of secure hashes a MUST and we call out SHA-256, SHA-384, and SHA-512 explicitly as examples. Also had to update the reference to the SHA document from NIST 180-2 (which did not contain SHA-2) to the current NIST 180-4 (which does)
Change:
QUIC endpoints implementing DPLPMTUD maintain a maximum packet size (DPLPMTUD MPS) for each combination of local and remote IP addresses. <del> 14.2.1. </del> <ins> 14.3.1. </ins> From the perspective of DPLPMTUD, QUIC transport is an acknowledged packetization layer (PL).  A sender can therefore enter the DPLPMTUD BASE state when the QUIC connection handshake has been completed. <del> 14.2.2. </del> <ins> 14.3.2. </ins> QUIC provides an acknowledged PL, therefore a sender does not implement the DPLPMTUD CONFIRMATION_TIMER while in the SEARCH_COMPLETE state; see Section 5.2 of DPLPMTUD. <del> 14.2.3. </del> <ins> 14.3.3. </ins> An endpoint using DPLPMTUD requires the validation of any received ICMP Packet Too Big (PTB) message before using the PTB information,

Discussion:
This was mixed in with other packet size text. A clean split is possible. (Note that this might rot with all the other changes that are in flight. This is a straight move, so it can be rebased easy on that basis.)
Change:
At the time this is published, the response types are works in progress.  The only response type defined in this document is <del> "application/dns-udpwireformat", but it is possible that at least one JSON-based response format will be defined in the future. </del> <ins> "application/dns-udpwireformat", but it is possible that other response formats will be defined in the future. </ins> The DNS response for "application/dns-udpwireformat" in dnswire MAY have one or more EDNS extensions, depending on the extension

Discussion:
The discussion of Accept: header tries too hard to suggest that there will be future formats. We don't actually know that, and the examples in the current draft have confused some developers. See PR URL
Yep, easier to narrow this down than address the implied questions.