jiebi/CodeConvo huggingface dataset:
Change:
for experimentation with protocols being developed.  Designated experts review, approve, and revoke provisional registrations. <ins> Values 0xFF00-0xFFFF are reserved for private use, to enable proprietary uses and limited experimentation. </ins> This document defines several Reserved values, which can be used by clients and servers to send "greased" values in token challenges and responses to ensure that implementations remain able to handle

Discussion:
To allow experimentation and private types, define a portion of the token type registry to be reserved for private use.
Change:
after the CRYPTO frame. Note that client Initial packets after the first do not always use <del> the Destination Connection ID that was used to generate the Initial </del> <ins> the destination connection ID that was used to generate the Initial </ins> keys.  Therefore, attempts to decrypt these packets using the procedure above might fail. 3.4. <del> The QUIC Connection ID (see rebinding) is designed to allow an on- </del> <ins> The QUIC connection ID (see rebinding) is designed to allow an on- </ins> path device such as a load-balancer to associate two flows as identified by five-tuple when the address and port of one of the endpoints changes; e.g. due to NAT rebinding or server IP address

Discussion:
We've not been capitalizing this in the main spec; so nor should this document. I've fixed those cases that I've touched in my upcoming PR, but it's going to need more work to clean up properly.
Yep, will do that after we merged the PRs. Thanks!
Change:
QUIC packet and framing add at least 36 bytes of overhead to the ClientHello message.  That overhead increases if the client chooses a <del> connection ID without zero length.  Overheads also do not include the token or a connection ID longer than 8 bytes, both of which might be required if a server sends a Retry packet. </del> <ins> source connection ID longer than zero bytes.  Overheads also do not include the token or a destination connection ID longer than 8 bytes, both of which might be required if a server sends a Retry packet. </ins> A typical TLS ClientHello can easily fit into a 1200-byte packet. However, in addition to the overheads added by QUIC, there are

Discussion:
Too fast! Thanks.
This will require rewrapping, which I can do if you prefer.
Change:
results.  Types, classes or the characteristics of an individual target endpoint are defined via endpoint profiles. <ins> An enterprise IT capability managing endpoint identity, endpoint information, and associated metadata on an ongoing basis. </ins> The task by which endpoint attributes are evaluated. The resulting value from having evaluated a set of posture

Discussion:
added terms from the vulnerability assessment scenario
Hi Danny, I still want to highlight one last time that we will have 3-4 different kinds of capability in the terminology in -10 if we pull this in. I understand this to be a basis of discussion still :) I am not sure if that is the case, though! Let me elaborate. We have in SACM used by the architecture: Capability: : The extent of an SACM component's ability enabled by the functions it is composed of. Capabilities are propagated by a SACM component and can be discovered by or negotiated with other SACM components. For example, the capability of a SACM Provider may be to provide endpoint management data, or only a subset of that data. We have in i2nsf, referenced in the sacm terminology: We have the VA Terms: +Endpoint management capability: +: An enterprise IT capability managing endpoint identity, endpoint information, and associated metadata on an ongoing basis. +Vulnerability management capability: +: An enterprise IT capability managing endpoint vulnerabilities and associated metadata on an ongoing basis by ingesting vulnerability description information and vulnerability detection data, and performing a vulnerability assessment. "Managed" in i2nsf means "has interface on the management-plane". I still do not understand what managing actually means in the context of an VA capability :) What potential functions are propagated as capabilities? What is their input? What is their output? Is it possible that the two VA capabilities are actually tasks? Viele Grüße, Henk TL;DR I will pull these terms in, but we will have to align these terms better. On 07/08/2016 01:56 PM, Danny Haynes wrote:
Change:
following fields: A variable-length integer representing the sequence number <del> assigned to the ACK-FREQUENCY frame by the sender, see multiple- frames. </del> <ins> assigned to the ACK-FREQUENCY frame by the sender to allow receivers to ignore obsolete frames, see multiple-frames. </ins> A variable-length integer representing the maximum number of ack- eliciting packets after which the receiver sends an

Discussion:
Plus fixing one spot where it said 2^14, but I think it should have been 2^24
Change:
secrets may be printed on labels or included in a Bill of Materials for ease of scanning or import. <del> 6.2. </del> <ins> 5.2. </ins> PSK provisioning systems are often constrained in application- specific ways.  For example, although one goal of provisioning is to

Discussion:
explain how tls exporter helps with KDF and mitigating selfie attacks. added text on psk identity usage.
I left it empty for Owen (NAME He was planning to contribute some text on PSK collisions (between external PSKs and between external and internal PSKs).
I'll merge and will remove it for now. Owen can add it when he gets around to his PR.
LGTM pending one orphan section!
Change:
difficult to give general guidance for unreliable media transport protocols used to carry interactive real-time media. <del> 1.2. </del> <ins> 1.3. </ins> Note to RFC Editor: Please remove this section and its subsections before publication.

Discussion:
Also move some expansions and references to first use.
From NAME -
Hi, NAME - We've been focused on what endpoints could do to improve streaming media performance, but it does seem helpful to point that out more clearly. Please see if is helpful.
Change:
The EDHOC-KeyUpdate takes a nonce as input to guarantee that there are no short cycles.  The Initiator and the Responder need to agree <del> on the nonce, which can e.g., be a counter or a random number. </del> <ins> on the nonce, which can e.g., be a counter or a random number.  While the KeyUpdate method provides forward secrecy it does not give as strong security properties as re-running EDHOC, see security. </ins> 5.

Discussion:
Comment by Robert Moskowitz
I think the forward secrecy could use some more text. Right know we are using the definition according to the IETF security dictionary, but as the security dictionary states, a lot of different definitions is used. The draft that the KeyUpdate gives much better security than using a single key, but that the KeyUpdate method gives a lower security level than frequently running ephemeral diffie-hellman
Change:
input-share-decryption. Check that the resulting input share is valid as described in <del> input-share-batch-validation. </del> <ins> early-input-share-validation. </ins> Initialize VDAF preparation and initial outputs as described in input-share-prep. <del> [[OPEN ISSUE: consider moving the helper nonce check into #input- share-batch-validation]] </del> <ins> [[OPEN ISSUE: consider moving the helper nonce check into #early- input-share-validation]] </ins> Once the helper has processed each valid report share in "AggregateInitializeReq.report_shares", the helper then creates an

Discussion:
Clarify that is used when it's impossible to determine if an input share is valid. One situation we need this for is when an Aggregator drops some anti-replay state in order to reduce storage costs. This should result in data loss in the worst case, not a loss of privacy.
Since , aggregators are required to store report nonces for batch intervals that have not yet been collected. This is necessary in order to prevent replay attacks. The problem is that nothing guarantees that a batch interval will be collected in a timely manner: In theory, it's possible that aggregators will have to store nonce sets indefinitely. To prevent this, there needs to be a way for the aggregators to agree on when to stop accepting reports for a given batch interval. The strawman solution is to allow each aggregator to, at its own discretion, ignore a report if it can't confirm if the report was replayed or not. The problem is that this potentially leads to unnecessary data loss.
I propose resolving this with .
Change:
2. <del> Clients are configured to use UDP Proxying over HTTP via an URI </del> <ins> Clients are configured to use UDP Proxying over HTTP via a URI </ins> Template TEMPLATE with the variables "target_host" and "target_port". Examples are shown below: <del> The URI template MUST be a level 3 template or lower.  The URI template MUST be in absolute form, and MUST include non-empty scheme, </del> <ins> The URI Template MUST be a level 3 template or lower.  The URI Template MUST be in absolute form, and MUST include non-empty scheme, </ins> authority and path components.  The path component of the URI <del> template MUST start with a slash "/".  All template variables MUST be </del> <ins> Template MUST start with a slash "/".  All template variables MUST be </ins> within the path component of the URI.  The URI template MUST contain the two variables "target_host" and "target_port" and MAY contain <del> other variables.  The URI template MUST NOT contain any non-ASCII </del> <ins> other variables.  The URI Template MUST NOT contain any non-ASCII </ins> unicode characters and MUST only contain ASCII characters in the range 0x21-0x7E inclusive (note that percent-encoding is allowed). <del> The URI template MUST NOT use Reserved Expansion ("+" operator), </del> <ins> The URI Template MUST NOT use Reserved Expansion ("+" operator), </ins> Fragment Expansion ("#" operator), Label Expansion with Dot-Prefix, Path Segment Expansion with Slash-Prefix, nor Path-Style Parameter Expansion with Semicolon-Prefix.  If any of the requirements above <del> are not met by a URI template, the client MUST reject its </del> <ins> are not met by a URI Template, the client MUST reject its </ins> configuration and fail the request without sending it to the proxy. Since the original HTTP CONNECT method allowed conveying the target

Discussion:
-> a URI Template
but also is it "URI Template" or "URI template"? this seems inconsistent through the document
Change:
Decrypt and verify the COSE_Encrypt0 as defined in Sections 5.2 and 5.3 of I-D.ietf-cose-rfc8152bis-struct, with the EDHOC AEAD algorithm in the selected cipher suite, and the parameters defined <del> in asym-msg3-proc.  Discard padding, if present. </del> <ins> in asym-msg3-proc.  Discard the padding PAD_3, if present. </ins> Make ID_CRED_I and (if present) EAD_3 available to the application for authentication- and EAD processing.

Discussion:
This is an editorial change.
If there is a risk someone thinks that padding in the messages must be the same we could use PAD2, PAD3, PAD_4.
If I understand correctly, the PAD is to hide the length of the messages. If the three messages share the same PAD length, it is enough for one of the message to have a length known by the attacker, e.g. if EAD_4 is of constant length across all sessions, to leak the length of the PAD, and thus the length of the other messages contents. As such, 3 distinct padding lengths would be strictly better. Otherwise, as the encryptions are distinct (different key streams), I on my side don't see any weird cryptographic interactions that would be possible. (a side question is does the padding in message 2 leads to potential for padding oracles attacks, where the attacker could try to flip a few bytes of the cyphertext and learn some information based on which step of the processing fail. However, that is covered by I guess)
This is an editorial change. I merged the PR and will close this issue. No and yes. SIGMA and EDHOC and TLS 1.3 does not provide confidentiality of the second flight to active attackers (except maybe the signature). In SIGMA and EDHOC and attacker can modify the second flight and gain information. But this attack seems very uninteresting compared to attacks where the attacker modifies message_1.
Change:
true, indicates the client's agreement with the terms of service. This field cannot be updated by the client. <ins> Including this field in a newAccount request indicates approval by the holder of an existing non-ACME account to bind that account to this ACME account.  This field is not updateable by the client. (See external-account-binding). </ins> A URL from which a list of orders submitted by this account can be fetched via a POST-as-GET request, as described in orders-list.

Discussion:
From Section 7.3: "MUST URL account bodies sent by the URL other fields that it does not recognize" in the first paragraph seems to be unnecessarily repeated by "MUST ignore any fields in the request object that it does not recognize" in the second paragraph. This PR merges these two paragraphs and discards the duplicated text. Also, "account bodies" isn't used anywhere else in the document, so this PR changes it to "account objects".
This looks reasonable to handle in AUTH48.
the last part isn't purely editorial, but okay.
Change:
can be altered by a middlebox without affecting MPTCP, as the data stream is equivalent to a regular, legacy TCP session.  The MP_FAIL signal affects only one direction of traffic.  It is not mandatory <del> for the reciever of an MP_FAIL to also respond with an MP_FAIL, since </del> <ins> for the receiver of an MP_FAIL to also respond with an MP_FAIL, since </ins> the paths may only be damaged in one direction.  However, implementations MAY choose to send a MP_FAIL in the reverse direction and entirely revert to a regular TCP session.

Discussion:
Reading through the draft I noticed a few typos so I wanted to propose a small change to fix.
Change:
7. <del> Servers that support ECH play one of two roles, depending on the extension in the ClientHello.  If the "encrypted_client_hello" extension is present, the server acts as a client-facing server and proceeds as described in client-facing-server to extract a ClientHelloInner, if available.  If the "ech_is_inner" extension is present and the "encrypted_client_hello" extension is not present, the server acts as a backend server and proceeds as described in backend-server. </del> <ins> Servers that support ECH play one of two roles, depending on which of the "ech_is_inner" and "encrypted_client_hello" extensions are present in the ClientHello: If both the "ech_is_inner" and "encrypted_client_hello" extensions are present in the ClientHello, the backend server MUST abort with an "illegal_parameter" alert. If only the "encrypted_client_hello" extension is present, the server acts as a client-facing server and proceeds as described in client-facing-server to extract a ClientHelloInner, if available. If only the "ech_is_inner" extension is present and the "encrypted_client_hello" extension is not present, the server acts as a backend server and proceeds as described in backend-server. If neither extension is present, the server completes the handshake normally, as described in RFC8446. </ins> 7.1.

Discussion:
The text for servers rejecting both extensions present is under Backend Server, but the Server Behavior text gates that section under just the one extension. Likewise, the client-facing server text allows for both extensions to be present. Move the illegal_parameter text around and write out the four cases.
Change:
5. HTTP message encapsulation uses HPKE for request and response <del> encryption.  An encapsulated HTTP message includes the following values: A binary-encoded HTTP message; see BINARY. Padding of arbitrary length which MUST contain all zeroes. The encoding of an HTTP message is as follows: </del> <ins> encryption.  An encapsulated HTTP message includes a binary-encoded HTTP message and no other content; see BINARY. </ins> An Encapsulated Request is comprised of a length-prefixed key identifier and a HPKE-protected request message.  HPKE protection

Discussion:
See discussion on-list.
See also URL
If we're pinning the contents of the encapsulation to message/bhttp, it seems like we also ought to change the HPKE info strings to match ("request" -> "message/bhttp-request" or whatever). When someone tries to reuse this layer of encapsulation, I think they ought to change the info string accordingly to match whatever the underlying type is. And it might not hurt to add guidance to such people in the security considerations. Can we do this in a followup PR?
I agree that we should think about content types a bit more, but that seems appropriate for another PR.
With , we're enforcing a 1:1 mapping between message/ohttp-req and message/bhttp, but we don't have any cryptographic enforcement of this pairing. If someone were to reuse the encapsulation mechanism in this document with another message type, say, to encapsulate application/dns-message values with a application/oblivious-dns-message wrapper, then we'd probably want to ensure that targets can't get confused between these two types. We could use the HPKE info string to separate these two protocols. (This is related to .)
The format I've sketched out for binary messages can be padded with zeros without needing a separate padding field. That's probably a feature worth mentioning in both drafts.
Padding is in the binary HTTP draft now.
Change:
4. <ins> To prevent PSK Importers from being confused with standard OOB PSKs we change the label used in the computation of the PSK binder key. In TLS 1.3 the PSK binder key computation is defined as follows: We replace the string "ext binder" with "imp binder".  This means the binder key is now computed as follows: This new label differentiates non-imported and imported external PSKs.  Specifically, a client and server will negotiate use of an external PSK if and only if (a) both endpoints import the PSK or (b) neither endpoint imports the PSK.  The "binder_key" is a leaf key. Therefore, changing its computation doesn't affect any other key. 5. </ins> A key importer takes as input an EPSK with external identity 'external_identity' and base key 'epsk', as defined in terminology, along with an optional label, and transforms it into a set of PSKs

Discussion:
Discussed in Singapore; will merge and add security considerations motivation in a followup to .
The document says: Aside from this statement needing update in light of the changes to the binder label, the core statement here isn't expanded upon. The document needs to very clearly say that the PSK ID that is sent in the psk extension is literally the serialized content of .
Fixed in .
This seems harmless, but it is predicated on a need to separate keys that I don't understand. Is there more rationale somewhere?
Change:
opened.  The server MAY limit the amount of connections open by the same client. <del> 8. </del> <ins> 9. </ins> <del> 8.1. </del> <ins> 9.1. </ins> The following entry is added to the "Application Layer Protocol Negotiation (ALPN) Protocol IDs" registry established by RFC7301:

Discussion:
This defines a new URL scheme for QuicTransport, and clarifies the use of "https" for Http3Transport.
Change:
Address case nits <ins> Add text about certificate extension vs EKU </ins> draft-08 Include details about the impact of signature forgery attacks

Discussion:
From Russ: I guess I ask the authors to add a paragraph to the rationale section that says something about why this extension was used instead of an extended key usage. From Watson: One of the hard requirements for our deployment was that the same certificate be useable with DCs and without. A different EKU would be more problematic then an extension for this purpose, and while it might be more or less irritating for implementors depending on how their stack works (sorry Rich - https://boringssl-URL might serve as inspiration, but the client side got dropped for similar issues). We know the extension doesn't bust things, I don't know an EKU would, and the root program issues make me hesitate.
Addressed in
Change:
An endpoint MAY send data to an unvalidated peer address, but it MUST protect against potential attacks as described in address-spoofing and on-path-spoofing.  An endpoint MAY skip validation of a peer <del> address if that address has been seen recently. </del> <ins> address if that address has been seen recently.  In particular, if an endpoint returns to a previously-validated path after detecting some form of spurious migration, skipping address validation and restoring loss detection and congestion state can reduce the performance impact of the attack. </ins> An endpoint only changes the address that it sends packets to in response to the highest-numbered non-probing packet.  This ensures

Discussion:
This is really just an observation, because there is no real way we can insist on people doing this sort of thing, but being aware of the performance implication of spoofed migrations might motivate solutions.
I think the sections that describe connection migration attacks should mention that, when the endpoint detects a spurious migration, it should revert back to using the same CC state and ECN state as before. Otherwise, an attacker could degrade the performance of a connection.
Perhaps the tag should be recovery, not transport.
I can see it going either way. NAME what do you think?
I think the text is going to be in transport, so that's probably the right tag
As long as this doesn't lead to confusion (for example: we recently tightened up the MUST around resetting state) for folks when reading this, I think it's really valuable to actually state this in the draft rather than hint at it throughout -- looks good!
Change:
Imported keys do not require negotiation for use, as a client and server will not agree upon identities if not imported correctly. Thus, importers induce no protocol changes with the exception of <del> expanding the set of PSK identities sent on the wire. </del> <ins> expanding the set of PSK identities sent on the wire.  Endpoints may incrementally deploy PSK importer support by offering non-imported keys for TLS versions prior to TLS 1.3.  (Negotiation and use of imported PSKs requires both endpoints support the importer API described herein.) </ins> 3.1.

Discussion:
Importantly, add details regarding incremental deployment, and clarify label values for non TCP-based variants of TLS.
Fixed in .
Fixed in .
Both endpoints must adopt importers for interoperability's sake.
Fixed in .
"TLS 1.3 supports pre-shared key s/resumption/authentication"
Fixed in .