jiebi/CodeConvo huggingface dataset:
Code change:
cryptographic key, we use the term "label" for this usage of either an integer or a string to identify map keys and choice data items. <ins> 1.5. One of the standard issues that is specified in IETF cryptographic algorithms is a requirement that a standard specify a set of minimal algorithms that are required to be implemented.  This is done to promote interoperability as it provides a minimal set of algorithms that all devices can be sure will exist at both ends.  However, we have elected not to specify a set of mandatory algorithms in this document. It is expected that COSE is going to be used in a wide variety of applications and on a wide variety of devices.  Many of the constrained devices are going to be setup to used a small fixed set of algorithms, and this set of algorithms may not match those available on a device.  We therefore have deferred to the application protocols the decision of what to specify for mandatory algorithms. Since the set of algorithms in an environment of constrained devices may depend on what the set of devices are and how long they have been in operation, we want to highlight that application protocols will need to specify some type of discovery method of algorithm capabilities.  The discovery method may be as simple as requiring preconfiguration of the set of algorithms to providing a discovery method built into the protocol.  S/MIME provided a number of different ways to approach the problem: Advertising in the message (S/MIME capabilities) Advertising in the certificate (capabilities extension) Minimum requirements for the S/MIME which have been updated over time </ins> 2. The COSE_MSG structure is a top level CBOR object that corresponds to

Related discussion:
text: MTI Algorithm requirements Expand RSASSA-PSS section Correct one coordinate EC for endian Hint to get binary versions of examples Correct kid to binary in the examples (except for static public key one).
Code change:
In both cases, the new members need information to bootstrap their local group state. <del> New members MUST verify the "signature" using the public key taken from the credential in the leaf node of the ratchet tree with leaf index "signer".  The signature covers the following structure, comprising all the fields in the GroupInfo above "signature": </del> <ins> New members MUST verify that "group_id" is unique among the groups they're currently participating in. New members also MUST verify the "signature" using the public key taken from the leaf node of the ratchet tree with leaf index "signer".  The signature covers the following structure, comprising all the fields in the GroupInfo above "signature": </ins> 13.2.3.1.

Related discussion:
text: Brendan to revise based on Rohan suggestion.
Interim 2022-05-26: Concerns around making the group_id totally random Malicious group creator can choose it malicious Federated systems get worse randomness Using AEAD.Nk depends on ciphersuite, could be awkward NAME will revise to say: Here are the requirements that group ID must satisfy If you don’t have an alternative plan, do it randomly
Group ids are signed to bind certain information to specific groups. But I can imagine a case where a user mis-uses the group id to be something like a "room title" which lets an adversary control the group id and introduces potential problems. If we can prove that it's fine for a group id to be reused, then should we get rid of group ids? If not (as I expect), then group ids need to be guaranteed to be unique [globally per signing key] and we need to specify that.
Discussed at 19 May interim. NAME to generate PR documenting fresh random value approach.
Virtual interim 2022-05-19: Agreement that some sort of uniqueness requirement is worthwhile Main question is what scope of uniqueness should be Globally? Within scope of DS? Fresh random value? Simple, but precludes application usage of the field Also could help avoid metadata leakage Client / DS should probably still check for collisions NAME to write up a PR on the fresh random value idea
Group IDs must be generated randomly by creator Clients and DS must check that group ids are unique as far as they know
Code change:
much later - in that scenario one endpoint might be aware of the compatibility document while the other may not. <del> When a client creates a QUIC connection, its goal is to use an application layer protocol.  Therefore, when considering which versions are compatible, clients will only consider versions that support one of the intended application layer protocols.  For example, if the client's first flight advertises multiple Application Layer Protocol Negotiation (ALPN) ALPN tokens and multiple compatible versions, the server needs to ensure that the ALPN token that it selects can run over the QUIC version that it selects. </del> 2.3. When the server can parse the client's first flight using the

Related discussion:
text: Can an ALPN label be used for multiple QUIC versions? I think that the text should say something like: NAME adds (and I wholly agree):
I'm merging into this one where NAME said "The point is that your ALPN offer when you offer QUICvX shouldn't be dependent on if you did VN or not."
LGTM
Code change:
send more than 255 tickets to clients. Servers that support ticket requests MUST NOT echo "ticket_request" <del> in the EncryptedExtensions. </del> <ins> in the EncryptedExtensions message.  A client MUST abort the connection with an "illegal_parameter" alert if the "ticket_request" extension is present in the EncryptedExtensions message. Clients MUST NOT change the value of TicketRequestContents.count in second ClientHello messages sent in response to a HelloRetryRequest. </ins> 4.

Related discussion:
text: Good catch -- will fix. Good suggestion! We can certainly add this. As the extension is merely a hint to servers when deciding how many tickets to vend, I think this is out of scope for the document. It's intended to be once per session, and we'll add that. Also a good catch. Like other extensions that are not affected by the possibly updated ClientHello, it must not change. We need to specify the server side behavior, too. That seems reasonable to me.
Thanks! Approved pending
Code change:
4.2.2. <del> The "manifest" section records a single URL identifying the manifest of the bundle.  The URL MUST refer to a resource with representations contained in the bundle itself. The bundle can contain multiple representations at this URL, and the client is expected to content-negotiate for the best one.  For example, a client might select the one matching an "accept" header of "application/manifest+json" (appmanifest) and an "accept-language" header of "es-419". 4.2.3. </del> The "critical" section consists of the names of sections of the bundle that the client needs to understand in order to load the bundle correctly.  Other sections are assumed to be optional.

Related discussion:
text: This PR removes the manifest section. The motivation is to factor the "core" Web Bundles specification to include just the minimal amount needed to support cases like subresource loading, which does not need a manifest. This and other removed sections can be defined in other documents in the future. Adapted from URL
We might want to make sure the impact of removing manifest section from the bundle format on the chromium. NAME NAME Does Chrome have any usages of manifest section? It seems doesn't use it, however, I am wondering whether there is existing use case for that, I am not aware of.
I never really understood the motivation of this section, since the primary URL response can contain a header pointing to the manifest.
Imagine the situation of application distribution, it is very useful to have a manifest section. For example, we can display the application icon without parsing the HTML of the primary URL. But I agree that the manifest section can be outside the scope of the "core" bundle specification. So removing it from the core spec looks good to me.
LGTM (just for record). Thanks for working on this.
Code change:
references) and are matched against a resolved link target.  Queries for endpoints SHOULD be expressed in path-absolute form if possible and MUST be expressed in URI form otherwise; the RD SHOULD recognize <del> either. </del> <ins> either.  The "anchor" attribute is usable for resource lookups, and, if queried, MUST be for in URI form as well. </ins> Endpoints that are interested in a lookup result repeatedly or continuously can use mechanisms like ETag caching, resource

Related discussion:
text: Closes: URL
In the lookup filtering description, we talk about how href can be queried for (that it only applies in the URI form), but say nothing about anchor (to which the same applies in principle, with slightly different statements about application to the endpoints). Thanks Christer for pointing that out. As RFC6690 contains a lookup example for ?anchor=, we may want to add one here as well.
Code change:
example, the default port for HTTP/3 QUIC-HTTP is UDP port 443, analogous to HTTP/1.1 or HTTP/2 over TLS over TCP. <del> Applications SHOULD define an alternate endpoint discovery mechanism </del> <ins> Applications should define an alternate endpoint discovery mechanism </ins> to allow the usage of ports other than the default.  For example, HTTP/3 (QUIC-HTTP sections 3.2 and 3.3) specifies the use of ALPN RFC7301 for service discovery which allows the server to use and

Related discussion:
text: note: don't merge yet, still need to make the pass on applicability but working on the CI issue at the moment
done. mergeable if ok.
There are a few instances that might be read as normative statements. Is that really wise? Examples: cannot? Maybe this isn't something that this document needs to say. It could just say that fallback to unencrypted TCP might not be a desirable outcome. There is also a bunch of "MUST"-level statements in the 0-RTT section, but I've proposed a rewrite that (I hope) eliminates them.
Fixed in : removed all 2119 language.
Not clear if these documents should use normative language at all. The applicability statement also sometimes uses normative language to recommend the implementation of certain interfaces; I don't think this is the right document for that but as we also don't have another document, we should decide if we want to do that or not!
Manageability is a user's guide to the wire image, as such there's no sense to normative language (though I suppose some might like to add MUST NOT observe packets). Since applicability is in part a set of recommendations to application designers, normative language might make sense there... but the document is informational, so normative language here has to reference or be trivially derived from normative language in one of the base drafts. To simplify things, I'd just scrub all the SHOULDs, MAYs, and MUSTs.
Code change:
5.2.4. <ins> Type: Enum This property specifies whether an application wants to use the connection for sending and/or receiving data.  Possible values are: The connection must support sending and receiving data The connection must support sending data. The connection must support receiving data In case a unidirectional connection is requested, but the system should fall back to bidirectional transport if unidirectional connections are not supported by the transport protocol. 5.2.5. </ins> Type: Preference This property specifies whether an application would like to supply a

Related discussion:
text: This closed As we have no methods on a connection object that query properties, cansend/canreceive also became connection properties. As with all the other connection properties, these are indeed a little underspecified. I want to keep it that way till we fix it for all connection properties with and
Aehm… that comes surprising – NAME why didn't you bring this up in ? Do you think this pull-request is the right place to discuss this issue? I would prefer we merge it now and make a new issue for the question whether the uni-directional connection should be more reflected in the connection. I am not particularly found on keeping it a selection property but would like to have the concept of unidirectional connections rather sooner than later. Our consensus in was that unidirectional connection should use the same abstraction for QUIC unidirectional streams, multicast sources/sinks, and half-closed connections – despite they are constructed in completely different ways. The Selection property is just for the QUIC style ones…

Aehm… that comes surprising – NAME why didn't you bring this up in ? Do you think this pull-request is the right place to discuss this issue? Happy to move the discussion back over to the issue if you like. Will continue the thread here for now though since you've got points to address below. fine, but keep open then, because adding the selection property is possibly-necessary but definitely-not-sufficient to fully address unidirectional connection semantics. good, I agree with this. then I'm confused why this PR purports to since it only addresses part of the issue...?
NAME agreed. The question (and discussion) was about support for including some support for unidirectional connections (with focus on QUIC and half-closed), but omitted details on multicast, as this has not laned yet. So indeed, this pull-requests does everything requested by , but does not fully capture the topic. I will move the open issues (Multicast support, is the Selection Property enough, find some place for more explanation of Uni/Bidi Streams) to once this PR is merged.
In Section 9 – "Setting and Querying of Connection Properties" – the properties of an established connection and path are heavily underspecified. Should be fixed along with .
I'm working on this issue within our pull request for , using the terminology as simplified there.
Code change:
5.2.4. <ins> Type: Enum This property specifies whether an application wants to use the connection for sending and/or receiving data.  Possible values are: The connection must support sending and receiving data The connection must support sending data. The connection must support receiving data In case a unidirectional connection is requested, but the system should fall back to bidirectional transport if unidirectional connections are not supported by the transport protocol. 5.2.5. </ins> Type: Preference This property specifies whether an application would like to supply a

Related discussion:
text: As QUIC has unidirectional streams, we might want to be able to accommodate them in our transport API. Do we want to handle them fundamentally different from a half-closed connection? This should match the decisions made in .
Side note: we don't support half-closed connections to begin with. As for unidirectional streams, is this the final decision in QUIC's design, or might it change? I'd suggest postponing this until we can be sure.
NAME regarding half-closed connections: we don't have any top-level state in the connection for being half-closed. However, being able to express that a message is final in a given direction when sending allows the same functionality. As I've discussed before, we absolutely need the ability to express sending a TCP FIN, but I whole-heartedly agree it doesn't need to be a top level concept. I think this is somewhat different from half-closing, since a unidirectional stream never allows sending on one end. You could imagine that it is a connection object that returns an error if you ever try to send on it, etc. If you wanted it to look like half-closing, you could open a connection (stream), and then mark it complete in a direction immediately? But that's a bit odd.
All ok, I agree with your suggestion to fin-mark a message
I agreee with NAME regarding half-closed. My suggestion is to explicitly state that connections can be uni- or bi-directional and to add a method to query that (cansend / canrecv). This aligns nicely with final messages after which can_send becomes false. I can do a PR for that.
Thanks! I like this
Still missing unidirectional stream for multicast. – please continue discussion of multicast aspects in The connection properties (can send/receive data) are still a little under-specified - please discuss in details in – we should fix this together with .
We need unidirectional connections. You know, for multicast. And ICN. And unidirectional streaming protocols.
This is a dup of , which has more discussion
I am re-opening this ticket as only dealt with unidirectional streams in unicast context (added with PR ): Current status: The current model for unidirectional streams supports half-closed connections and QUIC style unidirectional streams so far.
Code change:
5.2.4. <ins> Type: Enum This property specifies whether an application wants to use the connection for sending and/or receiving data.  Possible values are: The connection must support sending and receiving data The connection must support sending data. The connection must support receiving data In case a unidirectional connection is requested, but the system should fall back to bidirectional transport if unidirectional connections are not supported by the transport protocol. 5.2.5. </ins> Type: Preference This property specifies whether an application would like to supply a

Related discussion:
text: We don't know yet whether it is sufficient to have canread/canwrite property on the connection level to model unidirectional connections We don't have pre-connection methods to create multicast sessions yet
there's a selection property for this, tagged discuss, which we haven't discussed yet. I'm moving this down to the appendix as part of my restructuring in my work on
If help is still wanted here, I'm maybe up for an attempt or 2 at adding multicast support. Has there been some prior discussion I can review about rough ideas on pre-connection methods for multicast sessions, or should I just try making something up?

ok, with the caveat that we need to keep multicast as an open issueLGTM About the multicast concern: I agree that it would be good if this could function for multicast reception too, and I couldn't tell if this is suitable for multicast. I suspect that multicast support is much harder anyway - see RFC 3678... so for now, this is a good step forward IMO, and let's discuss how this relates to multicast when we see a concrete text proposal that addresses it.
Code change:
A client which supports this document SHALL send an empty "delegated_credential" extension in its ClientHello.  If the client receives a delegated credential without indicating support, then the <del> client SHOULD abort with an "unexpected_message" alert. </del> <ins> client MUST abort with an "unexpected_message" alert. </ins> If the extension is present, the server MAY send a delegated <del> credential extension.  If the extension is not present, the server MUST NOT send a credential.  A credential MUST NOT be provided unless a Certificate message is also sent.  The server MUST ignore the extension unless TLS 1.2 or later is negotiated. When negotiating TLS 1.3, and using delegated credentials, the server MUST send the delegated credential as an extension in the CertificateEntry of its end-entity certificate; the client SHOULD ignore delegated credentials sent as extensions with any other certificate.  When negotiating TLS 1.2, the delegated credential MUST be sent as an extension in the ServerHello. </del> <ins> credential extension; if the extension is not present, the server MUST NOT send a delegated credential.  A delegated credential MUST NOT be provided unless a Certificate message is also sent.  The server MUST ignore the extension unless TLS 1.2 or later is negotiated. When negotiating TLS 1.3, the server MUST send the delegated credential as an extension in the CertificateEntry of its end-entity certificate; the client SHOULD ignore delegated credentials sent as extensions to any other certificate.  When negotiating TLS 1.2, the delegated credential MUST be sent as an extension in the ServerHello. </ins> The delegated credential contains a signature from the public key in the end-entity certificate using a signature algorithm advertised by

Related discussion:
text: Based on The delegation certificate MAY have the DelegationUsage extension marked critical. This also adds a "strict" flag to the extension that, if set, requires the server to offer a DC. An alternative that was discussed is to add an optional TLS-feature extension (per RFC 7633) that would provide a "must-use-DC" feature, analogous to "must-staple-OCSP". Howver, it's possible for a certificate with such an extension to be used in a handshake without DCs if the client doesn't indicate support for DCs.
Code change:
1. <ins> Server operators often deploy TLS termination services in locations such as remote data centers or Content Delivery Networks (CDNs) where it may be difficult to detect key compromises.  Short-lived certificates may be used to limit the exposure of keys in these cases. However, short-lived certificates need to be renewed more frequently than long-lived certificates.  If an external CA is unable to issue a certificate in time to replace a deployed certificate, the server would no longer be able to present a valid certificate to clients. With short-lived certificates, there is a smaller window of time to renew a certificates and therefore a higher risk that an outage at a CA will negatively affect the uptime of the service. </ins> Typically, a TLS server uses a certificate provided by some entity other than the operator of the server (a "Certification Authority" or CA) RFC8446 RFC5280.  This organizational separation makes the TLS

Related discussion:
text: The text does not address my concern and will recap my perspective of the discussion. My initial comment was that the reference [KEYLESS] points to a solution that does not work with TLS 1.3 and currently the only effort compatible with TLS 1.3 is draft-mglt-lurk-tls13. I expect this reference to be mentioned and I do not see it in the text proposed text. If the intention with [KEYLESS] is to mention TLS Handshake Proxying techniques, then I argued that other mechanisms be mentioned and among others draft-mglt-lurk-tls12 and draft-mglt-lurk-tls13 that address different versions of TLS. This was my second concern and I do not see any of these references being mentioned. The way I understand your response is that the paper pointed out by [KEYLESS] is not Cloudflare's commercial product but instead a generic TLS Handshake proxying and that you propose to add a reference to an academic paper that discusses the LURK extension for TLS 1.2. I appreciate that other solutions - and in this case LURK, are being considered. I am wondering however why draft-mglt-lurk-tls12 is being replaced by an academic reference [REF2] and why draft-mglt-lurk-tls13 has been omitted. It seems that we are trying to avoid any reference of the work that is happening at the IETF. Is there anything I am missing ? My suggestion for the text OLD: (e.g., a PKCS interface or a remote signing mechanism [KEYLESS]) NEW: (e.g., a PKCS interface or a remote signing mechanism such as [draft-mglt-lurk-tls13] or [draft-mglt-lurk-tls12] ([LURK-TLS12]) or [KEYLESS]) with [KEYLESS] Sullivan, N. and D. Stebila, "An Analysis of TLS Handshake Proxying", IEEE TrustCom/BigDataSE/ISPA 2015, 2015.