jiebi/CodeConvo huggingface dataset:
Change:
ECDHE parameters for both clients and servers are encoded in the the opaque key_exchange field of a KeyShareEntry in a KeyShare structure. <del> For secp256r1, secp384r1 and secp521r1, the contents are the byte string representation of an elliptic curve public value following the conversion routine in Section 4.3.6 of ANSI X9.62 X962. Although X9.62 supports multiple point formats, any given curve MUST specify only a single point format.  All curves currently specified in this document MUST only be used with the uncompressed point format (the format for all ECDH functions is considered uncompressed). Peers MUST validate each other's public value Y by ensuring that the point is a valid point on the elliptic curve. For the curves secp256r1, secp384r1 and secp521r1, the appropriate validation procedures are defined in Section 4.3.7 of X962 and alternatively in Section 5.6.2.6 of KEYAGREEMENT.  This process consists of three steps: (1) verify that Y is not the point at infinity (O), (2) verify that for Y = (x, y) both integers are in the correct interval, (3) ensure that (x, y) is a correct solution to the elliptic curve equation.  For these curves, implementers do not need to verify membership in the correct subgroup. </del> <ins> For secp256r1, secp384r1 and secp521r1, the contents are the serialized value of the following struct: X and Y respectively are the binary representations of the X and Y values in network byte order.  There are no internal length markers, so each number representation occupies as many octets as implied by the curve parameters.  For P-256 this means that each of X and Y use 32 octets, padded on the left by zeros if necessary.  For P-384 they take 48 octets each, and for P-521 they take 66 octets each. For the curves secp256r1, secp384r1 and secp521r1, peers MUST validate each other's public value Y by ensuring that the point is a valid point on the elliptic curve.  The appropriate validation procedures are defined in Section 4.3.7 of X962 and alternatively in Section 5.6.2.6 of KEYAGREEMENT.  This process consists of three steps: (1) verify that Y is not the point at infinity (O), (2) verify that for Y = (x, y) both integers are in the correct interval, (3) ensure that (x, y) is a correct solution to the elliptic curve equation.  For these curves, implementers do not need to verify membership in the correct subgroup. </ins> For X25519 and X448, the contents of the public value are the byte string inputs and outputs of the corresponding functions defined in

Discussion:
As suggested by Nikos, provide a formal description of the point format modelled on 4492-bis.
Per Nikos's comment.
Change:
are not the next expected message. During the handshake, ACKs only cover the current outstanding flight <del> (this is possible because DTLS is generally a lockstep protocol). Thus, an ACK from the server would not cover both the ClientHello and the client's Certificate.  Implementations can accomplish this by </del> <ins> (this is possible because DTLS is generally a lockstep protocol).  In particular, receiving a message from a handshake flight implicitly acknowledges all messages from the previous flight(s).  Accordingly, an ACK from the server would not cover both the ClientHello and the client's Certificate, because the ClientHello and client Certificate are in different flights.  Implementations can accomplish this by </ins> clearing their ACK list upon receiving the start of the next flight. After the handshake, ACKs SHOULD be sent once for each received and

Discussion:
Clarify that being scoped to the current flight goes hand in hand with the implicit ACK behavior for an entire flight.
Change:
server.  This attack is bound by the number of valid TCP connections an attacker can open. <del> 7.3.4. </del> <ins> 7.4.4. </ins> As more clients enable ESNI support, e.g., as normal part of Web browser functionality, with keys supplied by shared hosting

Discussion:
Addresses .
This seems to be somewhat discussed in the draft and in issues, but I fail to see the motivation behind not using the ESNI key to encrypt other extensions such as ALPN. The main concern seems to be around entities seeing the value of decrypted ALPN, but that's still better than ALPN being the clear. Another concern is a middlebox blocking this extension, but if the client decides to fail hard, blocking is better than leaking; and if a client falls back to unencrypted then the connection works regardless. If I'm missing something, can that be clarified in the draft?
I think that the goal with ALPN is to ensure that the set of values that are advertised remains small and fixed. That is, everyone can offer h2+http/1.1 and no more. This gives no advantage to a passive observer in terms of distinguishing traffic; the pattern of TLS extensions (order and so forth) gives more away.
The other point is that SNI designates the server the client wants to handshakes with. ALPN (as well as other properties of ClientHello) is a property of the handshake. Consider the split case. SNI is decrypted by the fronting server. ALPN will be a property that will be taken into consideration by the backend server.
I agree that in current usage, ALPN is only used for h2 vs http/1.1. But if we had a way to hide ALPN from censors, we could use it to run a VPN over TLS to evade censorship - I'd like to have a TLS server on port 443 that mostly serves HTTPS but can also serve VPN to select clients. In the split case, having the fronting server decrypt the ALPN and pass it decrypted to the backend server is fine - I'm mostly concerned about threats between the client and the fronting server.
Current draft is designed in a way to allow stock TLS servers to be run as a hidden server. Creating a way to pass the decrypted ALPN (or decrypted SNI) from the client-facing server to hidden server destroys that design. Generally speaking, I am not opposed to protecting more properties. OTOH, I might prefer doing things in small steps; we have the extensions field in ESNIKeys.
NAME if you want to advertise a VPN ALPN on all your connections, then that would work.

I'd prefer to establish privacy-preserving usage patterns as the norm so that this is considered acceptable (and not a reason to block a connection). Advertising a willingness to use a VPN connection in addition to HTTP would be analogous to what we're doing here; the observer doesn't know what you ended up using. They could decide to block based on the possibility that you are doing something bad, but that applies to encrypted SNI in equal measure.
This sounds reasonable to me. If we build this solution in a way that allows us to encrypt ALPN later without it being distinguishable from ESNI by a MitM, then I'm happy
NAME this should be fixed by -- please reopen if that's not the case!
NAME works for me, thanks.
Change:
This is done with an HTTPS POST using the operation path value of "/.well-known/est/requestvoucher". <del> The pledge voucher-request Content-Types are: </del> <ins> The pledge voucher-request Content-Type is: </ins> The request is a "YANG-defined JSON document that has been signed using a CMS structure" as described in voucher-request using the

Discussion:
This should be a complete set of diffs for removing unsigned pledge voucher-requests from the text.
For issue
The text "This artifact may be optionally signed" is buried in the yang module (ietf-voucher-URL) and needs to be removed.
When a pledge decides to use an unsigned voucher request, the Registrar will place it into prior-signed-voucher request on the BRSKI-MASA arc. It will be JSON embedded in. When a pledge decides to use a signed voucher request, the Registrar will place the base64 encode of the pledge_request in as a string. The MASA can tell the difference between the two because the signed thing (whether CBOR, COSE, CMS signed CBOR, or CMS signed JSON) will always be base64 encoded. We need to explain this somewhere.
section 5.5 indicates that: prior-signed-voucher-request: If a signed pledge voucher-request was received then it SHOULD be included in the registrar voucher- request. (NOTE: what is included is the complete pledge voucher- request, inclusive of the 'assertion', 'proximity-registrar-cert', etc wrapped by the pledge's original signature). If a signed voucher-request was not recieved from the pledge then this leaf is omitted from the registrar voucher request. This indicates that the MASA never needs to "tell the difference" only the registrar. (The pledge to registrar signaling is via request media type as detailed in s5.2). I did notice this when reading: s3.3. these references to voucher in the leaf description should be to voucher request? "If it is necessary to change a voucher, or re-sign and forward a voucher that was previously provided along a protocol path, then the previously signed voucher SHOULD be included in this field." etc. subsequent paragraphs.
URL tries to fix the lack of specification for unsigned voucher requests.
Max to produce a draft branch that removes unsigned voucher request so we can examine the ramifications of this.
v20 of BRSKI removed unsigned voucher requests. What were the reasons for removing? I don't see a mention of this in the anima WG email. If removed as a final decision, then this issue can be closed also.
Hi, yes, we could close this now. I did post several times to the list in Feb and March, and it was raised during the WG meeting itself, asking for feedback.

Ok, I now see the email list discussion also in December 2018 and based on this the unsigned voucher was removed.
Change:
handshake and not dataflow, the effect on congestion should be minimal. <del> Implementations SHOULD retain the current timer value until a transmission without loss occurs, at which time the value may be reset to the initial value.  After a long period of idleness, no less than 10 times the current timer value, implementations MAY reset the timer to the initial value. </del> <ins> Implementations SHOULD retain the current timer value until a message is transmitted and acknowledged without having to be retransmitted, at which time the value may be reset to the initial value.  After a long period of idleness, no less than 10 times the current timer value, implementations MAY reset the timer to the initial value. </ins> 5.7.3.

Discussion:
This says to reset when you get a transmission without loss, but I actually think this is potentially too conservative and we should just reset on every "first" transmission.
Change:
5.1.1. <del> RFC 4492 defined 25 different curves in the NamedCurve registry for use in TLS.  Only three have seen any use.  This specification is deprecating the rest (with numbers 1-22).  This specification also deprecates the explicit curves with identifiers 0xFF01 and 0xFF02. It also adds the new curves defined in CFRG-Curves and CFRG-EdDSA. The end result is as follows: </del> <ins> RFC 4492 defined 25 different curves in the NamedCurve registry (now renamed the "Supported Groups" registry, although the enumeration below is still named NamedCurve) for use in TLS.  Only three have seen much use.  This specification is deprecating the rest (with numbers 1-22).  This specification also deprecates the explicit curves with identifiers 0xFF01 and 0xFF02.  It also adds the new curves defined in CFRG-Curves and CFRG-EdDSA.  The end result is as follows: </ins> Note that other specification have since added other values to this enumeration.

Discussion:
See Sean Turner's message IETF review is too onerous - use "specification required" instead.
Change:
A time window is expressed in seconds, using the following syntax: <ins> Where "delay-seconds" is a non-negative sf-integer compatible with the "delay-seconds" rule defined in Section 10.2.3 of SEMANTICS. </ins> Subsecond precision is not supported. 2.2.

Discussion:
uses structured fields based on NAME preliminary work: thanks!!!referencing the RFC distinguishing sf-item and sf-integer, since sf-integer do not support parameters whereas sf-item does retaining the intermediate syntaxes (quota-policy, quota-units, service-limit, ...)
LGTM, waiting on ack from NAME before merging.
NAME thanks for reviewing! Can we merge?
It's your draft :)
I take it for a YES :D
Since parameters are always allowed in Limit we could define a "registry" and add them subsequently as soon as implementers needs them. They can be used to specify: max throughputs request distribution other policies All data in parameters is informative.
I assume there must be previous art in keeping a registry like this that we can mimic, but I can't think of a good example off the top of my head that wouldn't be using a separate registry or document to manage that. What's your thinking about where to keep this registry?
NAME registries are usually maintained by IANA: we can check with NAME if that's possible...
We can pretty easily define a registry. You include a section in the RFC. See URL You define a table that is the registry, and meanings of the columns, and perhaps populate it with the initial entries. The WG decides some rules, like "X-" is left for experimentation. There must be something written (it can be an internet draft or something else on the net), whether a set of "experts" need to review for comliance and clarity, and so on.
If you'd like, I can make a PR that provides the initial text for this next week.
Yes, that would be great NAME
Can you give me an initial set of fields (even if it's just one or two), and an example, and a pointer to which section in the current draft? thanks.
Hi NAME Thanks for your support! To make best use of your time, I'd wait for to be merged (waiting for mnot's review) so you can PR directly vs . WRT the parameter registry: currently the initial set is just : See: URL Do you have a proposal for the registration policy?
Thanks, I'll wait. I think it should be expert review.

That means that there should be a document describing the parameter, and that the experts can be directed to verify that the documentation is clear and unambiguous, and that there is no significant overlap with the parameters already defined. The other choices are "specification required" and "first-come first-served."
NAME we just merged structured fields in RateLimit Headers!
Thanks for the ping, I saw :) I'll propose a PR soon.
URL I think it needs to be tweaked, since it's just defined as a "quota" registry in that PR. Should it be a ratelimit fields registry?
Change:
at the end of the ClientHello.  Note that this method of detecting optional data differs from the normal TLS method of having a variable-length field, but it is used for compatibility with TLS <del> before extensions were defined. </del> <ins> before extensions were defined.  As of TLS 1.3, all clients and servers will send at least one extension (at least "key_share" or "pre_shared_key"). </ins> The version of the TLS protocol by which the client wishes to

Discussion:
Small simplification & clarification. Now that the server key share is in an extension, all TLS 1.3 endpoints will have at least one extension in their hello, either "keyshare" or "preshared_key", at minimum. This changeset simplifies the ServerHello struct in the same manner as was previously done for ClientHello and adds short notes explicitly stating this.
Change:
scenario would illustrate persistent congestion: The first three packets are determined to be lost when the <del> acknowlegement of packet 4 is received at t=8.  The congestion period is calculated as the time between the oldest and newest lost packets: (3 - 0) = 3.  The duration for persistent congestion is equal to: (1 * kPersistentCongestionThreshold) = 3.  Because the threshold was reached and because none of the packets between the oldest and the newest packets are acknowledged, the network is considered to have experienced persistent congestion. </del> <ins> acknowledgement of packet 4 is received at t=8.  The congestion period is calculated as the time between the oldest and newest lost packets: (3 - 0) = 3.  The duration for persistent congestion is equal to: (1 * kPersistentCongestionThreshold) = 3.  Because the threshold was reached and because none of the packets between the oldest and the newest packets are acknowledged, the network is considered to have experienced persistent congestion. </ins> When persistent congestion is established, the sender's congestion window MUST be reduced to the minimum congestion window

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:
this way is intended to mitigate the risk of cross protocol attacks involving delegated credentials. <del> The code changes to create and verify delegated credentials would be localized to the TLS stack, which has the advantage of avoiding changes to security-critical and often delicate PKI code (though of course moves that complexity to the TLS stack). </del> <ins> The code changes required in order to create and verify delegated credentials, and the implementation complexity this entails, are localized to the TLS stack.  This has the advantage of avoiding changes to security-critical and often delicate PKI code. </ins> 3.1.

Discussion:
No substantive changes, just grammatical nits and suggestions for clarifying the exposition. In the "Client Behavior" section (Section 3.1), I added a sentence explaining how to check the time-to-live to the first of the DC-validation steps. This might be helpful, as folks have been confused in the past about how to determine if a DC has expired.
LGTM
Change:
5. <ins> (TODO: the ACK section should probably be split between the documents) 6. </ins> [[ TBD: There are a lot of items in the document that are expandable through the use of value registries. ]] <del> 5.1. </del> <ins> 6.1. </ins> This specification establishes the GNAP Token Format Registry to define token formats. <del> 5.1.1. </del> <ins> 6.1.1. </ins> <del> 5.1.2. </del> <ins> 6.1.2. </ins> The table below contains the initial contents of the GNAP Token Format Registry. <del> 6. </del> <ins> 7. </ins> [[ TBD: There are a lot of security considerations to add. ]]

Discussion:
Deploy Preview for gnap-resource-servers-editors-draft ready! Explore the source changes: 94d11a4362aaea79f357583969d87ec4955655a9 Inspect the deploy log: Browse the preview:
Change:
the future, the specification of those fields MUST describe whether they may be provided by the client. <ins> In general, the server MUST ignore any fields in the request object that it does not recognize.  In particular, it MUST NOT reflect unrecognized fields in the resulting account object.  This allows clients to detect when servers do not support an extension field. </ins> The server SHOULD validate that the contact URLs in the "contact" field are valid and supported by the server.  If the client provides the server with an invalid or unsupported contact URL, then the

Discussion:
In some cases, it might be important for a client to know that a server has or has not processed an extension field. For example, if we had an extension that requested some higher level of assurance, then a client would want to know that the CA was going to provide that level of assurance. This PR specifies some rudimentary feature detection to support this objective.
Change:
In order to help clients configure themselves with the right URIs for each ACME operation, ACME servers provide a directory object.  This <del> should be the root URL with which clients are configured.  It is a JSON dictionary, whose keys are the "resource" values listed in https-requests, and whose values are the URIs used to accomplish the </del> <ins> should be the only URL needed to configure clients.  It is a JSON dictionary, whose keys are the "resource" values listed in https- requests, and whose values are the URIs used to accomplish the </ins> corresponding function. <ins> There is no constraint on the actual URI of the directory except that it should be different from the other ACME server resources' URIs, and that it should not clash with other services.  For instance: a host which function as both an ACME and Web server may want to keep the root path "/" for an HTML "front page", and and place the ACME directory under path "/acme". a host which only functions as an ACME server could place the directory under path "/". </ins> Clients access the directory by sending a GET request to the directory URI.

Discussion:
The current wording ("root URL") may lead readers to believe that the ACME directory URI's path is "/", whereas it could actually be anything. Reword to "only URL" and provide examples which emphasize that the choice of the URL for the dictionary object is arbitrary.
Change:
estimate (4*rttvar), and max_ack_delay, to account for the maximum time by which a receiver might delay sending an acknowledgement. When the PTO is armed for Initial or Handshake packet number spaces, <del> the max_ack_delay is 0, as specified in 13.2.5 of QUIC-TRANSPORT. </del> <ins> the max_ack_delay is 0, as specified in 13.2.1 of QUIC-TRANSPORT. </ins> The PTO value MUST be set to at least kGranularity, to avoid the timer expiring immediately.

Discussion:
In recovery for maxackdelay of 0.
Section 5.2.1 of -recovery-25 says: However, Section 13.2.5 of -transport-25 doesn't actually say that (anymore?) Section 13.2.1 says so I guess at least the reference is incorrect. But since Section 19.3 only has a SHOULD for encoding zero and the pseudo code simply uses the encoded ACK delay, if the ACK sender doesn't encode zero, the ACK receiver will compute its RTT based on the encoded ACK delay.
The intent is to use 0 as a peer maxackdelay for the Initial and Handshake packet number spaces. The pseudocode says: ackdelay = min(Ack Delay in ACK Frame, maxack_delay) So for Initial and Handshake, min(Ack Delay, 0) = 0 The text in the "Estimating smoothed RTT and RTTVar" section is fairly clear I think? I fixed the section reference in
I understood the in the to be the value of the transport parameter?
Not for Initial and Handshake PN spaces. Would it be helpful to have a comment above the min() in the pseudocode?
That would at least help me (pointing out it is NOT the value of the TP, although the name is the same.)
I noticed the pseudocode before UpdateRtt() already makes this fairly clear. I can fold the pn_space check into UpdateRtt if you think it would read more clearly?
Ah, so we are not limiting , we are overwriting .