jiebi/CodeConvo huggingface dataset:
Change:
Previous design ideas for using cryptographically generated session ids, either using hash chains or public key encryption, were dismissed due to their inefficient designs.  Note that a client <del> always has the chance to fall-back to a full handshake or more precisely to a handshake that uses session resumption (DTLS 1.2 language) or to a PSK-based handshake using the ticket-based approach. </del> <ins> always has the chance to fall back to a full handshake or more precisely to a handshake that uses session resumption. </ins> Because each party sends in the extension_data the value that it will receive as a connection identifier in encrypted records, it is

Discussion:
Remove 1.3 references (based on Hannes's PR ); Protect CID; Initial sketch for explicit marking of CID records using ad hoc CTs.
I also do not understand that
Sorry, you're right. It needs to be in the MAC, but not the key derivation
I don't think we need to include the CID in the MAC since the CID is just the key name. In regular DTLS the 5 tuple is the key name and we don't include it in the MAC calculation either. If someone fakes a packet and places a wrong CID in there then they MAC will just fail since either (a) the wrong key will be looked up or (b) no key is found at all. In either case there is no issue.
Change:
data on this stream.  Either frame might arrive before a STREAM or STREAM_DATA_BLOCKED frame if packets are lost or reordered. <del> Before creating a stream, all streams of the same type with lower- </del> <ins> Before a stream is created, all streams of the same type with lower- </ins> numbered stream IDs MUST be created.  This ensures that the creation order for streams is consistent on both endpoints.

Discussion:
The phrase, , is semantically equal to This is not correct since all streams don't create a (new) stream. Moreover, by definition, a stream is created by sending data[1] or STREAM frames implicitly create a stream[2]. This indicates a stream itself doesn't create another stream. [1] URL [2] URL
Looks good. Just a minor comment.
Change:
When only an IP address of an Unencrypted Resolver is known, the client queries a special use domain name to discover DNS SVCB <del> records associated with the Unencrypted Resolver (bootstrapping). </del> <ins> records associated with one or more Encrypted Resolvers the Unencrypted Resolver has designated for use when support for DNS encryption is requested (bootstrapping). </ins> <del> When the hostname of an encrypted DNS server is known, the client </del> <ins> When the hostname of an Encrypted Resolver is known, the client </ins> requests details by sending a query for a DNS SVCB record.  This can be used to discover alternate encrypted DNS protocols supported by a known server, or to provide details if a resolver

Discussion:
I've made a few changes to terms used to correct some accidental lies: the starting IP address could be of an Encrypted Resolver, but does not have to be, discovery by SVCB may discover one or more resolver which may or may not be the original resolver, etc.
Change:
were chosen.  As a result, clients could have more opportunities to switch between attestation participants. <del> 6. </del> <ins> 7. </ins> Beyond the aforementioned security goals for the issuance protocol (issuance-protocol), it is important for Privacy Pass deployments to

Discussion:
cc NAME NAME
The privacy considerations section should probably include a discussion on timing correlation. The timing issues are non-trivial here; in particular, in the scenarios where the token is issued online in response to a token challenge (which is suggested in all of the diagrams, and which is required if the origin requires session-bound tokens). In that case, the anonymity set of issuance flows that could match a redemption flow is limited to those that started after the challenge was sent and ended before the token was redeemed. Even if process takes a second (which seems slow to me), you need a fairly popular issuer service to get a non-trivial anonymity set, and any (obviously desirable) improvements in the latency of this process put further pressure on the anonymity set. I think there should be a caution against deploying PrivacyPass in a setting where the issuance rate can be low, at least in combination with session-bound context.
This is a good suggestion! I proposed text that adds this under the privacy considerations section.
Change:
this suffix key is as defined by the CLDR data for TR35.  At the time of writing, this information is collected in CLDR-CALENDAR. <del> 5. </del> <ins> 6. </ins> IANA is requested to establish a registry called "Timestamp Suffix Tag Keys".  Each entry in the registry shall consist of the

Discussion:
Section 3.3 is not yet updated (but will clearly change a lot) (As discussed at IETF 114)
cc NAME
Hi NAME NAME - what are the next steps on this PR?
NAME NAME - Is there any update on this PR?
There isn't yet, but vacation time has officially ended in Europe... RSN.
Looks great! Thanks for bringing all these edits together. I left one minor comment in case you'd want to make that change, but also OK to merge if you don't think it's needed.
Change:
8.1.1. <ins> A token sent in a NEW_TOKEN frames or a Retry packet MUST be constructed in a way that allows the server to identity how it was provided to a client.  These tokens are carried in the same field, but require different handling from servers. 8.1.2. </ins> Upon receiving the client's Initial packet, the server can request address validation by sending a Retry packet (packet-retry) containing a token.  This token MUST be repeated by the client in all

Discussion:
Question for reviewers: do you think it necessary to point out that this distinction doesn't need to be hidden from other entities? That's almost obvious based on the way that this results in different behaviour from servers, but should it be written down?
We currently say that these tokens SHOULD be distinguishable by a server on the basis that an error in a NEW_TOKEN token is recoverable, but an error in a Retry token is fatal. I don't see why this can't be MUST. If we make it "MUST", then we can rely on this property in the design.
Agreed, that'd be a useful property to rely on.
Does that property need to hold if there are bit flips in the token? If you’re encrypting the token, this would be easy to ensure: put the distinguishing bit under crypto cover. If you’re using a map lookup, you’ll probably have to work a little bit harder.
Please ignore my last post, I mixed up Retry packets and Initials. Tokens in the client’s Initial are part of the AAD, so we don’t have to worry about bit flips.
One suggestion to change a normative to a MUST, on existing text.Some small suggestions, but LG
Change:
"Value" is an abstraction of a primitive value. <ins> "Boolean" is an abstraction of a primitive value that is either "true" or "false". </ins> "OptionalValue" is an abstraction of a primitive value that may also be absent.

Discussion:
Now we have switched to using function extensions for regexp filter matches, the current syntax requires the result to be compared against a boolean, as shown in this example from PR 330: This is consistent with the following statement in the "Existence Tests" section of the spec: If we wanted the following syntax to act as a regexp test: we would have to allow a function expression (returning a boolean result) to be treated as a (rather than an or a ). This would require (a) considerable rework of filter selectors and (b) making a special case of functions which return booleans. To be clear: I am not in favour of such a change. The reason for raising this issue was so that it doesn't come as a surprise to the WG. Thanks to NAME who spotted it when reviewing some draft input to PR 330.
This was fixed by the above PR.
Excellent!
Change:
child node will be uniquely identified by concatenating its integer to it's parents identifier with a dot in between, such as "1.1" and "1.2".  Each node will be summarized by a tuple of three elements: <del> endpoint, path, and protocol.  The above example can now be written more succinctly as: </del> <ins> endpoint, path (labeled here by interface), and protocol.  The above example can now be written more succinctly as: </ins> When an implementation views this aggregate set of connection attempts as a single connection establishment, it only will use one

Discussion:
After reading , I reviewed the latest text. I'm unsure I want to make changes to Arch/API: I see path as "network path", that is the set of hops through which the packet is forwarded (the local interface being the first local hop, and PvD information/PMTU/etc relating to something non-local). This changes the examples using interface to align with this.
Impl draft, section 4.1.2: "Each node will be summarized by a tuple of three elements: Endpoint, Path, and Protocol. The above example can now be written more succinctly as: 1 [URL, Any, TCP] 1.1 [URL, Wi-Fi, TCP] 1.1.1 [192.0.2.1:80, Wi-Fi, TCP] 1.2 [URL, LTE, TCP] 1.2.1 [192.0.2.1:80, LTE, TCP] 1.2.2 [2001:DB8::1.80, LTE, TCP]" looking at the example I would not call this "Endpoint, Path, and Protocol" but "Remote Endpoint, Local Endpoint or interface, and Protocol". Not sure we have defined the term Path well but I would consider a path to consists of both the local and remote endpoint plus optionally maybe even some more information about the path characteristics that might be known for this endpoint pair.
Yeah, it is "remote endpoint", "interface/local endpoint", and "protocol".
note that the wording needs to be fix at least in a few more places, so whoever puts the PR in should probably reach for the word path and ensure it's used correctly...
especially 4.1.3.2. (Alternate Paths) wouldn't fit that well anymore and would probably need some rewriting...
Change:
extension has been negotiated.  Recall that (as discussed previously) each peer chooses the CID value it will receive and use to identify the connection, so an implementation can choose to <del> always recieve CIDs of a fixed length.  If, however, an </del> <ins> always receive CIDs of a fixed length.  If, however, an </ins> implementation chooses to receive different lengths of CID, the assigned CID values must be self-delineating since there is no other mechanism available to determine what connection (and thus,

Discussion:
Tom Petch's review: URL
URL Some editorial quirks s.2 lacks the boiler plate of RFC8174 s.3 I found this unclear until I had understood it all (or perhaps I do not understand it) "URL again, alternately, to use a zero-length CID)." This suggests that a zero length CID is valid in Application Data which later text seems to contradict; otherwise I cannot see what this is saying. " If DTLS peers have negotiated the use of a CIDs using the ClientHello and the ServerHello messages " arguably sending a zero CID and receiving a zero CID is a successful Hello negotiation perhaps " If DTLS peers have negotiated the use of a non-zero CID in at least one direction, using the ClientHello and the ServerHello messages" "The DTLS peers determine whether incoming and outgoing messages need.." seems not to cater for unidirectional CIDs; perhaps "The DTLS peers determine whether incoming or outgoing, or both, messages need.. " s.4 /always recieve CIDs/always receive CIDs/ s.5.1 "the with Encrypt-then-MAC processing described in [RFC7366]." I do not understand why 'with' is needed s.5.2 ditto s.8 /this aspects SHOULD refuse/these aspects SHOULD refuse/ s.10 I would find this clearer as three sections for the three IANA actions new column for ExtensionType new value for ExtensionType new value for ContentType " IANA is requested to allocate an entry to the existing TLS "ExtensionType Values" registry, defined in [RFC5246],.." well no; whatever you think of RFC8447 the name has changed " IANA is requested to allocate an entry to the existing "TLS ExtensionType Values" registry, defined in [RFC5246],.." or, if you are picky (which I am not), IANA is requested to allocate an entry to the existing "TLS "ExtensionType Values" registry, defined in [RFC5246], and renamed by RFC8447 An extra column is added but I cannot see what value should be placed in that column for existing entries. "The tls12_cid ContentType is only applicable to DTLS 1.2." Good information but I struggle to see what IANA will do with it; I see nowhere for it to go. Tom Petch >
Change:
type TRANSPORT_PARAMETER_ERROR. If the Version Information was missing, the endpoints MAY complete <del> the handshake if they have reason to believe the peer might not support this extension.  However, if a client has reacted to a Version Negotiation packet and the Version Information was missing, the client MUST close the connection; if the connection was using QUIC version 1, that connection closure MUST use a transport error of type VERSION_NEGOTIATION_ERROR. </del> <ins> the handshake.  However, if a client has reacted to a Version Negotiation packet and the Version Information was missing, the client MUST close the connection; if the connection was using QUIC version 1, that connection closure MUST use a transport error of type VERSION_NEGOTIATION_ERROR. </ins> If the client received and acted on a Version Negotiation packet, the client MUST validate the server's Other Versions field.  The Other

Discussion:
This draft talks about clients and servers "thinking" and "believing" things. Those verbs don't necessarily apply to protocol implementations, no matter what new frontiers we're exploring in the machine learning space. Might be worth a pass to rephrase these in terms of client or server capabilities and information. "Know" is a little fuzzier, since an endpoint does in fact possess information at certain points in the process.
So... when my computer says "thinking ...", are you saying it's lying to me?
URL
Change:
this as a "slave", the current common usage has shifted to calling it a "secondary". <del> See secondary server. </del> <ins> See "Primary server". </ins> "Any authoritative server configured to be the source of zone transfer for one or more [secondary] servers" (Quoted from

Discussion:
Agree with the first one, although I don't care which way it comes out from the RFC Editor. For the second one, I have changed the wording to 'An authoritative server is named in the NS ("name server") record in a zone.' We don't need to stray into which zone has authoritative data; the double use of "authoritative" will confuse the reader without helping with the terminology.
l 179, s/octets which/octets that. This has been changed to violate the that/which conventions of the RFC Editor. l844 (new) the authoritative name server is named in the parent zone but is not authoritative data there (NS is authoritative in the child). This is discussed elsewhere in the document, and I find this addition confusing. I won't hold up pver either of these. The rest looks ok.
Change:
A more detailed discussion with examples appears in time- considerations. <ins> For a discussion on the security of handles see handles-sec. </ins> 11. The conveyance of Evidence and the resulting Attestation Results

Discussion:
Discuss the impact that altering the distribution of handles (e.g., delaying, suppressing) has on the security of the protocol. Add relevant text to the Security Consideration section.
Is this more than just finishing ? If so, what?
The scope is different: deals with the example in the appendix, this one is for text that belongs to the security considerations. Regarding the "what": is the issue description insufficient? If so, do you have any suggestion on how to make it clearer?
Change:
An example set of protocol messages for this method can be found in example-no-user. <del> 1.5.5. </del> <ins> 1.5.6. </ins> In this example flow, the client instance receives an access token to access a resource server through some valid GNAP process.  The client

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:
hash" because it contains all the handshake messages involved in establishing the session, up to and including the client's Finished. <del> 7.2.2. </del> <ins> 7.3.2. </ins> A conventional Diffie-Hellman computation is performed.  The negotiated key (Z) is used as the shared secret, and is used in the key schedule as specified above.  Leading bytes of Z that contain all zero bits are stripped before it is used as the input to HKDF. <del> 7.2.3. </del> <ins> 7.3.3. </ins> For secp256r1, secp384r1 and secp521r1, ECDH calculations (including parameter and key generation as well as the shared secret

Discussion:
Is good.
The counter has a size of (2^64-1).The records are max (2^14 + 2048). So, my bold calculation would come to (2^64-1) / (2^14 + 2048) / 2^40 = 910.22 TiB of data. In Big Data, video streaming and other mass data cases 910TB data can be a limitation. I would like to propose the counter to go to 2^128-1, which would result in a connection that can reach (2^128-1) / (2^14 + 2048) / 2^80 = 1.52 * 10^10 YiB. If byte preservation is an issue, I'm willing to accept 2^96-1 as the counter max, resulting in (2^96-1) / (2^14 + 2048) / 2^80 = 3.55 YiB as maximum connection.
On a 40Gibit line this will take less time than one might expect: URL (let's say 2.5-3 days with overhead).
Why do you divide by (2^14 + 2048)? Shouldn't it be a multiplication with the minimum record size?
I don't see much support for this. Please take it to the list if you want to pursue it.
Consensus at interim: No protocol action needed. Add calculations to security considerations.
Also, consensus is that the math above is wrong.
NAME would you be willing to contribute a PR with a paragraph or two of guidance on the limits for AES-GCM and ChaCha20
Yes. What happened to the Key Update message? I can't find it in the text, and that would be a logical place to mention the limitations as well as in the security considerations section.
URL If you want to just send a PR against that branch that would be fine. Or really, whatever form you want and I can manually merge.
If we ditch renegotiation (), then we will need a way to rekey sessions to extend their lifetime. Nico suggests that sending ChangeCipherSpec and then using an increasing counter to extract new keys (i.e., add a counter to the key expansion PRF input), which would seem to be sufficient.

We have asked David McGrew about the theoretical limits on AES-GCM, we can find the same info for ChaCha+Poly1305. When we have that info, we will make an assessment as to how urgent this is. That will determine how soon we define this mechanism. NAME noted that you don't even have to negotiate to enable rekeying: if you send the rekey message and rekey, your connection will either be rekeyed, or killed by the peer.
Change:
For example: <del> 3.7. Typed constants can be defined for purposes of specification by declaring a symbol of the desired type and assigning values to it. Under-specified types (opaque, variable-length vectors, and structures that contain opaque) cannot be assigned values.  No fields of a multi-element structure or vector may be omitted. For example: </del> 3.8. TLS defines two generic alerts (see alert-protocol) to use upon

Discussion:
The caveats at the beginning are silly We don't seem to every use Foo = { A, B} but we do use Foo = A;
Fixed, thanks
Change:
The following principles apply: The WebRTC media negotiations will be capable of representing the <del> same SDP offer/answer semantics that are used in SIP RFC3264, in </del> <ins> same SDP offer/answer semantics RFC3264 that are used in SIP, in </ins> such a way that it is possible to build a signaling gateway between SIP and the WebRTC media negotiation.

Discussion:
Ben provided the following comment: s7, list item 1: The citiation to [3264] seems misplaced. It describes the offer/answer model, not SIP in general. I suggest moving the citation to after the word "semantics”.
Change:
described in Section 9.2.1.3 of RFC5245. If the remote DTLS fingerprint has been changed or the dtls-id has <del> changed, tear down the DTLS connection.  If a DTLS connection needs to be torn down but the answer does not indicate an ICE restart, an error MUST be generated.  If an ICE restart is performed without a change in dtls-id or fingerprint, then the same DTLS connection is continued over the new ICE channel. </del> <ins> changed, tear down the DTLS connection.  This includes the case when the PeerConnection state is "have-remote-pranswer".  If a DTLS connection needs to be torn down but the answer does not indicate an ICE restart or, in the case of "have-remote-pranswer", new ICE credentials, an error MUST be generated.  If an ICE restart is performed without a change in dtls-id or fingerprint, then the same DTLS connection is continued over the new ICE channel. </ins> If no valid DTLS connection exists, prepare to start a DTLS connection, using the specified roles and fingerprints, on any

Discussion:
ICE credentials, DTLS fingerprint and SCTP port are allowed to change, which is necessary to support sequential forking with pranswers.
I still need to read this all carefully but at first glance looks reasonable to me.
LGTM. NAME do you want to take another pass? NAME do you want to take a look?
LGTM
Change:
the human readable name of the parameter, <del> the short name as used in query parameters or link attributes, </del> <ins> the short name as used in query parameters or target attributes, </ins> indication of whether it can be passed as a query parameter at registration of endpoints, as a query parameter in lookups, or be <del> expressed as a link attribute, </del> <ins> expressed as a target attribute, </ins> validity requirements if any, and

Discussion:
None of those meant any of (anchor,rel,rev), and all the other attributes that come from serializations should be called by what they are. Closes: URL
Working with RFC8288 in CoRAL I noticed that we're a bit sloppy on some concepts of web linking. This manifests in two related issues: We're talking of link attributes, where that's a term nowhere defined. (Used by RFC6690, but possibly they mean "attributes of CoRE links" and not "Core's use of link attributes", and even there only in the chapter name.) The information model we describe is more the model of the serialized data; the data model makes no distinction, for example, between and . The latter is something we can IMO let slide on account of practical readers having both in mind. The former poses the danger of aggravating the careless use of "link attributes" that'd describe the link-as-a-whole (something not covered by the data model, and thus incompatible with different serializations), but can easily be fixed in a search-and-replace PR coming right up.
Change:
Optional parameters: none <del> Encoding considerations: Must be encoded as using RFC7049.  See RFC- AAAA for details. </del> <ins> Encoding considerations: Must be encoded as using RFC7049. </ins> Security considerations: See seccons of RFC-AAAA.

Discussion:
using "(i)PATCH" to refer to both PATCH methods Clarified defaulting rules Clarified name resolving rules Clarified use of "resource" Added note that application of Patch Packs is idempotent Removed "more details in RFC-AAA" from media type encoding considerations (there are no more details actually)