jiebi/CodeConvo huggingface dataset:
Change:
In this document, we use the term "(D)TLS" to refer to registries that apply to both TLS and DTLS. <del> Add "TLS" to registries' names for consistency with other TLS- related registries. </del> <ins> Add "TLS" to registries' names for consistency amongst TLS-related registries. </ins> Change the IANA registry policy RFC5226 for the TLS ExtensionType Values, TLS Cipher Suite, and TLS ClientCertificateType Identifiers registries.  These changes register a small part of these code spaces for experimentation and private use. <del> Add the designated expert intructions as a note to the TLS ExtensionType Values, TLS Cipher Suite, and TLS ClientCertificateType Identifiers registries to inform users of the registry. </del> <ins> Add designated expert intructions as notes in the TLS ExtensionType Values, TLS Cipher Suite, TLS ClientCertificateType Identifiers, and TLS Exporter Label registries to inform users about what to expect from the designated expert. </ins> Add notes to indicate whether an extension, certain values of an extension, or an entire registry is only applicable pre-(D)TLS

Discussion:
Need to update summary to, at a minimum, reflect that the following is now in the draft: Added "Recommended" column to TLS ExtensionType Values, TLS Cipher Suite, and TLS Exporters registries to clearly indicate which values are specified in IETF Standards Track documents.
Change:
"new_member_proposal": The signature key in the LeafNode in the KeyPackage embedded in an External Add Proposal.  The <del> "content_type" of the message MUST be "proposal"and the </del> <ins> "content_type" of the message MUST be "proposal" and the </ins> "proposal_type" of the Proposal MUST be "add". Recipients of an MLSMessage MUST verify the signature with the key

Discussion:
Comment by NAME I personally don't like the underscored words in the html rendering of the document It "blank" the new American spelling of "blanc" ? I find "summarizes" a strange word here. It is not the hash contains a summary one can read. [SECG] has no IETF equivalent? Should it? proposaland -> proposal and I would say "after removing member C" (avoid ambiguity about "every third") I read this wrong the first way, the "," vanishes due to the unscores. Maybe: This section defines tree hashes, the next section defines parent hashes. Or alternatively, leave onlthe the first sentence in 8.8, then put the remainder and next section in two subsections (so 8.8.1 and 8.8.2) Maybe: For example, a malicious group member could otherwise send Maybe: to public keys whose private key was previously compromised. This reads a little odd as "new groups" would have no history and thus no previous compromise.
Filed I think it's important to emphasize the terms being defined, and this seems more readable than a definition list. Note that a hash function is often called a "message digest", in the same sense as the "Weekly github digest" that goes to the mailing list. I think referring to SECG is still pretty state-of-the-art. But apparently RFC 8446 moved on from that, so I updated to use that representation.
Change:
consider such a Protocol Stack to be established as soon as the Transport Services system has selected a path on which to send data. <del> However, if a peer is not reachable over the network using the connectionless protocol, or data cannot be exchanged for any other reason, the application may want to attempt using another candidate Protocol Stack.  The implementation should maintain the list of other candidate Protocol Stacks that were eligible to use. </del> <ins> However, this can cause a problem if a specific peer is not reachable over the network using the connectionless protocol, or data cannot be exchanged with the peer for any other reason.  To mitigate this, an application can use a Message Framer message-framers on top of a connectionless protocol to only mark a specific connection attempt as ready when some data has been received, or after some application- level handshake has been performed. </ins> 4.7.

Discussion:
That change would have helped me understand what framers can do. It seems a bit out of sync with " A Framer can encapsulate or encode outbound Messages, and decapsulate or decode inbound data into Messages." which sounds like it'd preclude operations like processing received data (or whole messages) into connection object state without emitting a message again -- maybe that sentence could be extended along with it (if even just to include "for example" or "or modify the connection object").
NAME we've added some clarifying text in the message framer definition
Impl draft Section 4.5: Handling racing with "unconnected" protocols "In the case that the application signals that the initial Protocol Stack is failing for some reason and that another option should be attempted, the Connection can be updated to point to the next candidate Protocol Stack. This can be viewed as an application-driven form of Protocol Stack racing." How does the application indicate that? I don't think this is covered by the API draft? Also I would recommend to move this section as a subsection within 4.5. (Completing Establishment) or at least switch the order with the previous section (Establishing multiplexed connections) to get a better reading flow.
This may affect the API draft so we should conclude if the API draft needs to be updated. We do have the functionality in NEAT for racing with unconnected protocols so i think the text is based on that.
Change this to text about how a framer can be used to drive racing over UDP. We shouldn't have a special API for marking the current connection failed.
Action is to propose initial text and follow up at next interim.
Change:
other sources of onboarding information as specified in BRSKI section 4.1 and 5.0. <del> The pledge should establish a provisional TLS connection with specified local domain registrar.  The pledge should not use its </del> <ins> The pledge SHOULD establish a provisional TLS connection with specified local domain registrar.  The pledge SHOULD NOT use its </ins> Implicit Trust Anchor database for validating the local domain <del> registrar identity.  The pledge should send a voucher request message </del> <ins> registrar identity.  The pledge SHOULD send a voucher request message </ins> via the local domain registrar.  When the pledge downloads a voucher, it can validate the TLS connection to the local domain registrar and continue with enrollment and bootstrap as per standard BRSKI

Discussion:
The two occurences of lower-case "may" might be clearer as "might". "The Pledge can be done with" ???? "may" or "MAY"? There are a few occurences of "should" and "must" in these sections, and I wondered about "SHOULD" and "MUST".
Change:
the AEAD checksum will only match if the client IP Address also matches.) <ins> If the token checksum passes, and the ODCIL and RSCIL fields are both zero, then this is an expired NEW_TOKEN token generated by the server.  An active Retry Service MUST drop the packet and issue a Retry packet with the appropriate token. </ins> The service SHOULD drop packets if the Timestamp of the retry token points to a past date; however, in order to allow for clock skew, it SHOULD NOT drop packets if the Timestamp merely points to a a few

Discussion:
and
Thanks Christian, Your comments ended up as an editorial rewrite of the section, with port verification added.
The diagrams indicate they are in the range 0..160. This is incorrect.
SS Tokens can have this, because they could be NEW_TOKEN tokens. But the shared state format is limited to 64.
Fixed by
A few more issues with Retry tokens: For Retry, we're supposed to check the client port. Because this isn't true for NEW_TOKEN, we probably can't put it in the shared-state pseudoheader. Relatedly, we currently just say that the shared-state Retry Service has to be behind any NAT. This isn't enough. For non-shared-state, we're probably fine. For a Retry, the NAT will keep the 4-tuple binding so that on either side there is something to validate. For shared-state: if the service is in front of the NAT, the server can't validate the address. if the service is behind the NAT, it'll "work" but to add any value at all there really has to be a port in there somewhere. We can probably assume that the alternate path that creates the need for shared state won't cause a service-generated token to suddenly appear on the unprotected path.
Fixed by
We should tighten up the rules for Resumption Token processing by the Retry Service. When active, it should reject the packet, but it should send Retry. I believe we can distinguish resumption from Retry because the CID length fields are zero; as any Retry token must have a ODCIDL of at least 8, this would appear to be robust. On a related note, the requirement on servers to encode a way to distinguish the two token types is silly, because of this propery.
Fixed by
Currently the Initial Packet number MAY be encoded in the Retry Token. We must either: Include language that a server MUST NOT reject a token because this information is not present; OR Just make it part of the format. (IMO this would be bad, because then the Retry service would have to decrypt the packet number)
Most changes appear editorial, except for the addition of the port number field. If you add that port, you need to also specify how it should be processed!
Change:
by the network operator, such as reading advertisements, accepting an acceptable-use policy, or providing some form of credentials. <del> Implementations generally require a web server, some method to allow/ block traffic, and some method to alert the user.  Common methods of alerting the user involve modifying HTTP or DNS traffic. </del> <ins> Implementations of captive portals generally require a web server, some method to allow/block traffic, and some method to alert the user.  Common methods of alerting the user in implementations prior to this work involve modifying HTTP or DNS traffic. </ins> This document describes an architecture for implementing captive portals while addressing most of the problems arising for current

Discussion:
One of the reviewers had a bunch of nits. This addresses all of them in one commit. See The issue for the list of nits.
Benjamin writes: Clarify to implementations of captive portals -> "huge variety of preexisting portals and ..." Take the suggestion. Is it sufficient to just say "SHOULD have a non-spoofable mechanism..."? How about "... the operating system could avoid updating the default route to a device on the captive WiFi network until ..." Note: We're changing MAY to could here to address Alvaro's review comment. This is a bit ambiguous. It's meant to basically say: "Stop interacting with the API". We canprobably rephrase to "If certificate validation fails, the User Equipment MUST NOT make any calls tothe API Server". Remove HTTP Do it Do it The identifier. Will update. Fix it. Do it. Do it.
Working on this. Will have a PR up tomorrow.
LGTM. Some small tweaks suggested.
Change:
6. <del> In this design, a wishes to make a request of a server that is authoritative for a . The wishes to make this request without linking that request with either: </del> <ins> In this design, a wishes to make a request to an that is forwarded to a . The wishes to make this request without linking that request with either: </ins> The identity at the network and transport layer of the (that is, the IP address and TCP or UDP port number the uses to create a

Discussion:
This change tries to emphasize that OHTTP is a protocol between client, relay, and gateway, and that the target is sort of ancillary to the whole thing. It further clarifies that the relay should not act as an open proxy when it's operated by an entity that is separate from the target server.
This works for me. We can merge this and then I want to take another pass at the other PR.Thanks NAME -- couple nits, otherwise lgtm.LGTM
Change:
Once a connection exists to a server endpoint, this connection MAY be reused for requests with multiple different URI authority components. <del> In general, a server is considered authoritative for all URIs with the "https" scheme for which the hostname in the URI is present in the authenticated certificate provided by the server, either as the CN field of the certificate subject or as a dNSName in the subjectAltName field of the certificate; see RFC6125.  For a host that is an IP address, the client MUST verify that the address appears as an iPAddress in the subjectAltName field of the certificate.  If the hostname or address is not present in the certificate, the client MUST NOT consider the server authoritative for origins containing that hostname or address.  See Section 4.3 of SEMANTICS for more detail on authoritative access. </del> Clients SHOULD NOT open more than one HTTP/3 connection to a given host and port pair, where the host is derived from a URI, a selected alternative service (ALTSVC), or a configured proxy.  A client MAY

Discussion:
The definition of how you determine a certificate matches an origin isn't specific to reuse, so it belongs in the description of establishing a connection. 3.4 now just says that the certificate needs to also be authoritative for any other origins you want to reuse the connection for. The issue also suggested making this easier to understand, so I'd appreciate suggestions for greater clarity without losing the specifics.
Hilarie Orman wrote: >The only problem that I have is that the authentication model for QUIC-HTTP is not explicitly spelled out. The only discussion is in section 3.4 Connection Reuse, and although that section may be technically correct, I find it hard to understand.
For server authentication, which I think is what you're getting at here, 3.2 also mentions the concept of establishing authority, but doesn't go into much detail. I suspect the specifics of comparing a certificate should move to 3.2. I'd appreciate suggestions for making it easier to understand.
Seems fine.This LGTM. It's clear.
Change:
<del> A nameserver at "ns.example" whose service configuration is </del> <ins> A nameserver at ""ns.example"" whose service configuration is </ins> published on a different domain:

Discussion:
These are really minor, was making all your dns names use the same syntax you started with ("") But I think the examples should look similar in nature. (i'm also thinking of some horrible bad examples to include)
agreed - totally missed that. I pushed up the edit if that is easier.
Change:
to provide enough information to allow the server to decrypt the traffic without negotiation.  This is accomplished by having the client indicate the "cryptographic determining parameters" in its <del> ClientHello, which are necessary to decrypt the client's packets. This includes the following values: </del> <ins> ClientHello, which are necessary to decrypt the client's packets (i.e., those present in the ServerHello).  This includes the following values: </ins> The cipher suite identifier. <del> If PSK is being used, the server's version of the PreSharedKey extension (indicating the PSK the client is using). </del> <ins> "key_share" if (EC)DHE is being used. </ins> <del> [[TODO: Are there other extensions we need?  I've gone over the list and I don't see any, but...]] [[TODO: This should be the same list as what you need for !EncryptedExtensions.  Consolidate this list.]] </del> <ins> If PSK is being used, the server's version of the "pre_shared_key" (indicating the PSK the client is using). </ins> 6.3.2.5.2.

Discussion:
Does it make sense to just have a tri-state column for TLS 1.3 on the extensions registry: "key" - key determining parameters "encrypted" - encrypted "forbidden" - not for use in TLS 1.3
"go" as in whether they are plaintext or go into the EncryptedExtensions block.
Change:
smaller than the min_rtt.  This limits the underestimation that a misreporting peer can cause to the smoothed_rtt. <del> On the first RTT sample for a network path, the smoothed_rtt is set to the latest_rtt. </del> smoothed_rtt and rttvar are computed as follows, similar to RFC6298. <del> On the first RTT sample for a network path: </del> <ins> When there are no samples for a network path, and on the first RTT sample for the network path: Before any RTT samples are available, the initial RTT is used as rtt_sample.  On the first RTT sample for the network path, that sample is used as rtt_sample.  This ensures that the first measurement erases the history of any persisted or default values. </ins> On subsequent RTT samples, smoothed_rtt and rttvar evolve as follows:

Discussion:
As pointed out in , I think that we should assume same amount of RTT variance when there is no RTT sample and when there is one sample, because variance is unknown in both cases. This PR makes that change while keeping the initial PTO being the same (i.e. 1 second), and slightly simplifies the timeout logic.
NAME Thank you for the review. Would you ming checking if the updated text has what you have suggested?
NAME NAME Thank you for the suggestions. I've applied them.
For each connection, the loss detection timeout is defined as 2 InitialRTT. I wonder if this should be 3 InitialRTT instead, because, once you have one RTT sample, PTO is calculated as 3 * InitialRTT. I do not think we have a reason to believe that the variance of RTT (which applies as a multiplier here) increases when we obtain the first sample? PS. The other benefit of making these two consistent is that we can get rid of in SetLossDetectionTimer. It would be possible to always rely on PTO calculation.
I wasn't sure if this would be design or not, but now that the PR is complete, I believe it's editorial, as NAME PR changes the pseudocode, but proscribes exactly the same behavior as the existing text.
To be precise, there is one thing that does change, and that is the initial timeout when a connection is resumed on the same path. At the moment, the only variable we recommend to remember is SRTT, and when resuming a connection on the same path, use 2 SRTT as the initial timeout. The proposed change increases that to 3 SRTT. I think this is better than status-quo, assuming that we agree that RTTVAR should be 2 * sample when there is only one known sample.
Thanks for pointing that out, I noticed that the first time around and then forgot. I'll let NAME make the call about whether he thinks this is design then.
LGTM - thanks, NAME Can you resolve the merge conflict?
Change:
The path secret value for a given node is encrypted for the subtree corresponding to the parent's non-updated child, that is, the child <del> on the copath of the leaf node.  There is one encrypted path secret for each public key in the resolution of the non-updated child. </del> <ins> on the copath of the sender's leaf node.  There is one encryption of the path secret to each public key in the resolution of the non- updated child. </ins> <del> The recipient of a path update processes it with the following steps: </del> <ins> The recipient of an UpdatePath processes it with the following steps: </ins> Compute the updated path secrets.

Discussion:
202105 Interim: To be reviewed by editors.
Ready to merge modulo one nit.
Change:
Endpoint and group lookups result in links to registration resources and group resources, respectively.  Endpoint registration resources are annotated with their endpoint names (ep), domains (d, if present) <del> and context (con); the lifetime (lt) is not reported.  Additional endpoint attributes are added as link attributes to their endpoint link unless their specification says otherwise.  Group resources are annotated with their group names (gp), domain (d, if present) and multicast address (con, if present). </del> <ins> and context (con) as well as a constant resource type (rt="core.rd- ep"); the lifetime (lt) is not reported.  Additional endpoint attributes are added as link attributes to their endpoint link unless their specification says otherwise. Group resources are annotated with their group names (gp), domain (d, if present) and multicast address (con, if present) as well as a constant resource type (rt="core.rd-gp"). </ins> While Endpoint Lookup does expose the registration resources, the RD does not need to make them accessible to clients.  Clients SHOULD NOT

Discussion:
Populates missing descriptions in the IANA template for resource types, but primarily adds new resource types (URL and URL) to the lookup results.
(This was quickly but a bit vaguely agreed on in the last meeting; will merge if nobody objects.)
This was discussed in the last meeting but did not result in an action item; will check whether we agreed to do this (AFAIR we did) and add the text for it.
The right place is in the management example. I hesitated but did not do it chrysn schreef op 2018-06-27 11:51: Links: [1] URL [2] URL
Done with in 801a4352587f4354d57949ab7cb427600a139158.
Change:
"alg" <del> "jwk" </del> <ins> "jwk" (only for requests to new-reg and revoke-cert resources) "kid" (for all other requests). </ins> "nonce" (defined below) "url" (defined below) <del> Note that this implies that GET requests are not authenticated. Servers MUST NOT respond to GET requests for resources that might be considered sensitive. </del> <ins> The "jwk" and "kid" fields are mutually exclusive.  Servers MUST reject requests that contain both. For new-reg requests, and for revoke-cert requests authenticated by certificate key, there MUST be a "jwk" field. For all other requests, there MUST be a "kid" field.  This field must contain the account URI received by POSTing to the new-reg resource. Note that authentication via signed POST implies that GET requests are not authenticated.  Servers MUST NOT respond to GET requests for resources that might be considered sensitive. </ins> In the examples below, JWS objects are shown in the JSON or flattened JSON serialization, with the protected header and payload expressed

Discussion:
Previously, each authenticated POST included a copy of its public key in the JWS protected header. Servers were required to canonicalize this key in some way and look it up in a database, then verify the payload. However, servers also had the option of verifying the payload, and then looking up the key in the database. This opened up a category of potential bugs based on truncated database fields or hash collisions, where an attacker could craft a key pair the would potentially be matched to someone else's account. Incidental benefits: Switching to kid makes payloads somewhat smaller, and removes the need to define key equality in the ACME spec.
Updated based on feedback.
Updated. Rather than have a switch/case about how to authenticate revoke-cert, I split it into two resources, authenticated different ways: one by account, one by cert key.