jiebi/CodeConvo huggingface dataset:
Change:
4.1. <del> These keys indicate the set of supported protocols (SVCB Section 6.1).  The default protocol is "dot", indicating support for DNS over TLS DOT. </del> <ins> This key indicates the set of supported protocols (SVCB Section 6.1). There is no default protocol, so the "no-default-alpn" key does not apply, and the "alpn" key MUST be present. </ins> If the protocol set contains any HTTP versions (e.g. "h2", "h3"), then the record indicates support for DNS over HTTPS DOH, and the

Discussion:
This change removes the default protocol, which is currently DNS over TLS ("dot"). Several readers have expressed concern that this default is confusing.
Blocked by URL
Section 5.1 says this: The examples are all like this: RFC 6570 says this: I assume that we don't want passed in the SVCB record. Should we clarify that MUST be in relative form, i.e., just the path portion of the URI?
As a normative matter, I think this is already settled in the text, but I'm happy to improve clarity of the description.
Yeah, I think this technically covers it (), but it would be nice to say something at the start of the paragraph to specify that this is just a path segment of the URL.
approved with 1 question
Change:
encapsulated request: a method of POST, a target URI of the oblivious proxy resource, a header field containing the content type (see (media-types), and the encapsulated request as the request content. <del> Clients MAY include fields that do not reveal information about the content of the request, such as Alt-Used ALT-SVC, or information that it trusts the oblivious proxy resource to remove, such as fields that are listed in the Connection header field. </del> <ins> In the request to the oblivious proxy resource, clients MAY include additional fields.  However, those fields MUST be independent of the encapsulated request and MUST be fields that the oblivious proxy resource will remove before forwarding the encapsulated request towards the target, such as the Connection or Proxy-Authorization header fields SEMANTICS. </ins> The client role in this protocol acts as an HTTP client both with respect to the oblivious proxy resource and the oblivious target

Discussion:
cc NAME
Alt-Used sticks out to me. So I looked for whether Alt-Svc is some prerequisite for oblivious HTTP and it doesn't seem so. I'm not sure many folks would be that familiar with Alt-Used, ? Is there some other, more familiar, filed that you could use as an example?
Change:
In step 4, the Pledge establishes a TLS channel with the Cloud RA/ MASA, and optionally the pledge should send a request, steps 3.a and 3.b, to the Cloud RA/MASA to inform it that the Pledge was able to <del> establish a secure TLS channel with the EST Registrar. </del> <ins> establish a secure TLS channel with the EST server. </ins> The Pledge then follows that, in step 5, with an EST Enroll request with the CSR and obtains the requested certificate.  The Pledge must

Discussion:
what is the "EST Registrar"? It is not defined so far. Wouldn't it be better to use RFC 8995 terminology of "EST server" ? So if the cloud Registrar supplies the Voucher and that redirects to an owner's EST server, we can call that "EST server" or "owner EST server". It's not a Registrar, so not "EST Registrar" or "owner Registrar". The latter term is already used for the server that provides a voucher to the pledge. (Interesting to consider that the owner's EST server could be a Registrar i.e. handing out vouchers in theory, even if the cloud-Registrar-supporting-pledge already got its voucher from the cloud-Registrar. But let's not say such things in the document to avoid complicating it.)
Change:
between the ServerHello and the EncryptedExtensions encrypted- extensions message.  The ServerHello MUST only include extensions which are required to establish the cryptographic context. <del> Currently the only such extensions are "key_share" and "pre_shared_key".  Clients MUST check the ServerHello for the presence of any forbidden extensions and if any are found MUST terminate the handshake with a "illegal_parameter" alert. </del> <ins> Currently the only such extensions are "key_share", "pre_shared_key", and "early_data".  Clients MUST check the ServerHello for the presence of any forbidden extensions and if any are found MUST terminate the handshake with a "illegal_parameter" alert. </ins> 6.3.1.3.

Discussion:
The early_data extension should be listed as one of the few that can't go into EncryptedExtensions but must be sent with ServerHello.
Change:
19.6. The CRYPTO frame (type=0x06) is used to transmit cryptographic <del> handshake messages.  It can be sent in all packet types.  The CRYPTO frame offers the cryptographic protocol an in-order stream of bytes. CRYPTO frames are functionally identical to STREAM frames, except that they do not bear a stream identifier; they are not flow </del> <ins> handshake messages.  It can be sent in all packet types except 0-RTT. The CRYPTO frame offers the cryptographic protocol an in-order stream of bytes.  CRYPTO frames are functionally identical to STREAM frames, except that they do not bear a stream identifier; they are not flow </ins> controlled; and they do not carry markers for optional offset, optional length, and the end of the stream.

Discussion:
Thanks! Beat me to it.
In quic-transport-22 section 19.6 it says CRYPTO frames can be sent in all packet types. However in quic-tls-22 section 4 it says the CRYPTO frames can't be sent in 0-RTT packets. Also in quic-tls-22 section 8.3, similar statement. Maybe the statement in quic-transport-22 needs to be corrected?
Change:
and never call an RS, just as it is possible for there not to be a user involved in the delegation process. <del> 1.5.1. </del> <ins> 1.5.2. </ins> In this example flow, the client instance is a web application that wants access to resources on behalf of the current user, who acts as

Discussion:
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: a48ba2e1204e2294f34f8550971f65f684ea7992 Inspect the deploy log: Browse the preview:
Sec. 1.5 (Sequences) would be clearer if we named the top sequence - all other sequences have been named. Maybe "main authorization flow"?
The sequences have not been names per say, they just happen to be related to a subtitle. We could of course create a new subsection, but the idea was to place this sequence above the others.
This is purely editorial. Naming it would make it easier to refer to this sequence.
Change:
A variable-length integer error code which indicates the reason for closing this connection.  A CONNECTION_CLOSE frame of type <del> 0x1c uses codes from the space defined in error-codes.  A CONNECTION_CLOSE frame of type 0x1d uses codes from the </del> <ins> 0x1c uses codes from the space defined in transport-error-codes. A CONNECTION_CLOSE frame of type 0x1d uses codes from the </ins> application protocol error code space; see app-error-codes. A variable-length integer encoding the type of frame that

Discussion:
The current structure is incorrect, because application error codes is a subsection of transport error codes, despite application error codes being disjoint from transport error codes.
Wonderful. Thank you.
Change:
Each frame begins with a Frame Type, indicating its type, followed by additional type-dependent fields: <del> The frame types defined in this specification are listed in frame- types.  The Frame Type in ACK, STREAM, MAX_STREAMS, STREAMS_BLOCKED, and CONNECTION_CLOSE frames is used to carry other frame-specific flags.  For all other frames, the Frame Type field simply identifies the frame.  These frames are explained in more detail in frame- formats. </del> <ins> frame-types lists and summarizes information about each frame type that is defined in this specification.  A description of this summary is included after the table. The format and semantics of each frame type are explained in more detail in frame-formats.  The remainder of this section provides a summary of important and general information. The Frame Type in ACK, STREAM, MAX_STREAMS, STREAMS_BLOCKED, and CONNECTION_CLOSE frames is used to carry other frame-specific flags. For all other frames, the Frame Type field simply identifies the frame. </ins> The "Pkts" column in frame-types lists the types of packets that each frame type could appear in, indicated by the following characters:

Discussion:
Less detail above, but a pointer to what follows.

Table 3: Frame Types The notation used in the table took a while to figure out. A little more explanation, and possibly before the table itself might make it clearer.
One suggestion, but LGTM
Change:
The device that should be protected from being held hostage for a long period of time <del> A remote server that will securely grant the Attester permission to continue operating (i.e., not reboot) for a period of time </del> <ins> A watchdog capable of triggering a procedure that resets a device into a known, good operational state. </ins> 2.7.

Discussion:
There seems to be some confusion: initially it is said that the "Relying Party is the watchdog timer in the TPM." Subsequently, the Relying Party is defined as "A remote server that will securely grant the Attester [...]". So, what is it?
For context, this is now: https://ietf-rats-URL This is plainly wrong (probably due being left over as an artifact after revising the text). How about: "Relying Party: The watchdog capable to trigger a procedure that resets a device into a remediatable operational state."
WFM, except I am not sure "remediatable" is a word. You want to use "known, good" instead?
Sry for my native language habit of concatenating and mangling existing terms. "Known, good" reads very appropriate. Thanks!
The sentence above says that the replying party is inside the TPM?? I think this sentence, relying party is a remote server, is more likely what you mean. In the above paragraph, it says that the Relying Party is inside the TPM. I think this is the correct description. The Relying Party isn't remote in this use case because it has the essential capability to force the device to reboot.
This issue is the same as
Change:
When generating a routable connection ID, the server writes arbitrary bits into its nonce octets, and its provided server ID into the <del> server ID octets.  Servers MAY opt to have a longer connection ID beyond the nonce and server ID.  The additional bits MAY encode additional information, but SHOULD appear essentially random to observers. If the decrypted nonce bits increase monotonically, that guarantees that nonces are not reused between connection IDs from the same server. </del> <ins> server ID octets.  See cid-entropy for nonce generation considerations. </ins> The server encrypts the server ID using exactly the algorithm as described in stream-cipher-load-balancer-actions, performing the

Discussion:
the server no longer has discretion to lengthen the CID. Also, the algorithms are more aligned so there has to be less unique text associated with each algorithm.
In any given deployment, the server use length should be consistent. The load balancer doesn't strictly need to know what it is, but obviously not doing this will lead to observable correlations.
As we've generalized the concept of a nonce, we should abolish the concept of "server use" and make it all a nonce. If the servers need to use the same length to prevent linkability, best to make it part of the configuration.
Change:
3.3. <del> In the WebRTC specification, session descriptions are formatted as SDP messages.  While this format is not optimal for manipulation from Javascript, it is widely accepted, and frequently updated with new features.  Any alternate encoding of session descriptions would have to keep pace with the changes to SDP, at least until the time that this new encoding eclipsed SDP in popularity.  As a result, JSEP currently uses SDP as the internal representation for its session descriptions. </del> <ins> JSEP's session descriptions use SDP syntax for their internal representation.  While this format is not optimal for manipulation from Javascript, it is widely accepted, and frequently updated with new features; any alternate encoding of session descriptions would have to keep pace with the changes to SDP, at least until the time that this new encoding eclipsed SDP in popularity. </ins> However, to simplify Javascript processing, and provide for future flexibility, the SDP syntax is encapsulated within a

Discussion:
Also, remove awkward reference to WebRTC spec
Originally raised by Christer Section 3.3 says: "In the WebRTC specification, session descriptions are formatted as SDP messages." 1) To me it is unclear what an ³SDP message² is, so I suggest we say ³SDP syntax², as we also do later in the section.
FWIW, RFC 4566 itself uses the term 'SDP message' in Section 7. However, we could say 'descriptions use SDP syntax' instead.
Change:
lead to attacks. Let the group of peers who know the key be "A", "B", and "C".  The <del> attack proceeds as follows.  1.  Let the attacker compromise "C" 2. "A" sends a "ClientHello" to "B" 3.  The attacker intercepts the message and creates a new "ClientHello" 4.  The attacker sends the new "ClientHello" to "B" 5.  "B" responds to "A" 6.  The attacker intercepts the message and creates a new response 7.  The attacker sends the new response to "A" 8.  "A" sends a "Finished" message to "B" "A" has completed the handshake, ostensibly with "B".  9.  The attacker intercepts the "Finished" message and creates a new "Finished" message 10.  The attacker sends the new "Finished" message to "B" "B" has completed the handshake, ostensibly with "A". </del> <ins> attack proceeds as follows: Let the attacker compromise "C". "A" sends a "ClientHello" to "B". The attacker intercepts the message and creates a new "ClientHello". The attacker sends the new "ClientHello" to "B". "B" responds to "A". The attacker intercepts the message and creates a new response. The attacker sends the new response to "A". "A" sends a "Finished" message to "B".  "A" has completed the handshake, ostensibly with "B". The attacker intercepts the "Finished" message and creates a new "Finished" message. The attacker sends the new "Finished" message to "B".  "B" has completed the handshake, ostensibly with "A". </ins> This attack, and minor variants of it, violate the remaining properties outlined above.  The attack violates the same session keys

Discussion:
Addresses , , and .
... and don’t prohibit or otherwise interfere with PAKEs. (Though we may want to state that PAKEs should produce PSKs that adhere to this limit if run out of band.)
Fixed in .
Fixed in .
Start with the general recommendation and invariant: Identities should be unique across all nodes, roles, and keys. For each use case, how a part of the invariant is violated and leads to one of the known attacks.
Fixed in .
Change:
"pending", "processing", "valid", "invalid" and "revoked".  If this field is missing, then the default value is "pending". <del> The date after which the server will consider this authorization invalid, encoded in the format specified in RFC 3339 RFC3339. </del> <ins> The timestamp after which the server will consider this authorization invalid, encoded in the format specified in RFC 3339 RFC3339. </ins> The challenges that the client needs to fulfill in order to prove possession of the identifier (for pending authorizations).  For

Discussion:
Also fixes some RFC3339 timestamps shown in examples, which must include seconds.
Authorization expiry should be a timestamp not a date, to allow for authorizations with very short expiry times. All discussion should be done on the mailing list.
Change:
packet protection. A client only receives acknowledgments for its 0-RTT packets once the <del> handshake is complete. </del> <ins> handshake is complete, as defined Section 4.1.1 of QUIC-TLS. </ins> A client MUST NOT send 0-RTT packets once it starts processing 1-RTT packets from the server.  This means that 0-RTT packets cannot

Discussion:
Specify that when the spec says that a "client only receives acknowledgments for its 0-RTT packets once the handshake is complete", it means "as defined in the Handshake Complete section of {{QUIC-TLS}}.".
is complete. Consequently, a server might expect 0-RTT packets to start with a However, this is not necessarily strictly true, because you might have the ACKs in 0.5RTT. Now you might say that the TLS stack reports the handshake as complete as soon as it receives Finished but that's an implementation detail
I think that this is true. The server can send before then, but we require that the client not install 1-RTT keys until it considers the handshake complete.
That's not entirely true. It's the server that needs to hold back keys (namely, the 1-RTT read key) until the handshake completes. The client can use keys as soon as they become available.
I think NAME is correct in sense that the following three events happen at the same moment on the client side: handshake is declared complete TLS stack provides the 1-RTT read and write keys TLS stack provides ClientFinished
Martin is correct. There are two different forms of handshake completion: complete when 1rtt can be sent and received, confirmed when the peer is known to be complete. The client cannot receive 0rtt acks before installing 1rtt keys, hence before hanshake is complete.
We've generally used section numbers for this.
Change:
5.5. <ins> The DTLS 1.3 handshake has one important difference from the TLS 1.3 handshake: the EndOfEarlyData message is omitted both from the wire and the handshake transcript: because DTLS records have epochs, EndOfEarlyData is not necessary to determine when the early data is complete, and because DTLS is lossy, attackers can trivially mount the deletion attacks that EndOfEarlyData prevents in TLS.  Servers SHOULD aggressively age out the epoch 1 keys upon receiving the first epoch 1 record and SHOULD NOT accept epoch 1 data after the first epoch 3 record is received. 5.6. </ins> DTLS messages are grouped into a series of message flights, according to the diagrams below. Note: The application data sent by the client is not included in the timeout and retransmission calculation. <del> 5.6. </del> <ins> 5.7. </ins> <del> 5.6.1. </del> <ins> 5.7.1. </ins> DTLS uses a simple timeout and retransmission scheme with the state machine shown in dtls-timeout-state-machine.  Because DTLS clients

Discussion:
NAME
s'OK wi' me. The other thing to consider mentioning is that record shadowing (key compromise at epoch N allowing the attacker to send records that cause records at epoch >N to be dropped) isn't a concern because dropping records in DTLS is trivial.
NAME thoughts?
Change:
value at each retransmission, up to no less than the RFC 6298 maximum of 60 seconds.  Application specific profiles, such as those used for the Internet of Things environment, may recommend longer timer <del> values.  Note that a 100 msec timer is recommend rather than the </del> <ins> values.  Note that a 100 msec timer is recommended rather than the </ins> 3-second RFC 6298 default in order to improve latency for time- sensitive applications.  Because DTLS only uses retransmission for handshake and not dataflow, the effect on congestion should be

Discussion:
I read through the draft and amassed a number of comments. This PR resolves the easy stuff. I'll send an email to the WG list with the more interesting ones shortly. Grammar fixes.The text describing sequence number encryption doesn't say how the receiver handles short ciphertexts. It's also phrased oddly. It says "In some (rare) cases the ciphertext may be less than 16 bytes", but the whole point of the text is to ensure it cannot be less than 16 bytes. Reword it. Whether there's a Certificate message is no longer a function of the ciphersuite, but of parameters in general. (With resumption that was already true.) The bits talking about epoch 1-3 so far before the definitions of those epochs should link to the section. Remove some remnants of EndOfEarlyData. They're still in the definition of the Handshake struct. I wasn't sure how to handle that since it was in the HandshakeType enum and we probably shouldn't call it RESERVED when it exists in TLS? Spell out [sender]applicationtrafficsecret since trafficsecret isn't defined.
This looks good to me.
These changes look good to me! NAME can you please have a look?
Change:
section is bundled into another m= section, it still MUST NOT contain any ICE credentials. <ins> If the m= section is not bundled into another m= section, an "a=rtcp" attribute line MUST be added with of the default RTCP candidate, as indicated in RFC5761, section 5.1.3. </ins> If the m= section is not bundled into another m= section, for each candidate that has been gathered during the most recent gathering phase (see sec.ice-gather-overview), an "a=candidate" line MUST be

Discussion:
LGTM
What needs to happen to finish this one ?
NAME NAME I think this reflects our discussion in the bug.
LGTM
NAME back at you
Ugh, git push failing due to airplane wifi. Will update when it succeeds
done
Where are we on this. Is this waiting for justin ?
yes, we are waiting for justin
Change:
is no longer valid. The signature algorithm of the credential key pair, where the type <del> SignatureScheme is as defined in the TLS 1.3 standard.  This is expected to be the same as CertificateVerify.algorithm sent by the server. </del> <ins> SignatureScheme is as defined in RFC8446.  This is expected to be the same as CertificateVerify.algorithm sent by the server. </ins> The version of TLS in which the credential will be used, where the <del> type ProtocolVersion is as defined in TLS 1.3.  This is expected </del> <ins> type ProtocolVersion is as defined in RFC8446.  This is expected </ins> to match the protocol version that is negotiated by the client and server.

Discussion:
The suggested OID for the DelegationUsage extension will be 1.3.6.1.4.1.44363.44.
Change:
Construct an initial Commit object with "updates", "removes", and "adds" fields populated from Proposals received during the current <del> epoch, and an empty "path" field. </del> <ins> epoch, and empty "client_init_key" and "path" fields. </ins> Generate a provisional GroupContext object by applying the proposals referenced in the initial Commit object in the order

Discussion:
You can now rebase this on master for clarity.
Here's the Weekly Digest for : - - Last week 5 issues were created. Of these, 1 issues have been closed and 4 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :speaker: , by It received 3 comments. - - Last week, 8 pull requests were created, updated or merged. Last week, 7 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there were 3 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustinsilhouette: - - Last week there were no stargazers. - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
This looks good, just one minor clarification