jiebi/CodeConvo huggingface dataset:
Change:
The sequence number specified in a RETIRE_CONNECTION_ID frame MUST NOT refer to the Destination Connection ID field of the packet in which the frame is contained.  The peer MAY treat this as a <del> connection error of type FRAME_ENCODING_ERROR. </del> <ins> connection error of type PROTOCOL_VIOLATION. </ins> An endpoint cannot send this frame if it was provided with a zero- length connection ID by its peer.  An endpoint that provides a zero-

Discussion:
This seems like another instance of deciding the scope of "context." Is the packet that the frame arrived in part of the connection context, or is it part of looking at the bytes?
NAME Even if the packet header is part of the context, that still doesn't help. The RETIRECONNECTIONID frame only carries the sequence number, not the actual connection ID. You have to access connection-level information to detect this error, which makes the FRAMEENCODINGERROR a poor choice here.
+1 to what NAME says. In addition this is a "MAY send" error, therefore I do not think we need to be cautious in trying to list all the possible error codes.
Our principle regarding error codes states that only those errors that are detectable without accessing connection state should result in a FRAMEENCODINGERROR. Since the RETIRECONNECTIONID frame contains only the sequence number of the connection ID, but not the actual connection ID itself, this should be a different error. Looking through the list of error codes, it seems like we don't have any more specific error code here, so this would be a PROTOCOL_VIOLATION.
Seems OK.
As the proposed PR indicates, this would be a design change.
Agreed, this seems OK.
As I noted in the PR, I agree that PROTOCOL_VIOLATION seems like a more appropriate error. In addition to NAME point, this is a semantic error, not one of encoding (which suggests syntactic).
It seems we have a proposed resolution, marking as such.
PR was less than a year ago, that's when this error code went from PROTOCOLVIOLATION to FRAMEENCODINGERROR_
I agree that this seems like a more appropriate error. In addition to NAME 's point, I will not that this is a semantic error, not one of encoding (which suggests syntactic).This seems like a more correct error, but I also don't have strong opinions about it.
Change:
handshake. In order to be considered a verified Designated Resolver, the TLS <del> certificate presented by the Designated Resolver MUST contain the IP address of the designating Unencrypted Resolver in a subjectAltName extension.  If the certificate can be validated, the client SHOULD use the discovered Designated Resolver for any cases in which it would have otherwise used the Unencrypted Resolver.  If the Designated Resolver has a different IP address than the Unencrypted Resolver and the TLS certificate does not cover the Unencrypted Resolver address, the client MUST NOT automatically use the </del> <ins> certificate presented by the Designated Resolver needs to pass the following checks made by the client: The client MUST verify the chain of certificates up to a trust anchor as described in Section 6 of RFC5280.  This SHOULD use the default system or application trust anchors. The client MUST verify that the certificate contains the IP address of the designating Unencrypted Resolver in a subjectAltName extension. If these checks pass, the client SHOULD use the discovered Designated Resolver for any cases in which it would have otherwise used the Unencrypted Resolver. If these checks fail, the client MUST NOT automatically use the </ins> discovered Designated Resolver.  Additionally, the client SHOULD suppress any further queries for Designated Resolvers using this Unencrypted Resolver for the length of time indicated by the SVCB

Discussion:
That's it apparently. No mention of RFC 6125(bis). On that basis, a self-signed certificate suffices. This is something that recently came up on the mailing list and apparently current deployments are validating based on WebPKI trust anchors in addition to checking for the iPAddress subjectAltName. So it's not as bad as this allows. Maybe that should be written down. The same problematic text is found in Section 4.2 and Section 5.
NAME do you have a suggestion about the right way to explain the trust anchor use here? Any text we can model after?
s/MUST contain/MUST prove authority over/ ?
I'm not looking to aggressively economize here. I was wrong about 6125. A reference to URL for the IP reference identity might be needed to cover the SAN validation piece. RFC 6125bis doesn't include the IP-ID piece, which is something I'm going to take up with the UTA WG... But it is RFC 5280 that you really want here. describes how you take a certificate and determine if you trust what it says. Start there, then talk about what the certificate needs to say (IP SAN) in order for it to be accepted. (BTW, RFC 9110 doesn't cite Section 6 of RFC 5280. It should, and it is probably my fault that it doesn't. Section 1.2 of RFC 6125bis says "In order to ensure proper authentication, applications need to verify the entire certification path as per ]" but this is a bit weak.) This is about a paragraph all up, which isn't too much to ask.
NAME take a look at the proposed text
LGTM
Change:
The following shows the syntax of the EKTField expressed in ABNF RFC5234.  The EKTField is added to the end of an SRTP or SRTCP <del> packet.  The EKTCiphertext is computed by encrypting the EKTPlaintext using the EKTKey.  Future extensions to the EKTField MUST conform to the syntax of ExtensionEKTField. </del> <ins> packet.  The EKTPlaintext is the concatenation of SRTPMasterKeyLength, SRTPMasterKey, SSRC, and ROC in that order.  The EKTCiphertext is computed by encrypting the EKTPlaintext using the EKTKey.  Future extensions to the EKTField MUST conform to the syntax of ExtensionEKTField. </ins> These fields and data elements are defined as follows:

Discussion:
s2.1, EKTPlaintext Probably over thinking this, but is the concatentation like so: +--------------+--------+--------+ +-------------+---------+--------+ I’d be afraid somebody would think it’s the other way around without being more specific. Maybe it’s as easy as: putting something like "SRTP MK denotes concatenation” s omewhere in the paragraph.
Change:
The same number of bytes are always sampled, but an allowance needs to be made for the endpoint removing protection, which will not know <del> the length of the Packet Number field.  In sampling the packet ciphertext, the Packet Number field is assumed to be 4 bytes long (its maximum possible encoded length). </del> <ins> the length of the Packet Number field.  The sample of ciphertext is taken starting from an offset of 4 bytes after the start of the Packet Number field.  That is, in sampling packet ciphertext for header protection, the Packet Number field is assumed to be 4 bytes long (its maximum possible encoded length). </ins> An endpoint MUST discard packets that are not long enough to contain a complete sample.

Discussion:
Though people will undoubtedly rely on pseudocode to understand this, there is no reason why we can't also use prose.
NAME said:
That's just an oops. There is a paragraph that almost defines this in prose. It just needs a little push and we don't need to rely exclusively on pseudocode.
Change:
13.1.  URIs <del> [1] https://blog.mozilla.org/security/2019/06/06/next-steps-in- privacy-preserving-telemetry-with-prio/ [2] https://github.com/abetterinternet/prio-documents/issues/22 </del> <ins> [1] https://github.com/abetterinternet/prio-documents/issues/22 </ins>

Discussion:
This is just converting to defn. list format. I'm going to submit a separate PR to clean up the contents.
Change:
3.4.3. <del> The URLs provided in the API SHOULD contain all the information </del> <ins> The URIs provided in the API SHOULD contain all the information </ins> necessary to render the resources requested: the resources should not depend on ambient information, such as remote address on the connection.  This is to ensure that the content served from these <del> URLs is correct and meaningful to the User Equipment, even when </del> <ins> URIs is correct and meaningful to the User Equipment, even when </ins> accessed from a network other than the one that contains the captive <del> portal.  One consequence of this is that URLs provided in the API are </del> <ins> portal.  One consequence of this is that URIs provided in the API are </ins> expected to be resolved using public global DNS (as defined in Section 2 of RFC8499). <del> Though a URL might still correctly resolve when the UE makes the </del> <ins> Though a URI might still correctly resolve when the UE makes the </ins> request from a different network, it is possible that some functions could be limited to when the UE makes requests using the captive network.  For example, payment options could be absent or a warning could be displayed to indicate the payment is not for the current connection. <del> URLs could include some means of identifying the User Equipment in the URLs.  However, including unauthenticated User Equipment identifiers in the URL may expose the service to spoofing or replay </del> <ins> URIs could include some means of identifying the User Equipment in the URIs.  However, including unauthenticated User Equipment identifiers in the URI may expose the service to spoofing or replay </ins> attacks. 4.

Discussion:
This replaces any 'URL' terminology with 'URI'. It also adds an informative reference to RFC 3986 , as suggested. Fixes issue
Multiple reviewers have suggested that we use URI instead of URL. I think we should make this change, and add the informative reference.
Change:
If implementations process out-of-epoch records as recommended in key-updates, then this creates a denial of service risk since an <del> adversary could inject packets with fake epoch values, forcing the </del> <ins> adversary could inject records with fake epoch values, forcing the </ins> recipient to compute the next-generation application_traffic_secret using the HKDF-Expand-Label construct to only find out that the message was does not pass the AEAD cipher processing.  The impact of

Discussion:
NAME
I think that the older versions of the spec were good at using the term "datagram" to refer to the thing that holds DTLS records. This version now uses "packet" in a good number of places. Sometimes I think that it means "record", other times "datagram". I'm sure that this is just the influence of QUIC and it can be fixed easily.
Actually 6357 uses "packet" all over the place. I'll do an audit, but I'm not going to ones that mean IP packet.
Change:
Relying Party can check "time(OP_r)-time(NS_r) < time(RX_v)- time(RG_v)". <del> 15.3. </del> <ins> 16.3. </ins> Handles are a third option to establish time-keeping next to nonces or timestamps.  Handles are opaque data intended to be available to

Discussion:
this is not complete and does not pass xml2rfc yet. Please add/fix your name/email. Or remove your email. Or foo at example dot com it.
Change:
not possible.  See plaintext-dns for more details regarding plaintext DNS. <del> Authenticating the ECHConfigs structure naturally authenticates the </del> <ins> Authenticating the ECHConfig structure naturally authenticates the </ins> included public name.  This also authenticates any retry signals from the client-facing server because the client validates the server certificate against the public name before retrying.

Discussion:
See .
I left this out because I figure there may be cases where there is no "published" ECHConfigList. (Maybe the config is baked in the app?)
Ah fair, that might be too precise. I think it still makes sense for that case to have the baked-in thing be an ECHConfigList than an ECHConfig, just for consistency. (I'm envisioning that ECHConfigList is the "public API" for client ECH and your TLS library might just that one byte string as input.) How about s/published/server's/?
That'd work :)
NAME done!
LGTMThanks, Chris!
Change:
Resolver without some sort of validation, such as the two methods defined in this document or a future mechanism. <ins> A client MUST NOT use a Designated Resolver designated by one Unencrypted Resolver in place of another Unencrypted Resolver.  As these are known only by IP address, this means each unique IP address used for unencrypted DNS requires its own designation discovery. This ensures queries are being sent to a party designated by the resolver originally being used. Generally, clients also SHOULD NOT reuse the Designated Resolver discovered from an Unencrypted Resolver over one network connection in place of the same Unencrypted Resolver on another network connection.  Instead, clients SHOULD repeat the discovery process on the other network connection. However, if a given Unencrypted Resolver designates a Designated Resolver that uses a public IP address and can be verified using the mechanism described in verified, it MAY be used on different network connections so long as the subsequent connections over other networks can also be successfully verified using the mechanism described in verified.  This is a tradeoff between performance (by having no delay in establishing an encrypted DNS connection on the new network) and functionality (if the Unencrypted Resolver intends to designate different Designated Resolvers based on the network from which clients connect). </ins> 4.2. Verified Discovery is a mechanism that allows automatic use of a

Discussion:
DDR designations, especially for/to non-public IP addresses, will break if cached across networks. Requirements and considerations need to be added to ensure correct behavior.
Closing with PR
Change:
The "JWK_Thumbprint" step indicates the computation specified in RFC7638, using the SHA-256 digest.  As specified in the individual challenges below, the token for a challenge is a JSON string <del> comprised entirely of characters in the base64 alphabet.  The "||" operator indicates concatenation of strings. </del> <ins> comprised entirely of characters in the URL-safe Base64 alphabet. The "||" operator indicates concatenation of strings. </ins> In computations involving key authorizations, such as the digest computations required for the DNS and TLS SNI challenges, the key authorization string MUST be represented in UTF-8 form (or, equivalently, ASCII). <ins> An example of how to compute a JWK thumbprint can be found in Section 3.1 of RFC7638.  Note that some cryptographic libraries prepend a zero octet to the representation of the RSA public key parameters N and E, in order to avoid ambiguity with regard to the sign of the number.  As noted in JWA, a JWK object MUST NOT include this zero octet.  That is, any initial zero octets MUST be stripped before the values are Base64url-encoded. </ins> 7.2. With HTTP validation, the client in an ACME transaction proves its

Discussion:
All of the Base64 strings are actually Base64 URL encoded In the Java support for big ints the top byte is set to 0 to eliminate issues with signs. The thumbprint used here does not support that. It would be useful to mention that in the spec. I think it would help if there was an appendix with a complete example from key to key authorization to help clarify the points above.
Right, point 3 is pretty unclear and requires searching with your favorite search engine.
Change:
Note that the URI parameter is not guaranteed to be null terminated. <ins> The maximum length of the URI that can be carried in IPv4 DHCP is 255 bytes, so URIs longer than 255 bytes should not be provisioned via IPv6 RA options. </ins> 3. A device may learn about Captive Portal API URIs through more than

Discussion:
Additionally, clarify recommended URI limit of 255 in each of DHCPv6 and IPv6 RA option description text.
Approved (text crafted on phone). The duplication of the warning length is intentional....
""" — Sections 2.1 and 2.2 — Why aren’t the diagrams for the two in the same format? And neither explicitly says what the length of the “len” field is. In the v4 version, one has to guess that it’s the same size as the “code” field, 1 byte. In the v6 version, one can look at the diagram. I suggest making the diagrams the same format (calibrated with bit/byte markings) and explicitly specifying in the text the size of the “len” field. """ I rather suspect this goes back to whichever source documents from which the option format text was copied. Nevertheless, harmonizing them seems reasonable.
Additionally: we should restate the 255 byte limit from DHCPv4 in each option's description.
Change:
"payload", as computed above. If optional configuration identifiers (see optional-configs)) are <del> used, "config_id" SHOULD be set to a randomly generated eight bytes. Unless specified by the application using (D)TLS or externally configured on both sides, implementations MUST compute the field as specified in encrypted-client-hello. </del> <ins> used, "config_id" SHOULD be set to a randomly generated byte.  Unless specified by the application using (D)TLS or externally configured on both sides, implementations MUST set the field as specified in encrypted-client-hello. </ins> 6.1.1.

Discussion:
accidentally targeted an older branch that was since merged into master. This just takes the same change and redirects it to the main branch.
Change:
concentrates on specifying the protocols and subprotocols that are needed to specify the interactions over the network. <ins> Operators should note that deployment of WebRTC will result in a change in the nature of signaling for real time media on the network, and may result in a shift in the kinds of devices used to create and consume such media.  In the case of signaling, WebRTC session setup will typically occur over TLS-secured web technologies using application-specific protocols.  Operational techniques that involve inserting network elements to interpret SDP -- either through endpoint cooperation RFC3361 or through the transparent insertion of SIP Application Level Gateways (ALGs) -- will not work with such signaling.  In the case of networks using cooperative endpoints, the approaches defined in RFC8155 may serve as a suitable replacement for RFC3361.  The increase in browser-based communications may also lead to a shift away from dedicated real-time-communications hardware, such as SIP desk phones.  This will diminish the efficacy of operational techniques that place dedicated real-time devices on their own network segment, address range, or VLAN for purposes such as applying traffic filtering and QoS.  Applying the markings described in I-D.ietf-tsvwg-rtcweb-qos may be appropriate replacements for such techniques. </ins> This memo uses the term "WebRTC" (note the case used) to refer to the overall effort consisting of both IETF and W3C efforts.

Discussion:
Benoit submitted a DISCUSS related to management. It was discussed and adding the following text as the penultimate paragraph in s1 ought will resolve it: Operators should note that deployment of WebRTC will result in a change in the nature of signaling for real time media on the network, and may result in a shift in the kinds of devices used to create and consume such media. In the case of signaling, WebRTC session setup will typically occur over TLS-secured web technologies (such as WebSockets [RFC6455]) using application-specific protocols. Operational techniques that involve inserting network elements to interpret SDP -- either through endpoint cooperation [RFC3361] or through the transparent insertion of of SIP Application Level Gateways (ALGs) -- will not work with such signaling. In the case of networks using cooperative endpoints, the approaches defined in [RFC8155] may serve as a suitable replacement for [RFC3361]. The increase in browser-based communications may also lead to a shift away from dedicated real-time-communications hardware, such as SIP desk phones. This will diminish the efficacy of operational techniques that place dedicated real-time devices on their own network segment, address range, or VLAN for purposes such as applying traffic filtering and QoS. The markings described in [URL] may be appropriate replacements for such techniques.
Change:
mechanism.) ecdh_Yc: Contains the client's ephemeral ECDH public key as a byte string ECPoint.point, which may represent an elliptic curve point <del> in uncompressed or compressed format.  Curves eddsa_ed25519 and eddsa_ed448 MUST NOT be used here.  Here, the format MUST conform to what the server has requested through a Supported Point Formats Extension if this extension was used, and MUST be uncompressed if this extension was not used. </del> <ins> in uncompressed or compressed format.  Here, the format MUST conform to what the server has requested through a Supported Point Formats Extension if this extension was used, and MUST be uncompressed if this extension was not used. </ins> Actions of the sender:

Discussion:
ecdhx25519 and ecdhx448 no longer have an ecdh_ prefix (.Remove some remnants of EdDSA curves as NamedCurves.TLS 1.3 only uses the PureEdDSA algorithms. If we were to use Ed25519ph, we would want separate SignatureAlgorithm values so the receivers can indicate support.
(NAME suggested I file this here.) In TLS 1.3, we dropped the "ecdh" prefix on ecdhx25519 and ecdh_x448 when we split signatures from NamedCurve/Group. The documents should probably match in naming one way or another. I think plain x25519 and x448 is tidier. X25519 already denotes the ECDH function, as opposed to curve25519 which is the curve.
Looks fine to me
Change:
The method the client instance uses to send an access token depends on whether the token is bound to a key, and if so which proofing <del> method is associated with the key.  This information is conveyed in the "bound" and "key" parameters in response-token-single and response-token-multiple responses. </del> <ins> method is associated with the key.  This information is conveyed by the "key" parameter and the "bearer" flag in response-token-single and response-token-multiple responses. </ins> If the "flags" field does not contain the "bearer" flag and the "key" is absent, the access token MUST be sent using the same key and

Discussion:
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 906ec0b0bbf3cdcb59850a43e4e9221456aa5eb8 Inspect the deploy log: Browse the preview: