jiebi/CodeConvo huggingface dataset:
Code change:
provide credentials to an attacker.  Browsers can authenticate servers but cannot detect cleverly misspelled domains, for example. <del> 5.2. </del> <ins> 6.2. </ins> The solution described here assumes that when the User Equipment needs to trust the API server, server authentication will be performed using TLS mechanisms. <del> 5.3. </del> <ins> 6.3. </ins> The solution described here requires that the API be secured using TLS.  This is required to allow the user equipment and API server to

Related discussion:
text: We need to discuss what information will be used to identify the UE from the perspective of the various components in the system. This updates the draft to discuss this concept, including desired properties of the identifier and some examples. This aims to address issue 5 (URL)
Code change:
The client uses the "signature_algorithms" extension to indicate to the server which signature algorithms may be used in digital <del> signatures.  Clients which desire the server to authenticate via a certificate MUST send this extension.  If a server is authenticating via a certificate and the client has not sent a </del> <ins> signatures.  Clients which desire the server to authenticate itself via a certificate MUST send this extension.  If a server is authenticating via a certificate and the client has not sent a </ins> "signature_algorithms" extension then the server MUST abort the handshake with a "missing_extension" alert (see mti-extensions).

Related discussion:
text: Adding "itself" makes the sentence much easier to understand. Actually, two Japanese, who are implementing TLS 1.3 independently, took a long time to understand this.
Code change:
Deployments should take care that the length of the PSK identity is sufficient to avoid obvious collisions. <del> [[OPEN ISSUE: discuss implication of collisions between external and resumption PSKs.]] </del> <ins> 6.1.2. It is possible, though unlikely, that an external PSK identity may clash with a resumption PSK identity.  The TLS stack implementation and sequencing of PSK callbacks influences the application's behaviour when identity collisions occur.  When a server receives a PSK identity in a TLS 1.3 ClientHello, some TLS stacks execute the application's registered callback function before checking the stack's internal session resumption cache.  This means that if a PSK identity collision occurs, the application will be given precedence over how to handle the PSK. </ins> 7.

Related discussion:
text: FIxed up: some nits on recommendations. I think the wording was a bit off on low entropy PSKs, so I lifted from ekrs text from earlier in the draft. some of the stack interface stuff on hints is not valid for TLS1.3 (hints are TLS1.2 and earlier), so removed it. Some prelim text on collisions. For completeness, will take a look at gnutls and wolfssl order too. Note, even with the OpenSSL callback sequence, the application still does not know if there is a collision...
Starter text from NAME
NAME can you please take this?
Ping NAME
Code change:
If the "index" value is equal to the size of the group, increment the size of the group, and extend the tree accordingly <del> Verify the signature on the included UserInitKey; if the signature verification fails, abort </del> <ins> Verify the signature on the included ClientInitKey; if the signature verification fails, abort </ins> Generate a WelcomeInfo object describing the state prior to the add, and verify that its hash is the same as the value of the

Related discussion:
text: Overall, this seems OK. Just using "InitKey" would be clear and less wordy.
I tried this and that led people to confuse and
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 - - Last week, 9 pull requests were created, updated or merged. Last week, 3 pull requests were opened. :greenheart: , by :greenheart: , by :greenheart: , by Last week, 1 pull request was updated. :yellowheart: , by Last week, 5 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 8 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustinsilhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - 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 .
These keys are Client one-time use keys, so "UserInitKey" seems like a strange name.
I'm fine with ClientInitKey, as long as a client is not only a physical endpoint. Changes in the architecture doc should make this clear soon.
Code change:
7.5. <del> The Signal could inform the User Equipment that it is being held captive.  There is no requirement that the User Equipment do something about this.  Devices MAY permit users to disable automatic reaction to captive-portal indications for privacy reasons.  However, there would be the trade-off that the user doesn't get notified when network access is restricted.  Hence, end-user devices MAY allow users to manually control captive portal interactions, possibly on the granularity of Provisioning Domains. </del> <ins> The Captive Portal Signal could inform the User Equipment that it is being held captive.  There is no requirement that the User Equipment do something about this.  Devices MAY permit users to disable automatic reaction to Captive Portal Signals indications for privacy reasons.  However, there would be the trade-off that the user doesn't get notified when network access is restricted.  Hence, end-user devices MAY allow users to manually control captive portal interactions, possibly on the granularity of Provisioning Domains. </ins>

Related discussion:
text: The working group has decided that we do not need to tackle specifying the signaling protocol. Rather than leaving the document with it partially specified, remove most of the text related to it. Keep some basic examples of constraints. This also removes the text which claimed that the document would specify rqeuirements for the protocol. It does not. Made a few related editorial changes.
As suggested by NAME : Do a pass through the document with this text in mind and make sure it makes sense. Clean up anything that may have depended on removed text.
Thanks for putting this together. This seems sufficient, and brief.
Code change:
A token allows a server to correlate activity between the connection where the token was issued and any connection where it is used. <del> Clients that want to break continuity of identity with a server MAY </del> <ins> Clients that want to break continuity of identity with a server can </ins> discard tokens provided using the NEW_TOKEN frame.  In comparison, a token obtained in a Retry packet MUST be used immediately during the connection attempt and cannot be used in subsequent connection

Related discussion:
text: NAME said:
I think "can" works equally well, given the precondition. I'll make that change.
Code change:
4.1. <ins> When a client discovers Designated Resolvers from an Unencrypted Resolver IP address, it can choose to use these Designated Resolvers either automatically, or based on some other policy, heuristic, or user choice. This document defines two preferred methods to automatically use Designated Resolvers: Authenticated Discovery authenticated, for when a TLS certificate can be used to validate the resolver's identity. Opportunistic Discovery opportunistic, for when a resolver is accessed using a non-public IP address. A client MAY additionally use a discovered Designated Resolver without either of these methods, based on implementation-specific policy or user input.  Details of such policy are out of scope of this document.  Clients SHOULD NOT automatically use a Designated Resolver without some sort of validation, such as the two methods defined in this document or a future mechanism. 4.2. Authenticated Discovery is a mechanism that allows automatic use of a Designated Resolver that supports DNS encryption that performs a TLS handshake. </ins> In order to be considered an authenticated Designated Resolver, the <del> TLS certificate presented by the Encrypted Resolver MUST contain both the domain name (from the SVCB answer) and the IP address of the </del> <ins> TLS certificate presented by the Designated Resolver MUST contain both the domain name (from the SVCB answer) and the IP address of the </ins> designating Unencrypted Resolver within the SubjectAlternativeName certificate field.  The client MUST check the SubjectAlternativeName field for both the Unencrypted Resolver's IP address and the

Related discussion:
text: Same comment for line 337/360 about referring to the resolver as Designated versus Encrypted (it's unmodified in this PR but based on your agreement with the other in-line comment it may need modified as well) I think we will need to add some text to the Security Considerations section to mention the security promise difference between following the MAY or not (for optional use of the unverifiable designation). However, we can close this PR without it and handle that in a new PR if that's preferable.
Code change:
SetupBaseS() will be, as well as the aad for context.Seal().  The aad might be the entire "transcript" between the client and helper.] <del> [OPEN ISSUE: Is it safe to generate the proof once, then secret-share between each (leader, helper) pair?  Probably not in general, but maybe for Prio?] </del> [OPEN ISSUE: allow server to send joint randomness in UploadStartResp, and then enforce uniqueness via double-spend state or something else (see issue#48).]

Related discussion:
text: Partially addresses . (We also need to decide if/how to allow a particular PA protocol to use multiple helpers for privacy.) Right now, multiple helpers are used for redundancy in case one of the helpers dropped out. This removes this mechanism from the core protocol.
Squashed and rebased.
That's a good idea,
Hmm... Do we need to decide. Per our discussion on Wednesday, if the clients learn this out of band then we won't need this field at all because clients will get it separately and helpers don't need to know what the other helpers are, right?
My takeaway is that the parameters must contain all input needed to run the protocol, including the helpers. And all of this is configured out of band. You could punt everything except for the cryptographic goop out of the parameters structure, forcing clients to know the leader and helper and get their public keys out of band as well, which would be fine. It's just different. I think both work just fine, but I lean towards having params specify everything. It just seems simpler to me. That said... making public key discovery part of the client upload protocol here is more complex, I think. So, .
Squashed.
LGTM. Multiple helpers "for privacy" seems like it's inherently a per-protocol thing (Prio supports it, Hits does not). If and when we decide to address that, should we move this to the protocol-specific slot in PAParam?
Code change:
streams, and those have stream IDs that are divisible by four.) A variable-length integer indicating the context ID of the <del> datagram (see datagram-contexts). </del> <ins> datagram (see datagram-contexts).  Whether or not this field is present depends on which registration capsules were exchanged on the associated stream: if a REGISTER_DATAGRAM_CONTEXT capsule (see register-capsule) has been sent or received on this stream, then the field is present; if a REGISTER_DATAGRAM_NO_CONTEXT capsule (see register-no-context-capsule) has been sent or received, then this field is absent; if neither has been sent or received, then it is not yet possible to parse this datagram and the receiver MUST either drop that datagram silently or buffer it temporarily while awaiting the registration capsule. </ins> The payload of the datagram, whose semantics are defined by individual applications.  Note that this field can be empty.

Related discussion:
text: I think the second option "Negotiate the presence of context IDs using an HTTP header" is the best personally. In terms of: "Context IDs would still be mandatory to implement on servers because the client might send that header", I assume server in this context is the final application server, not a proxy? Even so, I'd argue it's applications which decide if they need this functionality, so if a server only implemented one application and it didn't use Context-IDs, then I don't see why it would need to implement it.
Ian, in your comment, are you talking about an intermediary when you say "proxy"? If so, then an intermediary need not implement anything based on the payload of than H3 DATAGRAM, it only has to pass the data along. That may be worth a clarification.
Having context ID optional has a nice future-proof property - other uses of datagrams in HTTP/3 can decide if they want the second layer or not. I wouldn't even state it as application needing multiplexing or not. Other applications might find it very useful to include a second ((third, fourth, fifth) layer of frame header. I think its fine for us to state as much in this in the spec, while also defining an explicit second layer for multiplexing.
Yes, by proxy I meant intermediary. And I agree about what intermediaries need to do, I just wanted to ensure I understood what server meant when David used it above. Yup, whenever all this gets written up, we can make it clear that intermediaries can ignore much of this.
The method defines the semantics of datagrams for a particular request, thus I think the third option makes most sense. I don't see a point in using explicit negotiation, since in the two cases I can think of the top of the head, the answer is always clear from the method (CONNECT-IP seems to always want context IDs, WebTransport does not ever want context IDs). If some method starts out without context, but wants to add context later, it can add its own negotiation.
One set of use cases for which the method approach(3) is best are those where there are multiple context IDs but they're predefined by the method and don't need negotiation. My strawman is WebRTC.
Looks good overall.
Code change:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <del> This document uses the Augmented BNF defined in HTTP to specify valid protocol elements.  Additionally, it uses the modified "parameter" rule from RFC5987 and the "URI-Template" rule from URI-TEMPLATE. </del> <ins> This specification uses the following terms from STRUCTURED-FIELDS: List, String, Parameter. </ins> 2. <del> The Link-Template header field provides a means for serialising one or more links into HTTP message metadata.  It is semantically equivalent to the Link header field defined in WEB-LINKING, except that it uses URI Templates URI-TEMPLATE to convey the structure of links. </del> <ins> The Link-Template header field is a Structured Field STRUCTURED- FIELDS that serializes one or more links into HTTP message metadata. It is semantically equivalent to the Link header field defined in WEB-LINKING, except that it uses URI Templates URI-TEMPLATE to convey the structure of links. Its value is a List of Strings.  Each String is a URI Template, and Parameters on it carry associated metadata. </ins> For example:

Related discussion:
text: Emerging best practice is to use for new headers, so that parsing is well-defined. Arguments for sticking with a -like syntax: Consistence with (IMO a very poor justification) Reuse of parsers / other software (it's not well-defined, tho) ???
We could also talk about creating a SF version of (maybe ?).
Matching SF and headers would be appealing.
In the meantime (or maybe before ;) -- URL
Code change:
Changes to this behavior are currently under discussion: see https://github.com/quicwg/base-drafts/issues/602. <del> 3.5. </del> <ins> 3.6. </ins> Round-trip time of QUIC flows can be inferred by observation once per flow, during the handshake, as in passive TCP measurement; this

Related discussion:
text: Re SNI and ALPN: we can certainly point at the work in progress in TLS that will encrypt this information, but IMO the document should describe the current state of the world. I've just added something pointing to the SNI encryption document; while it seems that the tunneling technique described there could pretty clearly be applied to ALPN fronting as well, is there a reference for encrypting ALPN we can use here that doesn't leave details as an exercise for the reader?
I would actually prefer to describe the wire image of TLS and associated protocols in a separate document and just point to it because that's actually not only applicable for quic
I don't have a reference for encrypting ALPN. We don't have one. Maybe I should write one... On the plus side, it's something that benefits from the same techniques as SNI (and less likely to cause deployment issues, though that is only because we haven't ossified around it as much). As for the general point about now vs. later. One of the things we've tried to do is be very clear about what the invariants are, or what promises we are making. It's not the same thing as true ossification defense, but if we make it clear what we are committing to, maybe we won't have people relying on stuff we might want to change.
Code change:
to achieve similar performance.  Those features were introduced to HTTP in HTTP/2 RFC7540.  Earlier versions of HTTP are capable of conveying the semantic requirements of DOH but may result in very <del> poor performance for many uses cases. </del> <ins> poor performance. </ins> 6.3.

Related discussion:
text: Hello, I am a non-native English speaker but I noticed the following sentence: "Earlier versions of HTTP are capable of conveying the semantic requirements of DOH but may result in very poor performance for many uses cases." Shouldn't be there at the end? Wiktionary ( URL ) suggests that plural of "use case" is "use cases", not "uses cases".
Code change:
ClientHello, MUST contain the ConnectionId structure.  This structure contains the CID value the client wishes the server to use when sending messages to the client.  A zero-length CID value indicates <del> that the client is prepared to send with a CID but does not wish the </del> <ins> that the client is prepared to send using a CID but does not wish the </ins> server to use one when sending. A server willing to use CIDs will respond with a "connection_id" extension in the ServerHello, containing the CID it wishes the client to use when sending messages towards it.  A zero-length value <del> indicates that the server will send with the client's CID but does not wish the client to include a CID. </del> <ins> indicates that the server will send using the client's CID but does not wish the client to include a CID when sending. </ins> Because each party sends the value in the "connection_id" extension it wants to receive as a CID in encrypted records, it is possible for

Related discussion:
text: URL Francesca Palombini has entered the following ballot position for draft-ietf-tls-dtls-connection-id-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to URL for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: URL COMMENT: Thank you for the work on this document. I only have minor comments and nits below. Francesca sending messages to the client. A zero-length CID value indicates that the client is prepared to send with a CID but does not wish the server to use one when sending. ... to use when sending messages towards it. A zero-length value indicates that the server will send with the client's CID but does not wish the client to include a CID. FP: clarification question: I am not sure the following formulation is very clear to me: "to send with a(/the client's) CID". Could "send with" be rephrased to clarify? The previous paragraph uses "using a CID value", that would be better IMO. the record format defined in {{dtls-ciphertext} with the new MAC FP: nit - missing "}" in markdown. The following MAC algorithm applies to block ciphers that use the with Encrypt-then-MAC processing described in [RFC7366]. FP: remove "with" Section 10.1 FP: I believe you should specify 1. what allowed values are for this column (i.e. Y or N, and what they mean) and 2. what happens to the existing entries - namely that they all get "N" value. Section 10.2 FP: Just checking - why is 53 "incompatible with this document"? Value Extension Name TLS 1.3 DTLS Only Recommended Reference FP: nit- s/DTLS Only/DTLS-Only to be consistent with 10.1
Code change:
name and the same value, allowing for a trailing "*" wildcard operator as in Section 4.1 of RFC6690.  Attributes that are defined as "link-type" match if the search value matches any of their values <del> (see Section 4.1 of RFC6690; e.g. "?if=core.s" matches ";if="abc core.s";").  A resource link also matches a search criterion if its endpoint would match the criterion, and vice versa, an endpoint link matches a search criterion if any of its resource links matches it. </del> <ins> (see Section 4.1 of RFC6690; e.g. "?if=tag:example.net,2020:sensor" matches ";if="example.regname tag:example.net,2020:sensor";").  A resource link also matches a search criterion if its endpoint would match the criterion, and vice versa, an endpoint link matches a search criterion if any of its resource links matches it. </ins> Note that "href" is a valid search criterion and matches target references.  Like all search criteria, on a resource lookup it can

Related discussion:
text: ... and a few other cases of example errors and use of unregistered names.
Code change:
For each specified RTP header extension, establish a mapping between the extension ID and URI, as described in section 6 of <del> RFC5285.  If any indicated RTP header extension is unknown, this MUST result in an error. </del> <ins> RFC5285.  If any indicated RTP header extension is not supported, this MUST result in an error. </ins> If the MID header extension is supported, prepare to demux RTP data intended for this media section based on the MID header extension, as described in I-D.ietf-mmusic-msid, Section 3.2. <del> For each specified payload type, establish a mapping between the payload type ID and the actual media format, as described in RFC3264.  If any indicated payload type is unknown, this MUST result in an error. </del> <ins> For each specified media format, establish a mapping between the payload type and the actual media format, as described in RFC3264, Section 6.1.  If any indicated media format is not supported, this MUST result in an error. </ins> For each specified "rtx" media format, establish a mapping between the RTX payload type and its associated primary payload

Related discussion:
text: Talk about what to do with header extensions in a remote description Expand discussion of how to handle payload types in a remote description Fail things we don’t know about in an answer ,
LGTM
NAME PTAL at my responses
URL If any indicated payload type is unknown, it MUST be ignored. [TODO: should fail on answers] (q: does this logic need to also include processing for other lines - extmap, rtcp-fb, etc - that weren't present in the offer?)
Fixed by
URL 2) * For each specified payload type that is also supported by the local implementation, establish a mapping between the payload type ID and the actual media format. [TODO - Justin to add more to explain mapping.]
Relevant to as well
Fixed by
URL 1) If the media section proto value indicates use of RTP: [TODO: header extensions]
LGTM