jiebi/CodeConvo huggingface dataset:
Change:
Reference: [[this document]] <del> 9.10. </del> <ins> 9.11. </ins> IANA has created a new registry entitled "EDHOC External Authorization Data" under the new heading "EDHOC".  The registration

Discussion:
Discussion today in COSE on how to do RPK by value in EDHOC. Suggestions to send a COSE_Key or a C509. Additional suggestion from Carsten to use CWT. Several issues in the old GitHub on CWTs, that were not transfered to the new GitHub: URL URL URL Discussion to transfer CWT in kid, in Auxilery data, and as COSE header parameter. Transfering CWT is related to issues , , ,
I made a pull request for this URL I think it is essential that EDHOC supports CWT. CWTs are much more flexible than X.509 / C.509. I think both are needed. The need for CWT has been discussed since 2016. I think it was decided clear quite early that transporting CWT is needed but was a discussion on how to transfer them. In Aux Data, in COSE header parameter, or in the kid bstr. For some reason nothing was ever specified. TLS WG is discussing to add support for CWT. URL I think certificates and CWT needs to be included, I am not sure that we need a different format for RPK. Likely CWT or C509 can be used for this purpose.
I think it should be discussed if CWT is good enough for the . My initial understanding is that it is but this needs to be analyzed and discussed. My current thoughts. CWT needs to be supported in EDHOC. Most things in CWT is optional, it is likely an optimized enough format for the oportunistic / TOFU use case of "RPK". CWT is also very flexible. When CWT exist it would be strange to standardize a new format for transfereing a COSEKey unless it is really really needed to save bytes. CWT + Deterministic CBOR could maybe replace the discussion on how to integrity protect COSEKeys. We should at least remove the new subjectname from the COSEKey part in the EDHOC document. CWT and C509 can be used when subject name is needed. Does "Raw" COSE_Keys that are not CWT even need to be supported? Or would CWT / C509 / X.509 be enough
This change has now been done in the master branch, see a1b25ba and commits in its vicinity. Can we close the issue?
This has now been addressed.
Change:
8. <del> As discussed in background, more complex regexp libraries are likely to contain exploitable bugs leading to crashes and remote code execution.  There is also the problem that such libraries often have hard to predict performance characteristics, leading to attack vectors that overload an implementation by matching against an expensive attacker-controlled regexp. </del> <ins> As discussed in background, more complex regexp libraries may contain exploitable bugs leading to crashes and remote code execution.  There is also the problem that such libraries often have hard-to-predict performance characteristics, leading to attacks that overload an implementation by matching against an expensive attacker-controlled regexp. </ins> I-Regexps have been designed to allow implementation in a way that is resilient to both threats; this objective needs to be addressed

Discussion:
Implemented the changes as suggested in Issue
The purpose of this issue is to start discussion about how to turn this into a completed draft to send to the IESG. Perhaps the most important issue is how much of the explanatory and motivational material to leave in. There is a case to be made for taking all of it out, so you get a nice short RFC that just says what I-Regexp is. So here's my initial straw-person proposal on what should be removed and changed: Remove the "issues" para in Section 3. Section 5.2, 5.3, remove the trailing note about improving performance. This is an implementation artifact, no? Section 6. Replace with a single short paragraph somewhat as follows: "While regular expressions originally were intended to describe a formal language, i.e., to provide a Boolean matching function, they have turned into parsing functions for many applications. With this accretion of features, parsing regexp libraries have become susceptible to bugs and performance degradation, in particular those that can be exploited in Denial of Service (DoS) attacks in the case where an attacker controls the regex submitted for processing. I-Regexp is designed to offer interoperability, and to be less vulnerable to such attacks, with the trade-off that its only function is to offer a boolean response as to whether a character sequence is matched by a regex. [ If we really feel that other parts of this discussion add value, they could migrate into an appendix.] 6.1 - cut this down, retaining the first para of the first bullet point, the first sentence of the second bullet point, and that's all. The Unicode discussion can migrate into Appendix A.
Resolved by
Change:
subsequently into a ClientHello message.  DTLS 1.2 on the other hand used a separate message, namely the HelloVerifyRequest, to pass a cookie to the client and did not utilize the extension mechanism. <del> For backwards compatibility reason the cookie field in the </del> <ins> For backwards compatibility reasons, the cookie field in the </ins> ClientHello is present in DTLS 1.3 but is ignored by a DTLS 1.3 compliant server implementation.

Discussion:
I read through the draft and amassed a number of comments. This PR resolves the easy stuff. I'll send an email to the WG list with the more interesting ones shortly. Grammar fixes.The text describing sequence number encryption doesn't say how the receiver handles short ciphertexts. It's also phrased oddly. It says "In some (rare) cases the ciphertext may be less than 16 bytes", but the whole point of the text is to ensure it cannot be less than 16 bytes. Reword it. Whether there's a Certificate message is no longer a function of the ciphersuite, but of parameters in general. (With resumption that was already true.) The bits talking about epoch 1-3 so far before the definitions of those epochs should link to the section. Remove some remnants of EndOfEarlyData. They're still in the definition of the Handshake struct. I wasn't sure how to handle that since it was in the HandshakeType enum and we probably shouldn't call it RESERVED when it exists in TLS? Spell out [sender]applicationtrafficsecret since trafficsecret isn't defined.
This looks good to me.
These changes look good to me! NAME can you please have a look?
Change:
authenticated encryption of RTP media between endpoints and an "outer" key (HBH key) known only to media distributor and the adjacent endpoint) for the hop between an endpoint and a Media <del> Distributor or between Media Distributor.  Reference the following figure. The PERC Double specification I-D.ietf-perc-double uses standard SRTP keying material and recommended cryptographic transform(s) to first form the inner, end-to-end SRTP cryptographic context.  That end-to- end SRTP cryptographic context MAY be used to encrypt some RTP header extensions along with RTP media content.  The output of this is treated like an RTP packet and encrypted again using the outer hop- by-hop cryptographic context.  The endpoint executes the entire Double operation while the Media Distributor just performs the outer, hop-by-hop operation.  (See keyinventory for a description of the keys used in PERC and packetformat for an overview of how the packet appears on the wire.) </del> <ins> Distributor or between Media Distributor. The PERC Double transform I-D.ietf-perc-double enables endpoints to perform encryption using both the E2E and HBH contexts while still preserving the same overall interface as other SRTP transforms.  The Media Distributor simply uses the corresponding normal (single) AES- GCM transform, keyed with the appropriate HBH keys.  See keyinventory for a description of the keys used in PERC and packetformat for an overview of how the packet appears on the wire. </ins> RTCP can only be encrypted hop-by-hop, not end-to-end.  This framework introduces no additional step for RTCP authenticated

Discussion:
This looks good to me
Minor nits “hadnshake” —> “handshake” “Each E2E key that an endpoint uses to receive SRTP media is set by receiving a Full EKT Field from another endpoints.” —> from other endpoints.
Change:
The cTLS ClientHello is defined as follows. <ins> The client uses the "profile_id" field to inform the server about the compression profile being used (see template-based-specialization). This field MUST be set to a zero-length value and only if no compression profile is used.  Non zero-length values are agreed out of band between the client and server, as part of the specification of the compression profile. </ins> 3.2. We redefine ServerHello in the following way.

Discussion:
For cTLS/TCP, the CTLSCiphertext headers could easily all be the same size (1 byte type/flags, 2 byte length). For cTLS/UDP, the header sizes could be made more predictable. Suggestions: Always suppress sequence numbers and disallow connection IDs in cTLS/TCP, and after the first record in a datagram in cTLS/UDP. Move into the cTLS ClientHello struct.
Moving the profile_id into the ClientHello sounds good to me. Here is the PR: URL
Suppressing sequence numbers in cTLS/TCP sounds good to me as well. Here is the PR: URL
NAME closing as I think we addressed.
Change:
4.2.3. <del> Each PAUploadReq carries a list of extensions that clients may use to </del> <ins> Each UploadReq carries a list of extensions that clients may use to </ins> convey additional, authenticated information in the report.  Each extension is a tag-length encoded value of the following form:

Discussion:
NAME I'm struggling with Github here and can't figure out what change you want.
Thanks.
Disregard, I found it and pushed myself.
Change:
The diagram below shows a message flow of DTLS client and DTLS server using the DTLS-SRTP Key Transport extension. <ins> Note that when used in PERC I-D.ietf-perc-private-media-framework, the Server is actually split between the Media Distrbutor and Key Distributor.  The messages in the above figure that are "SRTP packets" will not got to the Key Distributor but the oter packets will be relayed by the Media Distributor to the Key Distributor. </ins> 5.3. When using EKT with DTLS-SRTP, the negotiation to use EKT is done at

Discussion:
EKT draft should make a clear naming difference between the message form TLS server / client and the the thing that goes at end of RTP packet Also clear up figure 5. First packets go to KD, last several packets go elsewhere
The PR fixes the figure. I looked at the naming and I don't think there is anything to be done to make it clearer.
Change:
4.3.1. <del> Common parameters such as TLS ciphersuites are known to </del> <ins> Common security parameters such as TLS ciphersuites are known to </ins> implementations.  Clients should use common safe defaults for these values whenever possible.  However, as discussed in RFC8922, many transport security protocols require specific security parameters and

Discussion:
Fix a bunch of nits
Looks good.
I would just go ahead and merge it, but, sigh, it has a conflict... I hope someone more git-savvy than me can solve this.
Looks good
Change:
header pointing to documentation about the specific hit rate limits using the "rate-limit" relation. <del> 5.6. </del> <ins> 5.7. </ins> Errors can be reported in ACME both at the HTTP layer and within ACME payloads.  ACME servers can return responses with an HTTP error

Discussion:
As discussed (too ambiguously) at IETF 96, this refactor uses two nested JWS objects instead of one parallel JWS object. This preserves the pattern that every ACME message sent by the client is signed by exactly one account key, and saves clients from having to search through multiple signatures in the verification process.
Looking at the current mechanism in a little more detail, I have a few concerns with the parallel-signature approach that's there now: It's not clear which signature is by the old key and which is by the new key, and the new key doesn't sign over the old key. Both signatures have to include the parameter, so this request burns two nonces unnecessarily The server's JWS checking code now has to switch between validating one signature and two Lots of JWS implementations don't support multiple signatures If not for this, we could require the flattened JSON serialization You need a lot of duplication to deal with the copy/paste attacks (cf. ). (On the other hand, I like that both signatures cover the parameter; reduces replayability.) I would propose that we change the signatures from parallel back to serial, as illustrated below. It would cost a little bit of payload bloat (due to another layer of base64url encoding), but I think the benefits in terms of conceptual simplicity would be worth it.
Just noticed that if we keep to one signature per object, you can do nice stuff like this on the server:
Change:
The master secret MUST be communicated as COSE_Key in the 'cnf' parameter of the access token response as defined in Section 5.6.4.5 of I-D.ietf-ace-oauth-authz.  The AEAD algorithm MAY be included as <del> the 'alg' parameter in the COSE_Key; the KDF algorithm MAY be included as the 'kdf' parameter of the COSE_Key and the salt MAY be included as the 'slt' parameter of the COSE_Key as defined in table 1. </del> <ins> the 'alg' parameter in the COSE_Key; the HKDF algorithm MAY be included as the 'hkdf' parameter of the COSE_Key and the salt MAY be included as the 'slt' parameter of the COSE_Key as defined in tab1. </ins> <del> The same parameters MUST be included as metadata of the access token; if the token is a CWT RFC8392, the same COSE_Key structure MUST be placed in the 'cnf' claim of this token.  If a CWT is used it MUST be encrypted, since the token is transferred from the client to the RS over an unprotected channel. </del> <ins> The same parameters MUST be included as metadata of the access token. This profile RECOMMENDS the use of CBOR web token (CWT) as specified in RFC8392.  If the token is a CWT, the same COSE_Key structure defined above MUST be placed in the 'cnf' claim of this token. </ins> The AS MUST also assign identifiers to both client and RS, which are then used as Sender ID and Recipient ID in the OSCORE context as described in section 3.1 of I-D.ietf-core-object-security.  These identifiers MUST be unique in the set of all clients and RS identifiers for a certain AS.  Moreover, these MUST be included in <del> the COSE_Key as header parameters, as defined in table 1. </del> <ins> the COSE_Key as header parameters, as defined in tab1. </ins> We assume in this document that a resource is associated to one single AS, which makes it possible to assume unique identifiers for

Discussion:
restructuring for readability adding a section for protocol overview adding examples for each message adding details about updating clients rights (request new token with only scope different) where before there were ref to the framework, explicitly state all the normative text add mechanism during OSCORE Setup for making sure the context is not reused on the server if token is re-posted after it has been lost/removed (nonces) added section about access rights verification between OSCORE layer and CoAP (handling of the resource) layer
Change:
IPv4 and IPv6 addresses MUST expose a different mDNS name for each address. <ins> The mDNS name of an mDNS candidate MUST be used in the connection- address field of its candidate attribute.  When an mDNS candidate is the default candidate, its mDNS name MUST be used in the connection- address field of the SDP "c=" line.  Since an mDNS candidate also conceals its address family, the "c=" line SHOULD use "IP4" in the address-type field. </ins> Note that any server-reflexive candidates generated from an mDNS host candidate will have IP addresses as their transport addresses, rather than mDNS hostnames.  Because their transport addresses are different

Discussion:
PR of
Currently it contains: c=IN IP4 address/ttl Obviously, putting one of the candidate's IP address there would defeat the purpose of use mDNS. Options: Can this be omitted? Should it have a fake IP address of the right address family? Should it be allowed to have an mDNS name?
Just use the mDNS name.
If we run into issues, we could use 0.0.0.0:9 as we do when there are no candidates, but that starts to get complicated (i.e. may require updates to other specs)
mDNS name with IP4?
good point - shouldn't matter that much, but IP4 seems like the safest choice.
Agreed to use mDNS + IP4. We'll reevaluate if this causes problems.
Fixed by
We have observed an interop issue in the experimental deployment. Endpoints can fail to parse the SDP when the c= line contains a FQDN. This is the current solution.
Well, at least we thought of the solution already :)
Change:
Protocols). the reponse SHALL include a single "Connection" header field with <del> value "Upgrade". </del> <ins> value "Upgrade" (note that this requirement is case-insensitive as per HTTP). </ins> the response SHALL include a single "Upgrade" header field with value "connect-udp".

Discussion:
This is really about case-sensitivity. The Connection header field value is case-insensitive - URL The requirement is uppercase but example uses lowercase. Without citing or mentioning the case sensitivity, readers might be confused, and pedants might complain
Change:
<del> WebTransport using HTTP/2 </del> <ins> WebTransport over HTTP/2 </ins> draft-ietf-webtrans-http2-latest Abstract

Discussion:
woohoo, making real progress!
The HTTP/2 draft uses "using". This one uses "over". This looks bad in my (sidebar) browser tabs.
HTTP/3 draft describes itself as "a mapping of HTTP semantics over QUIC", so I moderately prefer "over" based on that precedent (and well, the fact that all drafts that I wrote use "over").
Change:
Next, the client determines the length L of encrypting EncodedClientHelloInner with the selected HPKE AEAD.  This is typically the sum of the plaintext length and the AEAD tag length. <del> The client fills in a "encrypted_client_hello" extension with the outer variant of ClientECH with following values: </del> <ins> The client fills in an "encrypted_client_hello" extension with the outer variant of ClientECH with the following values: </ins> "config_id", the identifier corresponding to the chosen ECHConfig structure;

Discussion:
Just some minor nits I picked up during a slow pass of the spec.
LGTM pending one nit.
Change:
but different parameters.  These messages do not include the TLS record layer and are therefore not encrypted with a handshake key. <ins> 4.1. </ins> Each authenticator is computed using a Handshake Context and Finished MAC Key derived from the TLS session.  These values are derived using an exporter as described in RFC5705 (for TLS 1.2) or TLS13 (for TLS

Discussion:
There are lots of changes here. I did stage this as separate commits to some extent, so feel free to cherry-pick. There is one maybe-technical change here. It wasn't clear about the precedence between handshake and authenticator request for extensions. I've chosen to be clear about this and say that if the authenticator request exists, then it is the only thing that matters. That's 8c0b166. I can drop that from the CL and do that separately if you prefer.
Thanks for the comments. The technical clarification you made is the correct one, the request supersedes the handshake for extension choices if present.
Change:
3.4.2. <ins> This document defines a capsule (WT_MAX_STREAMS) that allows each endpoint to limit the number of streams its peer is permitted to open as part of a WebTransport session.  There is a separate limit for bidirectional streams and for unidirectional streams.  Note that, unlike WebTransport over HTTP/3 WEBTRANSPORT-H3, because the entire WebTransport session is contained within HTTP/2 DATA frames on a single HTTP/2 stream, this limit is the only mechanism for an endpoint to limit the number of WebTransport streams that its peer can open on a session. 3.4.3. </ins> WebTransport over HTTP/2 uses several capsules for flow control, and all of these capsules define special intermediary handling as described in Section 3.2 of HTTP-DATAGRAM.  These capsules, referred

Discussion:
Expand description of flow control and add additional notes NAME already wrote up a very nice overview of the layers we have, so added a little bit extra there and filled in the last little bit on limiting streams within a session to round everything out.
Document how MAXDATA interacts with the enclosing HTTP/2 flow control scheme Originally posted by NAME in URL
I tend to think we might want to have a section entirely on flow control since we've now got several layers: HTTP/2 connection level HTTP/2 stream for the CONNECT stream WTMAXDATA for the WT session Noting that this is different than the HTTP/2 layer's CONNECT stream, since we want to be able to indicate the sum of stream data separately from other control frames WTMAXSTREAMDATA for each WT stream And stream-count flow control HTTP/2 stream limits don't really apply once you've got the WT session up WTMAX_STREAMS limits stream counts within a WT session Just indicating the intended usage of each of these knobs would be helpful.
(From : Since QUIC's flow control credits work differently from H2, it may be worth explicitly stating how this works here.)
Chair notes from IETF 112 meeting: no one objected to proposal of resolving this by documenting how flow control works and pitfalls
Why do we need WTMAXDATA in first place? I thought that since we have flow control from the HTTP/2 side, we don't need it.
We want to be able to say "don't send me any more data on this stream" while still allowing control frames on that stream
Change:
4.1. <del> The publisher sends an HTTPS POST request to the "relay- notifications" resource under a known path on the receiver with the "Content-Type" header set to either "application/json" or "application/xml" and a request body containing the notification encoded using the specified format. </del> <ins> The publisher sends an HTTPS POST request to the "relay-notification" resource (see overview) on the receiver with the "Content-Type" header set to either "application/json" or "application/xml" and a body containing the notification encoded using the specified format. </ins> XML-encoded notifications are encoded using the format defined by RFC5277 for XML.

Discussion:
Getting the draft ready for publication. Did file a bug with libyang folks and even though it was an operator error on my part, the default in yanglint now is to enable all features when none are mentioned. The examples now validate correctly.
Change:
Issuers maintain an issuance key pair for the issuance protocol.  The Issuer public key is made available to all Clients in such a way that <del> key rotations and other updates are publicly visible.  The key material and protocol configuration that an Issuer uses to produce tokens corresponds to two different pieces of information. </del> <ins> key rotations and other updates are publicly visible.  See key- rotation-privacy for more considerations around Issuer key rotation. The key material and protocol configuration that an Issuer uses to produce tokens corresponds to two different pieces of information. </ins> The issuance protocol in use; and

Discussion:
cc NAME
S3.2.2.2 states "Issuers MUST only use one private key for issuing tokens at any given time." The next section (3.2.3), however, suggests that multiple keys could be used to encode metadata, and indeed, I believe the latest draft of rate-limited tokens uses different issuance keys. These seem to be in conflict.